Claude connectors: how to plug Claude into your tools, and check what comes back

A finance analyst wants to know how many enterprise invoices went overdue last month. Without a connector, she exports a CSV from the billing system, uploads it, and hopes the export had the right filters. With one, Claude queries the billing system itself, in the conversation, and shows the call it made.

That is what a connector is: a link between Claude and an outside service, built on the Model Context Protocol (MCP), which Anthropic describes as "an open standard, created by Anthropic, for AI applications to connect to tools and data" (Anthropic Help Centre). The service runs an MCP server; Claude calls the tools that server exposes, such as "search issues" or "run this SQL".

There are two kinds:

• Directory connectors. Anthropic keeps a catalogue at claude.ai/directory of MCP servers it has reviewed. Some are remote ("Connect"); some are desktop extensions that run on your machine ("Install").
• Custom connectors. Any remote MCP server you add by URL. Anthropic does not review these.

What a connector can do depends entirely on its server. Five that analysts and ops teams use, as their own docs describe them (checked October 2026):

Note the last column. The useful question about any connector isn't "what can it read" but "what can it change".

Start with the directory if your tool is in it, because those servers have been through Anthropic's review. Otherwise:

1. Pro and Max: open Customize > Connectors, choose Add, then "Add custom connector". Give it a name and the server URL.
2. Team and Enterprise: an Owner or Primary Owner adds the connector once in Organization settings > Connectors. Each member then connects individually, with their own login.
3. Choose how it signs in: sign in now, sign in when needed, or none. Fixed credentials can go in request headers.
4. Approve tools as they're used. Claude asks before it calls a tool. "Allow always" saves clicks; keep it for tools you trust and that can't write.
5. To change a connector, remove it and add it again. There's no edit.

Three practical limits, from Anthropic's help and developer docs (checked October 2026):

• Plans. Connectors work on Free, Pro, Max, Team and Enterprise, across Claude, Cowork and Claude Desktop. Free accounts are capped at one custom connector.
• Network. Claude connects from Anthropic's cloud, not from your laptop, so a server behind a VPN or firewall must allowlist Anthropic's IP ranges. Local MCP servers configured in claude_desktop_config.json are a separate route that only Claude Desktop uses.
• Size and time. Tool results are capped at roughly 150,000 characters, and calls time out after 240 seconds on claude.ai and Desktop.

The timeline is short. Remote MCP arrived in Claude as "Integrations" on 1 May 2025, in beta for Max, Team and Enterprise, reached Pro on 3 June 2025, and the directory followed in July 2025 (Anthropic, 2025).

A connector gives Claude your data, but it doesn't tell you which sentences in the answer came from it. Count is a connector built for that job. Add it like any other, and each claim comes back tagged as a citation, an assumption, model knowledge or a hallucination.

The case for connectors is strong. A model answering from memory is answering from training data with a cutoff; a model answering from your billing system is answering from this morning. For anything about your own business, that difference is the whole game, and we'd connect the source over pasting an export every time.

The trade is that the errors move. They stop being "the model made up a number" and become quieter:

• Truncation. BigQuery's MCP server returns at most 3,000 rows. Ask for revenue by customer across 12,000 customers and Claude may be summarising a quarter of them unless it aggregated in SQL.
• The wrong question asked well. The SQL can be valid, run fast and still join the wrong table or pick the wrong date column. On realistic enterprise schemas, the best agent in the original Spider 2.0 paper solved 21.3% of tasks against 91.2% on the older academic Spider 1.0 (Lei et al., Spider 2.0, arXiv v1). Agents have improved since; real schemas are still where they slip.
• Long tool runs. In a 2026 study of 14 models, factual accuracy fell by about 42% as the number of tool calls grew from 2 to 150 (Onweller et al., Cited but Not Verified, May 2026). Every extra connector call is another place for an answer to drift from its source.

None of this is an argument against connectors. It's an argument for reading the tool calls Claude shows you, which most people collapse and never open.

Anthropic's help page on custom connectors reads like a security briefing, and it should. The main points: custom connectors reach services Anthropic hasn't verified; Claude acts with your permissions; malicious servers can hide prompt injections; developers can change a tool's behaviour without notice; and on Team and Enterprise a shared API key gives every member that key's access.

The one most teams miss: during Research, tools can run without approval. Anthropic's advice is to disable any connector that writes to external apps before you start a research session.

These risks are documented, not theoretical. In May 2025 Invariant Labs showed a malicious public GitHub issue leading an agent in Claude Desktop, with "Always Allow" on, to leak private-repository data into a public pull request. In July 2025 a support ticket carrying hidden instructions led an agent with an over-privileged Supabase key to read a table of integration tokens and post it back into the ticket (General Analysis, July 2025).

The defences are boring and they work. Prefer read-only modes (Linear's read-only URL, Snowflake's read-only SQL, an IAM deny on BigQuery's execute_sql). Scope OAuth to the least you need. Don't mix a write-capable connector with one that reads untrusted text, such as public issues or inbound tickets, in the same session.

Anthropic documents nothing about connector accuracy specifically. The connector moves data; what Claude does with it is the part to check.

A two-minute check on any connector answer

1. Open the tool calls. Which connector did Claude use, and with what query or filter? If it searched rather than queried, the answer rests on whatever the search returned first.
2. Count the rows. Compare the row count in the tool result with what you'd expect. A suspiciously round number (3,000 on BigQuery) means truncation.
3. Re-run one query yourself in the source tool. Copy the SQL or the filter Claude used and look at the result directly.
4. Ask: "Which numbers in your answer came from a tool result, and which came from your own knowledge or an assumption?" Then check the second group.
5. Check what was written. If a write-capable connector was on, look at the service's activity log for anything Claude changed.

Step 4 is the one that catches most problems, because the model often fills a gap between two tool results with a reasonable-sounding guess.

Connectors can also be used to check work, not only to fetch it. Count runs an MCP server that you connect to Claude like any other custom connector. Its job is the opposite of a data connector's: rather than bringing data in, it takes an answer Claude has given and audits it.

A typical case (illustrative). A revenue operations analyst has BigQuery connected and asks Claude for last quarter's logo churn by plan tier. Claude runs three queries, joins the results and writes a confident paragraph with a table. Before the table goes into the board pack, the analyst asks, in the same conversation, for Count to audit the answer.

Count replies with a link to a canvas. On it, the answer is split into its individual claims, each labelled:

• Citation: traces to a source you can open, here a query result.
• Assumption: rests on something nobody checked, such as which customers count as churned.
• Model knowledge: said from memory, and possibly out of date.
• Hallucination.

Under each claim sits its reasoning chain: the prompt, what the model already believed, each query and calculation, and the source the claim rests on. If churn was calculated on the wrong definition (logo churn and revenue churn can differ sharply on the same data: one customer leaving out of three is 33% logo churn but can be 50% revenue churn, per ChartMogul's worked example), that's where it shows.

The canvas is also a full analytics workspace, so the analyst can open the query, fix the definition and re-run it there.

What are Claude connectors?

Are Claude connectors free?

What's the difference between a Claude connector and MCP?

Is it safe to connect Claude to company data?

Can a Claude connector change data, or only read it?