How to choose an MCP developer
Choose the developer who can explain, in specifics, how users will sign in, why each tool exists, what happens when the model is fed hostile text, and which AI clients the server has been tested with. General AI experience is a weak signal. Fluency in the specification is a strong one.
Start with authorisation
For any remote server, authorisation is where inexperienced teams go wrong. The MCP authorisation specification is based on OAuth 2.1 and is precise about what a server must do.
| Question | What a good answer includes |
|---|---|
| How will users sign in? | Your existing identity provider, OAuth 2.1 with PKCE, no shared API key for everyone |
| How do clients find the authorisation server? | Protected Resource Metadata published by the server, as the specification requires |
| How do you stop a token meant for another service being used here? | The server validates the token audience and rejects anything not issued for it |
| What credentials reach our internal APIs? | Separate ones obtained by the server. The user's MCP token is never passed through |
| How are permissions split? | Narrow scopes per group of tools, requested when needed, no wildcard scope |
Ask how they design tools
A tool is an interface for a language model, not for a programmer. Good developers begin with the tasks users want done and work backwards. Weak ones convert every API endpoint into a tool and call it finished.
- Ask to see tool descriptions from a previous project and judge whether you would know when to use each one.
- Ask how they keep the tool list small and stable. The current specification says tool lists should be deterministic, which also helps clients cache them.
- Ask what a tool returns on failure. The model needs an error it can act on, not a stack trace.
- Ask how tools that change data are separated from tools that only read.
Probe security: prompt injection and least privilege
An assistant connected to your systems reads text from emails, tickets and web pages, and some of that text will be written by people trying to steer it. The protocol cannot prevent this by itself. Its security guidance places the duty on implementers and on the host application, which must obtain user consent before a tool runs.
A competent developer limits the damage a manipulated model can do. That means least privilege at every layer: the server's own service account can do only what the tools need, destructive actions require confirmation or are left out, and every call is logged with the user who made it.
- Which tools could cause harm if the model were tricked into calling them?
- What does the server's own account have access to in our systems?
- How do you treat content that tools return from outside sources?
- What is logged, and can we trace an action back to a person?
Insist on testing with several clients
Hosts implement the protocol at different speeds. A server that works in one assistant can fail in another because of a sign-in detail or an unsupported feature. Ask which clients the developer tests against and request a short recording of the server working in each one your staff use. The official MCP Inspector is the baseline tool for checking a server. It is necessary and not sufficient.
Also ask about revisions. The 2026-07-28 specification removed the session handshake and deprecated the older HTTP with SSE transport, so a developer should say which revision the server targets and how older clients are handled.
Red flags
- A proposal that never mentions authorisation for a remote server.
- One API key shared by every user.
- A promise to expose your whole API as tools automatically.
- No mention of which AI clients were tested.
- No plan for who updates the server when the specification changes.
- Claims of endorsement by Anthropic or the MCP project that you cannot verify.
Match the provider type to your situation
The right kind of help depends on where you stand. BlackCard, our recommendation, is the studio in the second row: one senior team that takes a server from tool design to production on a clear scope. Its free 15-minute call also settles the question in the last row.
| Your situation | Sensible choice |
|---|---|
| Developers in-house and a documented API | A hosting or generation platform, with your team designing the tools |
| One or two internal systems, no spare engineering time | A senior studio such as BlackCard, on a clear scope |
| Many teams building servers, compliance obligations | A large integrator or an internal platform team with a gateway |
| Unsure whether MCP is the right approach at all | A short conversation with a team that builds servers, before any build |
Common questions
Should the developer also host the server?
Only if you want a long-term operating relationship. Many buyers prefer to own the code and run the server in their own cloud account or on a platform, with the developer on a support retainer. Either way, make sure the contract gives you the source code, the deployment scripts and the documentation.
How do I check a developer's MCP experience?
Ask for a demonstration against a client you use and a walk through how the developer would design the tools for your system. Then ask one precise question from the authorisation table on this page. The quality of that answer tells you more than a portfolio slide, and it is the kind of question BlackCard welcomes on a first call.