---
title: "Turn the MCP connector on or off for your organization."
method: PUT
path: "/internal/api/mcp/settings"
tags: ["MCP CONNECTOR"]
---

# Turn the MCP connector on or off for your organization.

`PUT /internal/api/mcp/settings`

## Request

- Base URL: `https://api.signalshq.io` (the document declares no server; this is the origin it was published from)
- URL: `https://api.signalshq.io/internal/api/mcp/settings`
- Auth: OAuth 2
  - Password
  - Token URL: `/auth/login`

The per-firm switch the MCP auth path checks on every request.

Without this endpoint the self-service flow did not actually work:
absence of a settings row means DISABLED, nothing else created one, so
a firm could mint a key and get ``401 the MCP connector is not enabled
for this organization`` with no way to fix it from the dashboard.

Disabling does NOT revoke keys. That separation is the point — an
operator can suspend a firm without invalidating credentials their
team has already deployed into infrastructure we do not control, and
re-enabling restores service without a re-integration.

Returns the full connection state so the settings page re-renders from
one round trip rather than toggling and then re-fetching.

## Request body

- UpdateMcpSettingsRequest
  - `mcp_enabled` boolean, required: Master switch for THIS organization. A valid API key does nothing while this is false, so an operator can suspend one firm without revoking credentials their team has already deployed.
  - `rate_limit_per_minute` integer, nullable: Requests per minute across the whole connector for this organization. Null means no cap. Connector traffic is driven by a third-party host on a schedule you do not control, so this is the ceiling that keeps a looping host from becoming an availability problem for the rest of Signals.
  - `daily_spend_cap_cents` integer, nullable: Ceiling on AI spend through the connector per UTC day, in cents. Null means uncapped. Checked before each question, so the cap can be passed by at most one question.

## Response `200`

Successful Response

- McpConnectionResponse: Everything the Settings page needs to render connection details. Deliberately one call. The page has to answer "is this on, where do I point it, do I have a key, and how do I wire it up" together — split across four endpoints it renders half-configured states that read as bugs.
  - `mcp_enabled` boolean, required: Whether this organization may use the connector.
  - `server_url` string, required: The MCP endpoint. Must be entered EXACTLY as given — OAuth discovery compares this string rather than normalizing it. Empty when the server has no ELAN_MCP_RESOURCE_URL set, which means the deployment is not ready to accept connectors.
  - `transport` string
  - `auth_header` string: Header carrying the credential.
  - `auth_scheme` string: Sent as ``Authorization: Bearer <api key>``.
  - `active_key_count` integer, required: Live keys for this organization. Zero means the connector cannot be used yet however it is configured — the setup screen should lead with 'create a key' in that state.
  - `tools` McpConnectionTool[]
    - `name` string, required
    - `summary` string, required
  - `setup` McpSetupStep[]
    - `client` string, required: Which AI tool this snippet is for.
    - `instructions` string, required
    - `snippet` string: Copy-paste command or config. ``<YOUR_API_KEY>`` is a placeholder — the real key is NEVER interpolated here, so this response stays safe to render, screenshot and paste into a support ticket.
  - `notes` string[]: Caveats worth showing next to the steps rather than burying in docs — read-only scope, and that access follows the credential rather than the person holding it.

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/signalshq/apis/signals-api.md) - [All operations](https://skmtc.dev/signalshq/apis/signals-api/llms.txt) - [OpenAPI document](https://skmtc.dev/signalshq/apis/signals-api/revisions/2c22af3b5576?raw)