Deciding whether to connect an official MCP server

The notice arrives from a tool you already pay for. There is now an official MCP server. First-party, supported, documented, and the setup is a URL, an approval screen and a couple of minutes of your afternoon. The word doing the work in that notice is “official”, and it is not obvious what it is supposed to have settled.

This guide is for a solo operator or a small team who already runs an assistant with one or two connectors and is deciding about the next one. It is not for someone publishing a server other people will connect to, and it is not for a security team with an identity provider and a policy engine, both of whom should be reading the protocol’s own security pages, which state plainly that their primary audience is developers implementing MCP authorization flows, MCP server operators, and security professionals evaluating MCP-based systems [2]. The argument here is short. First-party support answers the question of who is accountable for a server. It does not answer the question of what that server can do while acting as you, and only the second question has consequences.

Official verifies who published the server, not what it does

There is a real verification step behind the word, and it is worth knowing exactly how far it goes. The MCP Registry describes itself as “the official centralized metadata repository for publicly accessible MCP servers, backed by major trusted contributors to the MCP ecosystem such as Anthropic, GitHub, PulseMCP, and Microsoft” [3]. Server names use a reverse-DNS format such as com.example/server, tied to verified GitHub accounts or domains, and the registry states that this “ensures that only the legitimate owner of a GitHub account or domain can publish servers under that namespace” [3].

That is a genuine guarantee and a narrow one. It proves that whoever published com.example/server controls example.com. It says nothing about what the code in that server does. The registry is explicit that it “delegates security scanning” to the underlying package registries and to downstream aggregators, and that it “focuses on namespace authentication and metadata hosting, while relying on the broader ecosystem for security scanning of actual server code” [3].

The moderation policy is where the boundary becomes unmistakable. Its summary line says the registry will “only remove illegal content, malware, spam, and completely broken servers” [4]. It then states that the registry “does not make guarantees about moderation, and consumers should assume minimal-to-no moderation” [4]. And under the heading of what it will not remove, alongside low-quality and buggy servers, it lists “Servers with security vulnerabilities” [4]. The registry is also still labelled a preview, with breaking changes or data resets possible before general availability [3].

Read that as it is written rather than as a criticism. The people running the registry are being honest about what a directory can and cannot do. A verified namespace is a name badge, not a background check. Treat every official server the way you would treat a new API integration from a vendor you already have a contract with: the vendor is real, the invoice will be legitimate, and you still have to read what you are agreeing to.

The tool list is the access model, and it is public before you connect

The useful thing about MCP is that the access model is not hidden behind marketing copy. Servers offer resources, prompts and tools, and tools are the ones that act: the specification defines them as “Functions for the AI model to execute” [1]. Where a vendor documents its tool list, that list is the answer to what an agent can do once connected.

Notion’s documented tool list is a good example because it is long and it is legible. On the reading side it has notion-search, notion-fetch and notion-query-data-sources. On the writing side it has notion-create-pages, notion-update-page, notion-move-pages and notion-create-comment, among others [8]. Nobody has to speculate about whether an assistant connected to Notion can move your pages around. The documentation says it can, by name, before you click anything.

So read the list, and sort it into two piles: things that observe and things that change. Then check the second pile against the job you actually wanted done. Notion’s published list runs to more than thirty tools [8], and if you connected it to summarise a database or find last quarter’s notes, the tools that create, update and move pages arrived in the same approval as the ones that read.

The specification is direct about why that matters. Tools “represent arbitrary code execution and must be treated with appropriate caution”, and, in a line worth reading twice, “descriptions of tool behavior such as annotations should be considered untrusted, unless obtained from a trusted server” [1]. The description telling your assistant what a tool does is itself content from the server. Anthropic’s support documentation puts the same risk in operator language: “Malicious MCP servers may include hidden instructions that try to make Claude perform unintended actions” [6].

A connector inherits the access you already have

The thing that is easy to get wrong is imagining that a connector gets its own smaller account. It does not. It authorises as you, and its ceiling is your ceiling.

Notion’s own documentation shows this in the small print of individual tools. Query results “include only rows and properties that the connected user can read” [8], and converting a page requires that “the page must be in the connected workspace, and you must have permission to edit it” [8]. Both sentences are reassuring and revealing at once. The server cannot exceed your permissions. It also does not need to, because your permissions are broad. If you are an admin of the workspace, so is the assistant.

This is why scope is the control that actually does work, and the protocol’s security guidance treats it as a first-class subject under the heading of scope minimization. Broad scopes produce “Expanded blast radius: stolen broad token enables unrelated tool/resource access” and make revocation painful, because “revoking a max-privilege token disrupts all workflows” [2]. Among the listed common mistakes are “Using wildcard or omnibus scopes (*, all, full-access)” and “Bundling unrelated privileges to preempt future prompts” [2]. There is a behavioural failure in the list too, and it is the one you will recognise: “Consent abandonment: users decline dialogs listing excessive scopes” [2]. A consent screen asking for everything trains people to stop reading consent screens.

The specification also concedes the structural limit. It states that “MCP itself cannot enforce these security principles at the protocol level” and that implementors merely “SHOULD” build robust consent and authorization flows into their applications [1]. Consent is a promise made by the client you are using, not a property of the protocol.

Your controls live in the client, not in the server

