How to Evaluate an MCP Server Before Connecting It

To evaluate an MCP server, check five things before you connect it to anything real: who publishes it, which tools it exposes, how it authenticates and what access it asks for, how actively it is maintained, and how it behaves in a read-only test. If you cannot answer one of these, do not connect it to a live store, ad account or customer list.

MCP (Model Context Protocol) is an open protocol that lets AI assistants such as Claude connect to external tools and data. An MCP server is the piece that exposes those tools. Anyone can publish one, so "it works with my AI app" says nothing about whether it is safe for your business.

This guide is written for merchants and agencies, not developers. Where a step needs technical help, it says so.

What do you need before you start?

• A clear purpose. Write down one task, for example "read last month's Google Ads spend by campaign". A vague goal leads to vague permissions.
• The name of the account you would connect, and a way to limit it (a separate user, a read-only role, or a test account).
• Someone who can read the server's documentation and, for open-source servers, its code repository. This can be an agency, a freelancer or your developer.
• Your AI client's settings, so you can see which servers are connected and which tools are enabled.

Why does an MCP server need evaluating at all?

The official MCP security guidance warns that MCP servers run with the same privileges as the client that connects to them. A local server installed on your laptop can in principle reach what your user account can reach. A remote server holds the access token you grant it.

Real incidents show this is not theoretical:

• Anthropic's own reference Git MCP server had three vulnerabilities (CVE-2025-68143, 68144 and 68145) disclosed in January 2026, covering path traversal, argument injection and a repository-scoping bypass. They were patched.
• Security researchers have reported command injection bugs in servers published by large cloud vendors, according to a Trend Micro write-up. Brand size does not replace a review.
• In October 2026 a flaw in the OpenCode client was reported that let a malicious or hijacked MCP server run code on a developer machine at sign-in. It was fixed in a later version. The risk runs in both directions: a bad server can attack the client.

Treat these as examples of why you check, not as a ranking of which vendors are unsafe. Details should be verified in the original advisories.

Step 1: Who publishes this server, and can you verify it?

Start with provenance, meaning where the server comes from.

1. Identify the publisher. Is it the platform itself (Shopify, Google, Klaviyo, Stripe) or a third party wrapping that platform's API?
2. Find the vendor's own documentation page that links to the server. If the vendor does not mention it, treat it as unofficial.
3. For open-source servers, open the repository. Look at the number of maintainers, the date of the last commit, open security issues and whether releases are tagged.
4. Be wary of lookalike names, copied READMEs and servers that ask you to run a one-line install command from an unfamiliar source.

An unofficial server is not automatically bad. It simply needs more scrutiny, because you are trusting an unknown party with your credentials.

What does the MCP registry tell you?

The official MCP Registry (at registry.modelcontextprotocol.io) is a public catalog of servers, backed by contributors that include Anthropic, GitHub, PulseMCP and Microsoft. It is useful for discovery, but read its limits:

• It was in preview when this article was researched, and its docs warned that breaking changes or data resets may occur before general availability. Check the current status on modelcontextprotocol.io.
• A listing mainly verifies namespace ownership. Names beginning with io.github. require GitHub authentication, and domain-based names require DNS or HTTP verification. That tells you the publisher controls the name, not that the code is safe.
• Security scanning is not part of the registry. It is left to package registries and other aggregators.
• It is not designed for private servers. Organizations that need a private catalog can run their own registry using the same API.

In short: a registry listing is a starting point for finding the publisher, not a safety certificate. This also applies to other directories and marketplaces.

Step 2: What tools does the server expose?

Every MCP server publishes a list of tools, each with a name, a description and inputs. Read the full list.

• Sort each tool into read (fetch reports, list products) or write (change budgets, edit products, send emails, issue refunds).
• Count them. A server for "reporting" that exposes dozens of write tools is not a reporting server.
• Read the descriptions. Tool descriptions are text the AI reads and follows, so a poisoned description can steer the assistant. The OWASP MCP Security Cheat Sheet advises treating the entire tool schema as an injection surface, and pinning reviewed tool definitions so that any change requires review.
• Disable tools you do not need if your client allows it.

For background on how write access changes the risk, see MCP Permissions: Read-Only vs Read-Write for Ads and Stores.

Step 3: How does it authenticate and what access does it request?

