Choosing an MCP server: trust and permissions

To choose an MCP server, first check who distributes it, what actions it can perform, and how its access will be restricted, monitored, and revoked. Prefer the server that meets your needs with the narrowest scope, whether it runs locally or remotely. Compatibility with your assistant and a popular repository are not enough to establish trustworthiness.

Start with the task and the access it requires

The MCP protocol lets a client application use capabilities exposed by a server. That server can query a service, read documents, or modify data. Installing it therefore gives your assistant an operational capability: your decision should start with the possible consequences of that capability.

Describe the task using a precise verb: find a procedure, review tickets, or prepare a change. Then specify the resources involved and the actions that are out of bounds. “Read tickets in the support project without posting comments” gives you a scope you can verify; “connect support to AI” leaves too many decisions unstated.

Also distinguish between suggesting an action and carrying it out. A server that can prepare a draft does not necessarily need permission to send it. Access to test data may be enough during evaluation, even if the eventual use involves production data.

The MCP server directory can help you identify candidates. Keep a brief record for each one: intended use, owner, source, hosting arrangement, accessible data, and removal procedure. This makes comparisons useful and prevents an integration installed for a trial from remaining connected without anyone responsible for it.

Establish the source and assess trust signals

Start with the service provider’s website or its organization’s repository to find the advertised integration. Then check that the repository, downloaded package, and remote server address actually belong together. A similar name, a familiar logo, or a polished description does not establish that connection.

The word “official” should have a clear meaning: published by the service provider, maintained by the protocol organization, or simply recommended in documentation. These arrangements do not carry the same responsibilities. For a community project, look for identifiable maintainers, an explicit license, and a channel for reporting vulnerabilities.

Stars mainly reflect a repository’s visibility. They may apply to a broader project rather than its MCP integration, and they tell you little about permission controls. Look instead at whether incidents receive a response, fixes are explained, and known limitations are documented.

The repository linked from the MCP reference servers overview illustrates this distinction: its documentation describes the software as educational examples rather than production-ready solutions. That status is stated in the official reference servers repository.

Finally, examine how the software is distributed. Traceable releases, maintained dependencies, and a clear update process make ongoing maintenance easier. None of these signals, taken alone, amounts to a security certification.

Compare local, self-hosted, and remote options

“Local” describes where a program runs, not every destination it communicates with. A process running on your computer can call an external API. Conversely, a remote server may be operated by your organization on a private network.

The documented standard transports include stdio, which connects the client to a subprocess, and Streamable HTTP, which carries messages over HTTP. Hosting and transport are separate choices, as explained in the MCP transport specification.

Criterion	Local process	Shared self-hosted server	Managed remote service
Operation	Runs on the user’s computer	Your organization’s responsibility	The provider’s responsibility
Access to monitor	Files, environment, and network access on the computer	Internal network, accounts, and user isolation	Connected accounts, transmitted data, and retention
Updates	Must be arranged across user computers	Can be centralized by the responsible team	Applied by the provider
Operational dependency	Computer availability and configuration	Internal infrastructure and team	Service availability and terms
Removal	Stop the process and revoke access	Disable the service and identities	Disconnect and revoke authorizations

Choose a local setup when access to resources on the computer is necessary and you can manage that access. Shared self-hosting makes sense when you can handle authentication, updates, and user isolation. For a managed remote service, ask for documented commitments on data handling and service continuity.

In every case, identify who can step in when a connection stops working or access needs to be removed.

Check compatibility in the client you actually use

An “MCP-compatible” label does not guarantee that every feature will be available in your application. Check the supported transport, authentication mechanism, exposed capabilities, and documented compatibility between the client and server. Use their current documentation rather than an old configuration example.

Pay particular attention to what the interface lets you control. You should be able to find the enabled tools, understand their parameters, and identify which operations require approval. An integration that works but hides these details makes oversight and troubleshooting harder.