Once you accept that the server will not constrain itself, the question becomes what your own tools give you. The answer is more than most people use.

Anthropic’s guidance for Claude Code states the warning plainly: “Verify you trust each server before connecting it. Servers that fetch external content can expose you to prompt injection risk” [5]. It then documents the dials. You can pin OAuth scopes in configuration so the client requests only what you list, using a value such as channels:read chat:write search:read rather than whatever the server advertises [5]. Organisations can set per-tool controls on connector tools, where a tool set to ask prompts on every call, with the prompt appearing even in acceptEdits, auto and bypassPermissions modes, and a tool set to blocked is filtered out before Claude sees it, so it never appears in the tool list at all [5]. A blocked tool is a stronger control than a careful instruction, because it removes the option rather than discouraging it.

On the consumer side, Anthropic is blunt about what a custom connector is: “Custom connectors allow you to connect Claude to arbitrary services that have not been verified by Anthropic” [6]. The guidance is to only connect to trusted servers and to “Review requested permissions carefully” during authorisation [6]. Permissions can be removed “at any time by disconnecting the connector in Claude’s settings or the third-party service’s security settings” [6], and it is worth knowing which of those two you would reach for at speed.

OpenAI’s documentation for MCP apps in ChatGPT reads the same way. “Connecting to unsafe or untrusted MCP servers may increase exposure to security risks (including prompt injection)” [7]. There is a write-side control: “ChatGPT can ask for confirmation before important actions or other changes based on app permissions and the action’s context”, and “Admins see risk warnings when enabling apps that can write or modify data” [7]. On Business plans, “Only admins/owners can enable developer mode and deploy an app” [7]. That last detail is a small-team detail. If you are the admin, you are the review board, and nobody else is going to catch it.

Local servers are a different risk class from remote ones

Official servers arrive in two shapes, and the difference matters more than the vendor’s logo. A remote server is a URL you authorise against. A local server is software you run.

The protocol’s security guidance is unsentimental about the second kind. Local MCP servers “are binaries that are downloaded and executed on the same machine as the MCP client”, and the listed risks start with arbitrary code execution, where “Attackers can execute any command with MCP client privileges”, followed by “No visibility”, because “Users have no insight into what commands are being executed” [2]. Where a client supports one-click local configuration, it “MUST implement proper consent mechanisms prior to executing commands” and must “Show the exact command that will be executed, without truncation” [2]. Warning the user that “MCP servers run with the same privileges as the client” is only a SHOULD, as is running the server sandboxed [2].

The practical translation is that installing a local MCP server is installing software, with all the judgement that normally implies, and a one-click flow presents that decision in the shape of adding a browser extension. Claude Code’s own configuration surface reflects the same caution. It executes a headersHelper as an arbitrary shell command, and it prompts for approval in interactive sessions before using project-scoped servers from .mcp.json files [5]. A repository you cloned cannot connect its own servers on your behalf.

Connect it read-only, and make writes a second decision

The sequencing is the whole method, and it costs you a week rather than an afternoon.

Connect the server with the smallest set of scopes the client will let you specify, and turn off or block every tool that changes anything [5]. Use it for real work in that state. You will learn two things that no documentation gives you: whether the server returns what you expected, and whether the assistant reaches for it at sensible moments. If a server that reads well in a tool list turns out to be useless in your actual work, finding that out while it can only read costs you nothing.

Then enable writes one tool at a time, starting with the reversible ones. Comments before page updates, drafts before publishes, and nothing that deletes. Keep the confirmation step on the actions you cannot undo, and use the client’s per-call approval where it exists rather than a note in a system prompt [5][7]. Verify the revoke path once, while nothing is wrong, so that you are not learning the settings layout during an incident [6].

Note also which servers were never worth an account in the first place. A server that reads public documentation and holds no credential of yours has no write tools to misuse and no token worth stealing, which removes most of the scope problem above. It does not remove the injection problem, because it is exactly the kind of server that fetches external content [5]. It is still the cheapest first connection for anyone who wants to see how this works before authorising anything real.

What still goes wrong

The largest unresolved problem is the one both vendors name in their own documentation, and neither claims to have solved. Connecting servers increases exposure to prompt injection [5][7], and the specification’s answer is that tool descriptions from an untrusted server should be treated as untrusted [1]. There is no setting that fixes this. There is only a smaller set of tools, which is why turning things off is a more durable control than any wording you put above them.

Verification also stops at the moment of publication. Nothing in namespace authentication or the moderation policy constrains what a server does after you have connected to it, and the registry says as much when it declines to remove servers with security vulnerabilities and tells consumers to assume minimal-to-no moderation [3][4]. Your connector list is a set of standing authorisations that you granted on one afternoon under one set of assumptions, and nothing described in the documentation above will prompt you to look at it again. Put a recurring hour in the calendar for that review, because nothing else will produce it.

Then there is the part that scales badly for a small team. Every control described here assumes a person who reads approval dialogs, and the protocol’s own guidance identifies consent abandonment as a known failure, where users decline dialogs listing excessive scopes [2]. A solo operator running a handful of connectors is being asked to be the reviewer, the administrator and the incident response, usually while doing the work the connectors were supposed to speed up. The honest mitigation is not more vigilance. It is fewer connections, each with a smaller tool list, so that the prompts you do see are rare enough to still mean something.