Bottom line up front
Treat every MCP server as a privileged service that acts with its own credentials, not the caller's. Before you connect one, record what tools it exposes and what each tool can reach, check which protocol revision it implements, decide which credential actually performs the action, and plan to re-read its tool descriptions on every session. Approval at install time is not approval at run time, so the evaluation has to be repeatable rather than a one-time check.
Start with what the server can reach, not what it claims to do
An MCP server is a program that runs tools and returns results to the model. The consequential question is not whether the tool is useful but what it can touch when it runs: which repositories, cloud accounts, databases, secrets, and file paths are reachable using the credentials it holds. Write that inventory down before you evaluate anything else, because a tool that reads a public API and a tool that can write to production are not comparable decisions.
The server executes with its own credentials rather than the caller's. That single fact changes the review: the permission set you are approving is the server's, and any user who can trigger the server inherits whatever it was granted. When a server's reach is wider than the workflow it was adopted for, the correct outcome is a narrower server, not a longer risk acceptance.
- List every tool the server exposes and mark each as read-only, write, or destructive.
- Record which credential performs each action and where that credential is stored.
- Write down what is reachable but not currently used, and why it is still granted.
Check which specification revision the server implements
The protocol has changed materially, and servers do not move in lockstep. The published MCP security guidance and the 2026 revision of the specification tighten authorization requirements and remove session-handling behaviour that earlier disclosures relied on. A server running an older revision can retain weaker behaviour long after the specification improved, so the version an approved server implements is part of the evaluation record.
Record the version alongside the approval date, and re-check it after any server update. A version that was acceptable at adoption may no longer describe what is running after an upgrade, which is exactly why the check belongs in a repeatable process rather than a one-time gate.
Treat tool descriptions as input, not documentation
Tool descriptions are read by the model, which makes them instructions. A description can be changed by a server update after the server was approved, and published guidance and independent research in 2026 have both described cases where a server behaved benignly during review and then altered its behaviour later. The practical consequence is that a server that was safe when you inspected it is not guaranteed safe on the next session.
That does not mean treating every server as malicious. It means scope: describe a server as reviewed as of a specific date and a specific version, prefer servers whose update history you can see, and keep the option to re-inspect. Where the workflow is sensitive, plan for runtime inspection of what a tool actually asks for rather than relying on the description alone.
- Record the server version and the date the description set was last reviewed.
- Prefer a pinned or vendored server over a remotely updated one for sensitive workflows.
- Decide in advance what you will do when a description changes, before it changes.
Make the approval something you can repeat
Published government and industry guidance converges on the same operational shape: inventory what is deployed, allowlist what is approved, grant least privilege, and log invocations with enough detail to reconstruct what happened. None of those controls is specific to one product, and none of them is satisfied by having reviewed a server once.
For most teams the honest starting point is a short list: one or two servers, an explicit record of what each can reach, a defined owner, and a date to revisit. A small governed set that you understand is easier to reason about than a large one you have approved in bulk. Oryxen's directory can help you discover candidate servers by category, but it cannot establish what a specific server is permitted to do in your environment.