Compare the available restrictions as well. Some servers offer tool groups or a read-only mode. The GitHub MCP server, for example, documents filtering by tool group and individual tool, along with a mode that disables write tools. These options are described in its official configuration documentation.

Verify that filtering works in your actual configuration. An option supported by the server may not be exposed by your client, or it may behave differently depending on how the connection is established.

Finally, keep a record of the tools that are actually visible after connecting. This list provides a baseline for reviewing updates. For application-specific setup instructions, see Install an MCP server in your assistant, which complements this selection process.

Restrict permissions at every layer

The principle of least privilege means granting only the permissions needed for a task. For an MCP server, this requires several checks: the tools offered to the model, the permissions of the connected account, and the process’s access to its environment.

Hiding a tool in the interface does not automatically remove permissions from the underlying account. Conversely, a read-only account may prevent certain writes even when a tool offers them. Look for consistent restrictions at every layer so that a configuration mistake cannot expand the entire scope of access.

For files, prefer a dedicated folder with appropriate operating system permissions. For a database, use an identity restricted to the objects the task requires. For a business service, separate test and production environments when that option is available.

Do not mistake a directory hint for isolation. The documentation for roots states that they guide the server rather than enforce access controls; this feature has been deprecated since the July 28, 2026 revision. Details appear in the official roots specification.

A local server is still a program running with permissions. Avoid passing it the computer’s entire environment or granting access to unrelated folders. The guide to securing an AI agent covers isolation and secret management in more detail.

Review authentication and trace the data path

Authentication establishes an identity; authorization determines what that identity can do. For a protected remote server, check how the client obtains access, which permissions it requests, and how the user can withdraw them. A successful connection does not prove that the permissions are proportionate to the task.

The MCP authorization specification describes the mechanism intended for HTTP transports. It distinguishes this from stdio, where credentials are normally retrieved from the environment. Do not assume that every MCP server automatically implements this specification: verify support explicitly.

Before providing a secret, identify who receives it and where it will be stored. Prefer an identity dedicated to the integration over a shared administrator account. Check expiration, rotation, and revocation, along with how the server behaves when the secret becomes invalid.

Then trace a piece of data through the full chain: source service, MCP server, client, model, and any logs. The server may filter a result, but content passed to the client may subsequently reach remote inference infrastructure. Hosting the connector locally therefore does not guarantee confidentiality throughout the chain.

For an external provider, ask where results are retained, who can view them, and how they are deleted. If those answers are unavailable, limit evaluation to fictitious data. Missing documentation is an uncertainty to resolve before granting access to sensitive information.

Treat results as untrusted data

A legitimate server can return malicious content found in a document, ticket, or web page. Trust in the software should not automatically extend to everything it reads. A prompt injection attempts to make external content appear to be an instruction the assistant should follow.

Evaluate combinations of capabilities as well. A tool that reads private documents and another that publishes externally can create a route for data leakage, even if they belong to different servers. Your review should cover all connections available within the same session.

For sensitive operations, the approval step should show the actual action: its destination, the data being sent, the objects being changed, and the extent of the change. A general approval at the start of a task cannot provide scrutiny of an operation whose parameters only become known later.

MCP documentation recommends making tools visible and allowing users to refuse their invocation. It also states that the protocol does not prescribe a single interface. These principles appear in the MCP tools specification.

Treat a “read-only” label with the same care: a description states an intended behavior, while an enforced permission makes that behavior a constraint. Check the controls in both the server and the source service. Checking MCP servers and skills before installation explores how to review integrations and suspicious content.

Run a pilot with clear rejection criteria

Before the pilot, prepare a dedicated account, fictitious data, an authorized scope, and a way to remove any objects created during testing. Define the expected outcome for each task. This will help distinguish a model misunderstanding from a problem with the server or its permissions.

Check the inventory. Compare the visible tools with the capabilities the task requires. Disable capabilities unrelated to the intended use.
Perform an authorized task. Verify the result in the source service, beyond the answer written by the assistant.
Attempt a prohibited operation. Request a write or access outside the authorized scope. The system should refuse without relying solely on the model’s judgment.
Introduce misleading content. Place a test instruction in a fictitious document and observe whether it triggers an action you did not request.
Revoke access. Check that a new operation fails, then restore only the permissions that are necessary.

