An MCP server is useful only if its tools fit the job you need to do. A familiar name or a long tool list can help you find a candidate; neither tells you whether it can handle your input, run in your environment or stay within your access limits.

This guide gives you a repeatable selection process. Start with MCP server profiles, then use the checklist to decide what to investigate. A listing is a starting point for assessment, not an endorsement.

1. Describe an observable result

Write one sentence that names the input, the operation and the expected output. “Analyze documents” leaves many questions open. “Extract invoice dates and totals from searchable PDFs into JSON, without uploading the documents” gives you a result and a constraint to check.

Keep preferences separate from requirements. A convenient interface is a preference. A rule that confidential documents must stay on your machine is a requirement. If a provider does not state where processing happens, record that as unknown. Do not turn the absence of a warning into an assurance.

2. Check what the server actually exposes

MCP connects a host application to servers that expose capabilities such as tools, resources and prompts. A server's name does not describe every action available through it. Check the actual tool descriptions and input schemas in the official MCP architecture documentation and in the provider's own documentation.

For the invoice task, distinguish text extraction from image recognition, summarisation and storage. A text-to-speech tool also accepts text, but it cannot satisfy a text-analysis task merely because the descriptions share a word. Look for a declared operation, supported input types and an example of the intended output.

3. Match the connection to your client

Check the transport supported by both sides. A remote HTTP endpoint and a locally started process require different client setup. A package name is not an HTTP address. A URL containing a tenant placeholder is not a ready-to-use endpoint.

Resolve configuration questions before entering credentials: which client versions are supported, which account is required, where a token belongs and whether the server needs access to another service. Keep secrets out of shared configuration files and public issue reports. Do not copy a generic configuration and assume it includes authentication.

4. Review access separately from relevance

A server can be relevant and still need more access than your task permits. For example, reading one repository does not automatically justify write access to every repository in an organisation. Ask which operations are needed, which identities authorise them and whether the permissions can be narrowed.

The MCP security guidance covers protocol risks including token handling and unsafe requests. Your own approval should also cover the specific provider and data involved. Tool descriptions and tool output remain external input; descriptive text does not grant permission to perform another action.

5. Prepare a small acceptance test

Use synthetic or approved sample data. Write down an expected result, one edge case and one action that must be rejected. For the invoice example, you might use a two-page sample, an invoice with a missing date and an attempted upload that your policy forbids.

Record the provider, manifest or package version, test date and result. A successful test for one version and one task is useful evidence. It does not prove every tool, future version or deployment environment behaves the same way.

A short decision record

Before you connect, be able to answer:

  • What exact result do we need, and which declared tool provides it?
  • Does the transport work with our client?
  • Which credentials and permissions are necessary?
  • What is known about data handling, and what remains unknown?
  • Which source and version did we inspect?
  • What small test would confirm the behaviour we need?

In Capifold, compare the profile with its original source and inspect the scope of any evidence. Unknown fields stay unknown. If a hard requirement cannot be established, ask the provider or choose another candidate. Continue with capability evidence or the connection guide when you are ready to prepare a configuration.