The Claude API MCP connector lets a developer attach remote MCP servers to a Messages API request without writing an MCP client. It supports tool calls only, and the server must be public over HTTP, so local stdio servers cannot connect directly. It is in beta, so check the current page before building on it.
What it is
Anthropic's documentation describes the connector as a way to connect to remote MCP servers directly from the Messages API without a separate MCP client. It is marked beta and requires a beta header. A previous version is deprecated, and the page notes that it is not eligible for zero data retention. Features and availability can change, so read the current page.
Key features listed include tool calling, enabling all tools or allowing and denying specific ones, per tool configuration, OAuth bearer tokens, and several servers in one request.
Limits that matter for security tools
| Limit | Meaning |
|---|---|
| Tool calls only | Resources and prompts from the specification are not supported by the connector |
| Public HTTP servers only | Local stdio servers cannot be connected directly |
| Token supplied by you | Your application obtains and refreshes the OAuth token |
| One toolset per server | Each server is referenced by a single toolset |
The documentation says API consumers must handle the OAuth flow, obtain the access token before the call, and refresh it as needed. The connector passes the token you give it in an authorization token field. That puts credential handling in your code, which you then need to protect.
Controlling which tools are available
The page describes a toolset for each server with a default configuration and per tool overrides. Three patterns appear.
- Allow everything, the default.
- Allow list: disable all tools by default and enable only the ones you name.
- Deny list: enable all tools and disable specific ones. The page recommends denying write or destructive tools when you build read only assistants, or when you want a human confirmation step before state changes.
For security tools, the allow list is the safer start. A deny list lets any tool added later through, until you notice.
Pinning the tool list
The documentation describes a beta way to pin a server's tool list. You copy the tools reported by the API into your toolset, and the API then does not ask the server for its tools, so the toolset contains exactly those entries. This ties directly to a worry that applies to every connector: a vendor can change tools after you approved them. A pinned list means a new tool will not appear until you add it.
A worked example
This example is illustrative. A team builds an internal assistant that answers questions about open vulnerabilities.
- The developer registers the vendor's remote server in the request, with the token from a secrets manager.
- The toolset disables everything by default and enables four read tools.
- The developer pins the tool list, so the vendor cannot add a tool silently.
- The assistant's system prompt tells the model to state totals and to say when results were paged.
- The team logs each tool call with the user who triggered it.
- A weekly job compares the vendor's current tool list with the pinned one and alerts on a difference.
Step by step: before you build
- Confirm the server is reachable over public HTTP and uses OAuth.
- Decide where tokens are stored and who can read them.
- Write the allow list.
- Decide whether to pin tools.
- Plan logging and the review of odd calls.
- Confirm data handling terms for your use of the API, noting the zero data retention point on the page.
Choosing between the connector and your own client
The page suggests that when you have remote servers reachable by URL and only need tool support, the connector parameter fits. If you need local servers, prompts, resources or more control, use the client side helpers with an MCP SDK. The choice also changes who holds the connection: with the connector, the call to the server is made from Anthropic's side, so network rules for a private server must allow it.
Mistakes to avoid
Do not treat a long lived token as harmless because it sits in your backend. Do not skip the allow list because the vendor's tools look safe today. Do not forget that descriptions are text the model reads, so a hostile description is a risk even through an API.
Operating it after launch
An API integration is not finished at launch. Assign an owner for the toolset, a reviewer for changes to it, and a date to revisit the choice of servers. Watch the vendor's release notes for tool changes, and watch your own logs for calls that look different from the usual pattern, such as a tool that was never called before.
Also test the failure paths. Turn off the token and see what the assistant says. Return an error from the server and check that the assistant reports it instead of inventing an answer. These tests take little time and tell you how the system behaves on a bad day.
Where Safeguard fits
Safeguard offers an MCP Guardrail for policy on the tools agents can call and agent identity for accountability. A free scan shows what an assistant could be asked about. The Safeguard CLI, installed with a curl or PowerShell installer, can also write code, and the download page lists a Local agent and a Cloud agent as available.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a server declares tools, then think about which you would allow, deny or pin.
Quick check
Can the connector reach a server on my laptop?
No. The documentation says local stdio servers cannot be connected directly, and the server must be publicly exposed over HTTP.
Does the connector handle OAuth for me?
No. The documentation says API consumers handle the OAuth flow and refresh the token.
Why pin the tool list?
So a tool added by the vendor later does not become available until you add it yourself.
Sources
Last reviewed: 19 October 2026.