Also test an interruption during a modification. If the client loses its connection after sending a request, the action may have completed even though its confirmation never arrived. Retrying without checking could then create a duplicate.

Record the relevant parameters, the observed result, and the limits of the test. A successful demonstration validates a scenario in a particular configuration; it does not guarantee every future use. Reject a move to production if essential restrictions remain unverifiable, actions cannot be supervised, or no one can revoke access.

Plan for maintenance, incidents, and total cost

Choosing a server also means taking on maintenance work. Assign responsibility for tracking fixes, approving configuration changes, and responding to incidents. An active repository does not replace that responsibility, and an automatic update can also change the available tools or requested permissions.

For a controlled installation, keep an identifiable version and a reproducible configuration. Plan how updates will be reviewed and tested, and how to return to a known configuration. Freezing the software indefinitely allows defects to accumulate; adopting every release without review makes it harder to determine which change caused a problem.

The official MCP security best practices cover risks involving local servers, authentication intermediaries, and network access, among others. Use them to ask maintainers which controls they implement. A statement of compliance alone is not evidence that those controls work.

Logs should help identify the identity used, the tool called, and the operation’s outcome, while avoiding unnecessary storage of secrets or complete documents. The guide to monitoring an AI agent in production explains how to organize this oversight.

Finally, compare the total cost: remote service fees, hosting, underlying APIs, model calls, and administration time. Measure result sizes and retries after errors as well. A server without a subscription may require more operational work; a managed service may reduce that workload while introducing a contractual dependency.

Common problems and the final decision

A connected server with no usable tools may indicate a compatibility issue, filtering, or insufficient permissions. Compare the documentation with the logs before granting broader access. Expanding permissions until the problem disappears makes its cause harder to understand.

If an operation appears to fail, first check the state of the source service. A transport error does not necessarily mean the action was canceled. For significant changes, require an appropriate procedure for verification and recovery.

When an update adds tools, reassess their usefulness before enabling them. If an integration becomes essential while its maintenance remains uncertain, prepare an alternative or reduce its responsibility within the process.

The decision can be accepted, accepted with restrictions, or rejected, with reasons and conditions for reassessment. A blocking issue should not be obscured by an average of otherwise favorable criteria.

Before connecting real data:

The source of the server, package, or remote address has been established.
The intended task, responsible owner, and prohibited actions are documented.
Permissions are restricted in both the server and the source service.
The data path and retention arrangements are understood.
Prohibited operations and access revocation have been tested.
Someone is responsible for updates, incidents, and removal.

The right choice is a server whose access you can explain, whose limits you can verify, and whose maintenance you can sustain for as long as you use it.

Frequently asked questions

Is an official MCP server always safe?

An official source helps you identify who is responsible for the software, but it does not guarantee that the server has no vulnerabilities or that its configuration fits your needs. Focus on which permissions it requires and how you can revoke them.

Can I use an MCP server without giving it an API key?

Yes, if its features do not require an authenticated service, such as when processing certain local files. Having no API key does not mean having no permissions: the process may still inherit the access rights of its operating system account.

Should I use a local MCP server for confidential documents?

Running locally can reduce the number of intermediaries, but you still need to trace the full data path. Excerpts returned to the client may then be sent to a remote model, even when the MCP server runs on your computer.

How can I tell whether an MCP server is still maintained?

Look at fixes, responses to reported issues, and documented compatibility rather than relying on the date of the latest commit. A stable project may change infrequently, while a busy repository can still leave security issues unanswered.

What should I do if an MCP server requests more permissions?

Compare the additional permissions with the features actually being added, and hold off on granting broader access while you review them. If the need is not justified, keep the existing scope or choose another integration.

Choosing an MCP server: trust, maintenance, permissions, and local or remote hosting