Connect MCP tools without losing track of trust

Connect an MCP tool with a clear record of which server receives the request and which account authorizes it. Before proceeding, identify whether the tool can read data, change it or both, and whether the token was issued for that service. A healthy connection is not enough to settle those access decisions.

The MCP introduction describes an open standard connecting AI applications with external data, tools and workflows. Standardizing that connection is valuable. Correct authorization still depends on the client, server and downstream services. This guide pairs that distinction with the documented Claude Code configuration, rather than assuming that registering a server establishes deployment security.

Trace the request before adding the server

An AI application uses an MCP client to communicate with an MCP server. The server may expose tools backed by another service. For a document lookup, the application requests a tool operation, the server handles it and the document service applies the permissions associated with the authorized account. Those steps cross different boundaries.

Keep protocol, transport and authorization separate. MCP defines how the integration communicates. A transport carries messages. OAuth, where used, governs the grant of access. The tool implementation determines what an operation actually does. A working message exchange does not establish that the correct account, permissions or token audience was selected.

Before installation, identify the server maintainer and its official endpoint. For a locally launched server, identify the executable and its provenance as well. A familiar service name is not evidence that an arbitrary package with a similar name is trustworthy. This matters particularly when the local process inherits access to your machine.

Start with a documented remote configuration

Claude Code’s documentation provides this Notion example:

claude mcp add --transport http notion https://mcp.notion.com/mcp

It registers an HTTP server under the name notion. This is a documented configuration example, not a command we ran for this guide. Before using it, confirm that Notion is the intended service and that connecting the account is authorized. Adding a server and granting it access remain separate decisions.

Transport options precede the server name. If you instead use JSON configuration, supply the appropriate type alongside the URL. The documentation explains that an entry containing a URL but no type is an error: without a type, Claude Code interprets the entry as a stdio server. Do not infer configuration syntax by combining unrelated examples.

Remote HTTP and stdio also imply different execution arrangements. With stdio, the client starts a local process and exchanges messages with it. That introduces trust in the executable and its machine access. Follow the server maintainer’s documented transport rather than swapping methods simply because another command looks convenient or resembles a previous installation.

Verify the account behind the connection

For a server using OAuth, follow the client’s authentication flow and check the account selected during consent. Inspect the connection through the client’s MCP management interface. A server appearing in configuration does not establish that authentication completed, or that the intended account is the one supplying access.

Read the requested permissions. The MCP security best practices recommend minimal scopes, with elevation when a privileged operation actually needs it. A document-reading workflow should not automatically receive every write capability in a service’s tool catalog. Broad access makes a connection easy to demonstrate while obscuring its consequences.

Token audience is another boundary. A server must validate that a token was issued for the appropriate resource. The security guidance rejects token passthrough: accepting a token meant for another service and forwarding it unchanged instead of establishing proper authorization for the MCP server. A token being technically accepted somewhere is not enough.

Intermediaries do not remove consent requirements

A server acting as a proxy for other services can encounter a confused deputy problem. In practical terms, a component with legitimate access is induced to act for a client that lacks the corresponding authorization. The security document examines risks involving client identification, consent and OAuth proxy arrangements.

For an implementer, this is a reason to verify the supplier’s handling of consent and token validation, rather than inventing a shortcut authentication flow. A familiar login page does not establish a correct relationship between the client requesting access, the resource receiving the request and the user granting permission.

For an integration user, the actionable boundary is simpler. Prefer the official flow, avoid moving tokens between unrelated services for convenience and keep secrets out of shared configuration. When credentials are required, use the maintainer’s recommended mechanism. A configuration that colleagues can review should not silently become a vehicle for distributing personal access.

Check a low-impact task before broad use

A suggested first exercise is reading a nonsensitive document whose contents you can verify manually. Compare the response with the original and check which account supplied access. Inspect whether the requested scope matches that task. These are proposed checks; we have not performed the lookup or certified a particular server here.

Then verify a negative case. A resource outside the granted permissions should remain unavailable. Do not work around that refusal merely to make the demonstration succeed. It provides evidence about the boundary the authorization was meant to preserve. If later work requires writing, evaluate that permission separately and begin with a reversible action in an appropriate environment.

1. Check retrieved content as external data. Keep instructions inside a document from redirecting the assistant beyond your request.
2. Trace the action back through the application, server and authorizing account. Confirm that the exposed operations stay within the grant; MCP provides access to the content, not authority for that content to control your session.