---
title: Permissions | Stainless
description: Configure fine-grained permissions for the MCP code execution tool to control which SDK methods clients can call
---

Permission enforcement relies on static analysis of executed code. Determined users can bypass these checks through code obfuscation. Always use API-layer authentication with restricted tokens to protect sensitive operations.

By default, the MCP code execution tool allows clients to call any API method through your SDK. Permissions let you restrict which methods the code tool can execute, giving you control over what MCP clients can do with your API.

## Permission settings

Three settings control method access:

| Setting           | Type       | Description                                      |
| ----------------- | ---------- | ------------------------------------------------ |
| `allow_http_gets` | `boolean`  | Allows all methods that map to HTTP GET requests |
| `allowed_methods` | `string[]` | Regular expressions matching methods to allow    |
| `blocked_methods` | `string[]` | Regular expressions matching methods to block    |

## How method names work

Permissions match against fully qualified SDK method names. These names follow the resource hierarchy in your SDK, separated by dots.

For example, if your SDK has a `users` resource with a nested `messages` resource:

- `users.list` matches the `list` method on the `users` resource
- `users.messages.list` matches the `list` method on the `messages` resource
- `users\..*` matches all methods under the `users` resource (regex pattern)

## How settings interact

When you configure multiple permission settings, they combine in a specific order:

1. **Collect allowed methods**: Start with `allowed_methods` patterns. If `allow_http_gets` is true, add all GET-based methods.
2. **Apply blocks**: Remove any methods matching `blocked_methods` patterns from the allowed set.

If no `allowed_methods` or `allow_http_gets` are set, all methods are allowed by default (subject to `blocked_methods`).

## Configuration

You can configure permissions in your Stainless config file or as command-line flags when starting the MCP server. Flag values override config defaults.

### Stainless config

To configure permissions, add a `code_exec_permissions` block to your MCP server options:

```
targets:
  typescript:
    options:
      mcp_server:
        code_exec_permissions:
          allow_http_gets: true
          allowed_methods:
            - "users\\..*"
            - "organizations\\.retrieve"
          blocked_methods:
            - ".*\\.delete"
```

### MCP server flags

To configure permissions at runtime, pass command-line flags when starting the server:

Terminal window

```
npx -y my-org-mcp \
  --allow-http-gets \
  --allowed-methods "users\..*" \
  --allowed-methods "organizations\.retrieve" \
  --blocked-methods ".*\.delete"
```

Flag values take precedence over values set in the Stainless config.

## Examples

### Read-only access

Allow only methods that map to HTTP GET requests:

```
code_exec_permissions:
  allow_http_gets: true
```

This blocks all POST, PUT, PATCH, and DELETE operations while allowing any read operation.

### Allow specific resources only

Restrict access to a single resource:

```
code_exec_permissions:
  allowed_methods:
    - "users\\..*"
```

Clients can only call methods on the `users` resource. All other resources are inaccessible.

### Block sensitive resources

Allow everything except specific resources:

```
code_exec_permissions:
  blocked_methods:
    - "billing\\..*"
    - "admin\\..*"
```

Clients can call any method except those under the `billing` and `admin` resources.

### Combine allow and block

Allow read access but block sensitive read endpoints:

```
code_exec_permissions:
  allow_http_gets: true
  blocked_methods:
    - "admin\\..*"
    - "billing\\.invoices\\..*"
```

Clients can read from any resource except `admin` and `billing.invoices`.

## Enforcement

The MCP server enforces permissions through static analysis of the TypeScript code submitted to the code tool. Before execution, the server inspects the code for method call signatures and rejects requests that reference blocked methods.

Because enforcement is based on static analysis, it can be circumvented by obfuscating method calls. For this reason, permissions should be treated as a convenience layer, not a security boundary. To protect sensitive API operations, use API-layer authentication with restricted tokens or scoped API keys that limit what the caller can do at the API level.