This article is part of our MCP Guide: what the Model Context Protocol is, how to use it safely, and how to choose servers, tools and help. Want a second opinion on your setup? Request a free MCP readiness review.
An MCP RFP (request for proposal) is a short document that tells vendors what your Model Context Protocol server must do, how it must be secured and how you will judge their answers. Below is a template you can copy into a doc and fill in. It takes most teams an afternoon.
A clear RFP gets you comparable quotes. Without one, every vendor guesses at scope, and their prices are impossible to compare. It also forces your own team to agree on what the AI should and should not be allowed to do.
The template follows the current MCP specification, version 2026-07-28 as of October 2026. After the template, you'll find guidance on each section and a simple scoring sheet.
Key Takeaways
- Write the tool list first: each action the AI may take, whether it reads or writes, and who must approve writes.
- Ask every vendor the same security questions so you can compare answers line by line.
- Name the MCP spec version you expect and ask how the vendor will handle future versions.
- Require a testing plan that uses the official MCP Inspector or an equivalent.
- Ask for a support and maintenance price, not just a build price.
Before you write: three decisions
Make these calls inside your team first. They shape every other section.
- Local or remote? A local server runs on the user's machine over stdio (standard input and output). A remote server runs on the web over HTTP. Remote servers that need sign-in follow the MCP authorization spec, which is based on OAuth 2.1.
- Read or write? Read-only tools are lower risk. Write tools need limits, confirmations and audit logs.
- Who uses it? Your staff only, or customers and partners too? Customer-facing servers need tenant separation and stronger review.
If you can't answer these yet, ask vendors for a paid discovery phase instead of a full build. Our guide on build vs buy can also help you decide whether you need a custom server at all.
The MCP RFP template
Copy everything in the box below. Replace each [bracketed] item. Delete sections that don't apply.
MCP SERVER PROJECT: REQUEST FOR PROPOSAL
Company: [Your company name]
Contact: [Name, role, email]
Issued: [Date] Questions due: [Date] Proposals due: [Date]
Decision expected: [Date] Target launch: [Date or "flexible"]
1. ABOUT US
[Two or three sentences: what your company does, who your customers are,
and why you want an MCP server now.]
2. GOAL OF THE PROJECT
[One paragraph. Example: "Let our support team ask Claude or ChatGPT about
an order and get the status from our order system, without copying data
by hand."]
Success looks like: [2-3 measurable outcomes you will check after launch]
3. USERS AND AI CLIENTS
Who will use the server: [internal staff / customers / partners]
Approximate number of users: [number or range]
AI apps it must work with: [e.g., Claude, ChatGPT, VS Code, Cursor, other]
Deployment: [local (stdio) / remote (HTTP) / both]
4. SYSTEMS TO CONNECT
For each system:
- System name: [e.g., our PostgreSQL order database / HubSpot / Shopify]
- How we access it today: [REST API / SQL / SDK / other]
- API documentation: [link or "will share under NDA"]
- Test or sandbox environment available: [yes / no]
5. TOOLS (ACTIONS THE AI MAY TAKE)
List each tool. Vendors may suggest changes.
| Tool name (draft) | What it does | Read or write | Needs human approval? |
| [lookup_order] | [Find order by number or email] | [Read] | [No] |
| [refund_order] | [Issue refund up to $X] | [Write]| [Yes] |
Actions the AI must NEVER be able to take: [list]
6. RESOURCES AND PROMPTS (OPTIONAL)
Resources (read-only data the AI can load): [e.g., product catalog, policies]
Prompts (reusable templates for users): [e.g., "summarize this customer"]
7. SECURITY AND ACCESS
Please describe how you will:
a) Authenticate users (for remote servers: OAuth 2.1 per the MCP
authorization spec; for local servers: how credentials are stored).
b) Validate that access tokens were issued for this server, and avoid
passing client tokens through to downstream APIs.
c) Design scopes using least privilege (smallest set of permissions).
d) Keep each customer's or tenant's data separate.
e) Validate tool inputs and limit result sizes.
f) Treat content returned by tools as untrusted (prompt-injection risk).
g) Store and rotate secrets.
h) Log tool calls (who, what, when, result) without logging sensitive data.
Our compliance requirements: [e.g., SOC 2 controls, HIPAA, GDPR, none]
Data that must not leave our environment: [list or "none"]
8. HOSTING AND OPERATIONS
Where the server should run: [our cloud account / vendor-hosted / on-premise]
Our cloud provider: [AWS / Azure / Google Cloud / other]
Monitoring and alerting we expect: [describe]
Uptime or response-time target: [e.g., business hours only / 24x7]
9. TESTING AND ACCEPTANCE
Please describe your testing plan, including:
- Tests with the official MCP Inspector or equivalent.
- Tests with each AI client listed in Section 3.
- Security tests (auth failures, bad inputs, scope checks).
Acceptance: we will accept the work when [criteria, e.g., all tools pass
an agreed test script in our staging environment].
10. MCP SPEC VERSION AND UPDATES
Target spec version: 2026-07-28 (current as of October 2026), unless
you recommend otherwise and explain why.
Please explain how you will handle future spec versions, deprecated
features and changes in the AI clients we use.
11. DELIVERABLES
- Source code in our repository: [GitHub / GitLab / other]
- Setup and deployment documentation
- Tool reference (name, inputs, outputs, permissions for each tool)
- Automated tests
- Handoff session with our team: [number of hours]
- [Optional] Listing in the official MCP Registry or a directory
12. SUPPORT AND MAINTENANCE
Please quote a support option after launch, including response times
for critical and non-critical issues, and what is included
(bug fixes, security patches, spec updates, new tools).
13. YOUR PROPOSAL SHOULD INCLUDE
a) Your understanding of the project in your own words
b) Proposed tool list and architecture
c) Team: who will do the work, their roles and MCP experience
d) Examples of MCP servers you have built that we can inspect
(public repo, live server, or detailed write-up)
e) Timeline with milestones
f) Price: build (fixed / milestone / time and materials) and
support (monthly or per incident)
g) Assumptions and anything you need from us
h) Risks you see and how you would reduce them
i) Two client references we may contact
14. HOW WE WILL EVALUATE
[Share your weights, e.g.:]
Understanding of our goal ............ 15%
Security approach .................... 25%
Relevant MCP experience .............. 20%
Testing and handoff plan ............. 10%
Support and update plan .............. 10%
Price and value ...................... 20%
15. TERMS
NDA required before sharing: [yes / no]
We will own all code and documentation created for this project.
[Link to your standard contract terms, or "to be agreed"]How to fill in each section well
Goal and success measures
Write the goal as a task a person does today. "Support staff look up order status without switching tabs" is better than "AI-enable our support." Pick outcomes you can check, such as fewer copy-paste steps or faster lookups.
Tools
This is the most important section. Each tool is something the AI can do on its own once a user allows it. Keep the first version small. Start with read-only tools and add write tools after you see how people use it. Our article on MCP security risks explains why.
Security questions
The questions in Section 7 come from the spec itself. The security best practices page says MCP servers MUST NOT accept tokens that were not explicitly issued for them. It also recommends a "progressive, least-privilege scope model." A vendor who can't explain these in plain terms is a risk. For the background, see MCP authentication and OAuth 2.1.
Spec version
MCP versions are named by date. According to the versioning page, clients and servers may support several versions at once. Features marked deprecated stay in the spec for at least twelve months, or ninety days under an expedited security exception. Ask vendors how they track this.
Testing
The MCP Inspector is the official tool for testing servers. It has a web interface, a command-line mode for automated tests and a terminal interface. Asking for Inspector-based tests gives you something concrete to check at acceptance.
Registry listing
If you want outside AI users to find your server, ask for a listing in the Official MCP Registry. Our registry guide explains how listings work.
Scoring vendor replies
Use one sheet. Score each vendor 1 to 5 on each line, then multiply by your weights.
| Criterion | What a 5 looks like | What a 1 looks like |
|---|---|---|
| Understanding | Restates your goal and questions a risky tool | Copies your RFP back to you |
| Security | Explains token validation, scopes, logging in plain words | "Enterprise-grade security" with no detail |
| Experience | Shows a server you can inspect | Only general AI or chatbot work |
| Testing | Named test plan with Inspector and your AI clients | "We test everything" |
| Support | Clear response times and spec-update plan | Build price only |
| Price | Matches scope, assumptions listed | Low number, vague scope |
Red flags in replies:
- No named people, or the senior person disappears after the sale.
- No mention of how write actions are limited or approved.
- A claim to be an "official" or "certified" MCP partner. MCP is an open standard, and certification applies to people, not firms. See our MCPA certification guide.
Next step
If you'd like a second opinion on your draft RFP, or want us to respond to it, see our MCP development page. You can also read how to hire an MCP developer for interview questions to use after the written round.
Frequently asked questions
How long should an MCP RFP be?
Most are three to six pages. The tool list and security section matter most. Long boilerplate about your company slows vendors down without improving their answers.
Should I include a budget?
It helps. A budget range lets vendors propose the right scope instead of guessing. If you'd rather not share it, ask each vendor to price a "minimum version" and a "full version."
How many vendors should I send it to?
Three to five is usually enough to compare. More than that creates review work without much benefit. Include at least one freelancer or small firm if your scope is small.
Can I use this template for an MCP client, not a server?
Partly. Sections on goals, security, testing and support still apply. Replace the tools section with the servers your app must connect to and how users will approve connections.
What if we don't know which tools we need?
Ask vendors for a short, paid discovery phase. The output should be a tool list, an access model and a fixed price for the build. Then issue the full RFP.
