How to evaluate an MCP server before you connect it
Choosing an MCP server is mostly a permissions question, not a features question. Any server can list impressive capabilities; what separates them is what proportion of those capabilities can change something, whether a human sits between a decision and its effect, and how quickly you can take access away.
There is no shortage of directories ranking servers by popularity. This page ranks by the five questions that actually determine whether connecting one to a business is a good idea.
The five questions
Adapted from how security teams evaluate any third-party integration, narrowed to what is specific about handing tools to a model.
- What proportion of the tools can change something? Ask for the breakdown, not an assurance.
- Where does human approval sit — before the effect, or in a log you read afterwards?
- How narrowly is access scoped, and what happens if a call names a different tenant?
- How do I revoke it, how fast does that take effect, and do credentials expire on their own?
- Where does the data come from, and does a response tell you how fresh it is?
A vendor who can answer all five in specifics has built the thing carefully. A vendor who answers in adjectives has told you something too.
Sort servers by what they do to your systems
A more useful taxonomy than category directories, because it maps directly onto risk.
| Type | What it does | Risk if it misbehaves | What to check hardest |
|---|---|---|---|
| Reference | Reads public or static material | Low | Whether answers are grounded and current |
| Read-only business data | Reads your private systems | Disclosure | Scope, tenant isolation, revocation |
| Proposal | Prepares changes for a human to approve | Low — nothing executes | Whether the approval step can be skipped |
| Execution | Changes live systems or spends money | High, and proportional to reach | Scope gating, approval, rollback, verification |
| Mixed | All of the above in one surface | Depends entirely on the split | Ask for the census — this is where numbers matter |
Red flags worth walking away from
- No published authorization model, or a single shared static token as the only option
- No answer to what proportion of tools can write
- Approval that can be turned off, or an assistant that can approve its own proposals
- No way to revoke a single connection without disabling everything
- Responses with no indication of where a figure came from or when it was true
- Write access granted by default on first connection
- A tool named as though it acts, whose description reveals it does something else entirely
That last one is worth checking directly rather than trusting names. Tool names are marketing surface as much as engineering surface, and reading the descriptions catches mismatches quickly.
Green flags
- OAuth with PKCE and discovery metadata you can fetch yourself
- Scopes enforced centrally, with refusals that name the missing scope
- A published safety classification of the tool surface
- Read-only as the default posture, with write requiring explicit grant
- Verification after execution — the server re-reads the object rather than trusting the provider's acknowledgement
- Credentials that expire without anyone remembering to remove them
- Freshness metadata on read results
Worked example: Zylx's own answers
So this is not abstract, here are the answers to the five questions for the server we run. The point is the form of the answer, which is what you should expect from anyone.
| Question | Answer |
|---|---|
| What can change something? | Of 923 tools observed on 2026-08-09: 708 read-only or diagnostic, 107 write proposals into an approval queue, 11 decide approvals, 87 execute, 10 roll back. |
| Where does approval sit? | Before the effect. Consequential changes become queue items a human decides; approval tools refuse a machine identity, so an assistant cannot approve its own proposal. |
| How is access scoped? | To one workspace. A call naming a workspace the credential is not authorized for is refused, not honoured. |
| How do I revoke it? | Revoke the token or disconnect the OAuth grant; access ends immediately. Tokens also expire after 90 days on their own. |
| How fresh is the data? | Read results carry a freshness envelope: source, observation time, and whether it needs re-checking. |
Frequently asked questions
What is the best MCP server?
There is no single best one, because servers do unrelated jobs. The better question is which server is safe and useful for your case, which comes down to what proportion of its tools can change something, whether a human approves consequential actions, how narrowly access is scoped, and how quickly you can revoke it.
Are MCP servers safe to connect?
It depends entirely on the server, not the protocol. A read-only reference server carries very little risk. A server that can write to your store or spend money carries real risk, and should be evaluated on its permission model rather than its feature list.
How many MCP servers should I connect?
As few as answer your questions. Every connection is an authorization surface and a source of context competing for the model's attention, so more connected servers is not automatically better.
How do I know what an MCP server can actually do?
Read the tool list and the tool descriptions rather than the marketing page, and ask the vendor for a breakdown by what each tool does to your systems. Names can overstate; descriptions rarely do.
What should a vendor be able to tell me?
The proportion of tools that can write, where human approval sits, how access is scoped and what happens on a mismatch, how revocation works and how fast, and whether responses carry provenance. All five are answerable in a paragraph.
Evaluate ours with the same five questions
The tool census, the approval model and the authorization metadata are all published rather than described.
MCP security in depthWhich AI apps connectThe Zylx MCP serverMCP explained for operators
Sources
- Model Context Protocol specification and documentation
- Anthropic: security considerations for custom connectors
Zylx product details verified against the live implementation on 2026-08-09.