Ask four things, in this order: who can call the server, what it can read, what it can do, and what you can prove afterwards. Twelve questions cover them. For each one, there is an answer that closes the point and an answer that leaves it open; a reviewer needs to recognise the difference, not to be an MCP specialist.
The grid applies to any vendor of an MCP server, DeployIt included. We state what ours answers at the end, and where our public pages stop. We read the MCP authorization specification (revision 2026-07-28) on 14 October 2026 for the points that rest on it.
Why a grid, and why now
An MCP server gives an AI agent a set of tools to call. The agent, not a person, chooses what to ask and when. A classic integration review assumes a developer wrote every call in advance. Here nobody did.
So the review changes shape. It is less "what can this endpoint do" and more "what can anyone, or anything, make it do". A one-line definition for the record: an MCP server is a program that exposes tools and data to AI agents through a standard protocol. The plain-language explanation covers the rest.
Block 1: who can call it
Everything else depends on this block.
1. How does a caller authenticate? Closes the point: an OAuth access token on every request, an unauthenticated request answered with 401. Leaves it open: a static key in a URL, or "the endpoint is hard to guess". Details of the flow are in how an agent authenticates to an MCP server.
2. Is a token bound to this server? The specification requires the server to accept only tokens issued for itself, and not to pass a token on to another service. Closes the point: the vendor names the audience check. Leaves it open: "we use industry-standard tokens".
3. Can you cut one caller without touching the others? Closes the point: yes, per requester, and the vendor says what happens to the grant behind the token. Leaves it open: "rotate the shared secret".
Block 2: what it can read
4. Which sources does the server read, and with what scope? Closes the point: a list, and a read-only scope for each. Leaves it open: "access to your repositories", with no mention of the permission level.
5. Does any credential to the source ever reach the caller? Closes the point: never, the server holds it. Leaves it open: the agent receives a token and talks to the source itself.
6. Does a caller see a slice, or everything the server can read? Closes the point: one server per project, so the boundary is the project. Leaves it open: one server for the whole account, filtered "in the prompt".
7. Where does the data travel, and who processes it? Closes the point: a sub-processor list you can ask for, a stated hosting region, and a stated position on model training. Leaves it open: a privacy page that does not mention the model provider. The data-flow article shows what to look for.
Block 3: what it can do
8. Can any tool change something? This is the question people forget. Closes the point: no tool writes, and the vendor can list them. Leaves it open: "mostly read-only". A single write tool changes what a hijacked agent can do.
9. What happens when a retrieved text contains instructions? Source files and commit messages are text, and text can address the agent. Closes the point: the vendor explains that the server returns answers and the caller's agent treats them as data, and what the server does itself about content it retrieves. Leaves it open: "the model is trained to ignore that".
Block 4: what you can prove
10. Can you see who asked what? Closes the point: a log per requester, available to you. Leaves it open: logs "available on request" with no stated content.
11. What does revoking access leave behind? Closes the point: a precise list. Leaves it open: "everything is deleted" with no mention of caches, logs or derived data.
12. Which of these guarantees exist today, and which are plans? For a product in early access, this one carries the most weight. Closes the point: a written split between "in production" and "intended". Leaves it open: the roadmap told as if it were the present.
The grid as a conversation
The questions work better said aloud. A shortened exchange, labelled illustrative and with no real vendor behind it:
- Reviewer: "A caller sends a request with no token. What comes back?"
- Vendor: "A
401, with a pointer to our metadata." - Reviewer: "And a token issued for another of your services?"
- Vendor: "Refused. The audience must match."
- Reviewer: "Is there any tool that writes?"
- Vendor: "None today. Two are planned, and they will be opt-in."
Notice the last line. A vendor who volunteers what is planned is easier to trust than one who has nothing to add. It is also the answer to question 12, given for free.
How to score the answers
Do not add up a number. Three states are enough.
- Settled: the answer is specific and checkable.
- Open: the answer is plausible but cannot be checked yet. Write down who will check it, and when.
- Blocking: the answer is missing, or it contradicts the vendor's own pages.
One blocking item on blocks 1 to 3 stops the integration. An open item on block 4 alone usually does not, if the server is read-only and the data is public to your team anyway. That is a judgement for your policy, not a rule of the protocol.
What ours answers, and where it stops
DeployIt's MCP server is in early access, through a design partner program. It reads your real code (resynchronised on every push) and your git history through a read-only GitHub connection, one server per project, and that connection is revocable at any time. The agent that calls it never holds a GitHub credential. That covers questions 4, 5 and 6 and part of 8. These points are also described on the security page and in the access model.
What our public pages do not state: token lifetimes, refresh rules, exact revocation timing, the log format for question 10. Ask us for them in writing before you rely on them. That is question 12 applied to ourselves.
If you want to run the grid against a real server, the design partner program is open. DeployIt is free during early access; paid plans arrive in January 2027.
Frequently asked questions
What should a security team ask an MCP server vendor?
Four things, in this order: who can call the server and how that access is cut, what the server can read and where that data goes, what it can do beyond answering, and what evidence you can get afterwards. Twelve questions cover them.
Is an MCP server riskier than a normal API?
Not by nature. The difference is the caller: an AI agent decides at runtime what to ask, so the server must be safe against requests nobody planned. A server that only answers, read-only, is the smallest version of that risk.
Do I need a certification to connect an MCP server?
That is your policy to set. A certificate says something about a vendor's organisation; it says nothing about what one server can read. Ask for both the certificate your policy requires and the answers to the twelve questions.
Should the review treat an early-access MCP server differently?
Yes: ask what is stable and what is not. A vendor in early access should say which guarantees exist today, in writing, and which are intentions.
Continue reading
How do you connect Cursor or Windsurf to your product knowledge?
Both editors accept a remote MCP server from one JSON entry. Here are the two entries side by side, as the docs stated them on 13 October 2026, and what an editor can ask a product expert that it cannot ask the open file.
What should you expose when you build an MCP server on your own SaaS?
The catalog of an MCP server is a product decision, not an export of your API. Three questions sort what an outside agent should be able to call.
Why does my AI agent give wrong answers about our API after a release?
An agent plugged into your API documentation answers with the API as it was last documented. After a release, the gap is invisible to it. What to hand it instead.