For remote servers, the MCP specification bases authorization on OAuth 2.1, the same sign-in pattern as "Log in with Google". When you connect, you should see a consent screen listing what you are granting.

Check:

• Does it use OAuth sign-in, or does it ask you to paste a long-lived API key or password into a config file? OAuth with limited scopes is generally preferable.
• Are the requested scopes (permissions) narrow? Ask for read-only scopes where the platform offers them.
• Is the account you are connecting the minimum needed? Use a dedicated user with a restricted role, not the owner login.
• Where are secrets stored? A Trend Micro analysis reported that 48% of more than 19,000 MCP server codebases it reviewed recommended storing secrets in insecure .env files or plaintext JSON. Ask where keys end up on your machine.
• Can you revoke access easily, from the platform's connected apps page?

Note that a US NSA security information sheet on MCP (May 2026) points out that servers rely on OAuth bearer tokens without protocol-level management of refresh, revocation and reuse. Revocation is therefore something you should test on the platform side, not assume.

Step 4: Is it local or remote, and does that change the risk?

	Local server (runs on your computer)	Remote server (hosted by a vendor)
Connection	stdio, started by your AI app	HTTP, with sign-in
Main risk	Code runs on your machine with your privileges	Token and data held by a third party
What to check	Source code, install method, sandboxing	Vendor identity, scopes, data handling terms
Good practice	Run in a container or separate user profile	Use a restricted account, review connected apps

Local servers deserve extra care because installing one is running someone else's software. A command-execution issue affecting stdio-based setups was reported in 2026 across several official SDKs. Confirm the current status in the original report before relying on any claim about it.

Step 5: How well is it maintained?

• Look for a changelog, tagged releases and a security contact or disclosure policy.
• Search the name plus "CVE" or "vulnerability". Past bugs that were fixed quickly are a better sign than silence.
• Check which MCP specification revision it supports. Newer revisions have changed authorization and removed or deprecated some features, and many tutorials are out of date. Compare with the revision your AI client supports on modelcontextprotocol.io.
• Check that the server is pinned to a version you reviewed, so an automatic update cannot change its behavior unnoticed.

Step 6: How do you test it safely?

1. Use a test account, a staging store or a read-only user.
2. Connect the server to one client only.
3. Start with simple read questions where you already know the answer, and compare the results with the platform's own reports.
4. Watch whether the assistant asks for approval before each tool call, and keep that approval prompt switched on.
5. Check the platform's activity or audit log to see exactly what the server did.
6. Try a harmless prompt-injection test, such as a product description that says "ignore previous instructions", to see how the assistant reacts. Our article MCP Prompt Injection in E-commerce and How to Reduce It covers this in more depth.
7. Only then decide whether any write tools are justified, and enable them one at a time.

Is this MCP server safe? A quick checklist

Use this as an MCP server checklist and keep a copy for each server you approve.

• Publisher identified and linked from the vendor's own documentation
• Source code or security documentation reviewed by someone qualified
• All tools listed and classified as read or write
• Unneeded tools disabled
• OAuth sign-in with narrow scopes, or keys stored securely
• Dedicated, restricted account used
• Version pinned and changelog monitored
• Read-only test passed against known numbers
• Human approval kept on for every tool call
• Revocation steps written down and tested
• Review date set (for example every quarter)

If you cannot tick most of these, the honest answer to "is this MCP server safe" is "not yet".

What can go wrong even after a review?

• Tools change after approval. A server can update its tool descriptions later. Pin versions and re-review on change.
• Prompt injection through your own data. Reviews, support tickets and product text can contain instructions that an assistant may follow. A safe server does not make the content it reads safe.
• Scope creep. Access granted for a one-off task stays in place. Remove connections you no longer use. The OWASP MCP Top 10 (still a beta project) lists scope creep and shadow, unapproved servers among the main risks.
• Over-trusting the registry or a big brand. A listing proves namespace ownership, and a large vendor can still ship bugs.
• Staff connecting servers on their own. Agree a short approval process, especially in agencies handling many client accounts.

For a wider merchant view, read MCP Security: Is MCP Safe for Your Store? A Merchant Checklist.

When should you ask a specialist?

Ask a developer or security professional if the server runs locally with broad system access, if it handles customer personal data or payment information, or if you plan to enable write tools. For simple read-only reporting against a restricted account, the steps above are usually enough to make a reasonable decision, but this article is general guidance, not a security audit.