Connectors

The URL must be HTTPS and publicly reachable; the gateway refuses private and internal addresses, and never follows redirects. For a REST API, the base URL is the only place its credentials are ever sent: the addresses a spec suggests are offered as a choice when you create the connector, never used on their own.

Who owns it. A connector belongs to one workspace (its admins manage it, only its endpoints use it), or to the organization: organization admins manage it, and it is shared with every workspace or the ones picked on its Workspaces tab, with one set of credentials.

An account for agents. Agents are not people, so with OAuth · each user they have no account of their own. An organization admin can connect one organization account on the connector’s page (Connect for the organization); agents then use it. A person’s own connection always comes first, and letting people fall back to the organization account is off unless an organization admin turns it on. Logs show whose account each call used.

Not supported: mutual TLS and request signing (AWS SigV4, HMAC). An agent can never replace the connector’s credentials: an argument with the same name as a credential header or query parameter is dropped.

Sync capabilities reads what the connector offers and records each capability’s exact definition: name, description, arguments, everything a model reads. Test only checks that the connection works (for a REST API, that the spec reads; the API itself is not called).

• What is switched on. On an MCP server’s first sync, what it lists is switched on; anything that appears in a later sync arrives switched off, because a new tool on an approved server is what a takeover looks like. Every tool imported from a REST API arrives switched off, first sync included.
• Changed definitions. When a definition changes upstream (a rewritten description is enough), the tool is blocked as changed until an admin approves the new version on the Capabilities tab. Even between syncs, a tool whose live definition differs from the approved one is not shown to agents.
• Tool poisoning. Each new definition is scanned for instructions hidden in it (concealment, hidden tags, requests to read sensitive files, attempts to override other tools). A flagged one is quarantined: hidden and refused until an admin releases that exact definition.
• Removed tools stay listed as removed, with their settings, in case they come back.
• Changing the URL or the credentials marks the connector out of date until the next sync.

What these mean on a call is described in Security controls. Guardrails for every endpoint of the connector are attached on its Guardrails tab.

Give the spec’s URL (read again on every sync, so tools follow the API as it changes, each change waiting for approval) or upload the file. Read spec shows, before anything is created, the tools it would become, how many change data, the operations that would be skipped and why, the base URLs it suggests, and the authentication it declares, with Use to fill in the form.

• OpenAPI 3.0 and 3.1, JSON or YAML, up to 12 MB. Swagger 2.0 is refused with how to convert it.
• An uploaded file must be .json, .yaml or .yml and parse as that format; duplicate keys are refused.
• Only references inside the spec are followed; nothing a spec points at is fetched. A spec URL is fetched without credentials and without following redirects, so a spec behind a login has to be uploaded.
• Each operation is one tool, named from its operationId. Path, query and header parameters and the fields of a JSON or form body become its arguments. Operations with multipart (file upload) bodies or required cookies are skipped and listed with the reason.
• Everything but GET and HEAD starts Privileged; every tool starts switched off.

The last line of each tool’s description says how the call is made, for example HTTP request: POST /v1/customers; query: expand; body (form): email, name. It is part of the approved definition, so a spec change that moves an argument (from the body to the query, say) is a change an admin approves.

Declare each endpoint: a tool name, the method, a path relative to the base URL with {placeholders}, a description the model reads, and its arguments with their type and where each is sent. Arguments named in the path go there; the rest go in the body (JSON or form), or in the query string for GET, HEAD and DELETE, unless you send them as a query parameter or header. The form shows the request line as it will be pinned, and Edit as JSON takes the same declarations as JSON.

Every argument value is encoded where it goes, so an argument can never add a path segment or a query parameter, and a path argument of . or .. is refused.