Permissions

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:

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.