This article is part of The MCP Guide, our plain-English reference on the Model Context Protocol.
A 30-day MCP pilot plan is the document that decides, before anyone connects anything, what the pilot will test, who approves each step and what result means go, adjust or stop. It covers one workflow, starts read-only and ends with a written decision. Without it, pilots drift, and the final call comes down to opinion.
This page gives you the plan itself: a charter to copy, a sign-off table, gates at set days and decision rules. For the hands-on admin steps in Claude and ChatGPT, such as adding connectors and setting tool permissions week by week, use our pilot rollout playbook. The two work together.
Any numbers below that look like targets are HYPOTHETICAL examples. Set your own from your baseline.
Key Takeaways
- Write the charter, success measures and stop rules before day one, and have the business sponsor sign them.
- Pilot one workflow with one team, and keep every server read-only or approval-only for writes.
- Use three gates: a readiness gate before launch, a safety check at day 10 and the decision at day 30.
- Name one person who can switch a connector off at any time, without asking anyone.
- The day-30 decision is go, adjust or stop, written down with the evidence behind it.
The one-page pilot charter
Copy this into a doc. Fill in every bracket before the readiness gate.
MCP PILOT CHARTER
Pilot name: [e.g., Weekly client report, read-only]
Dates: Day 1 = [date] Day 10 check = [date] Day 30 decision = [date]
1. WORKFLOW
Task being piloted: [one task, as people do it today]
Team: [team name, number of people]
Baseline (measured before Day 1): [hours per week, error/rework count]
2. SCOPE
AI app: [e.g., Claude Team / ChatGPT Business]
MCP servers: [name, publisher, hosted or local, for each]
Allowed: [read actions the AI may take]
Writes: [none / drafts only / named writes with approval each time]
Out of scope: [systems and data that stay disconnected]
3. SUCCESS MEASURES (set now, not after)
| Measure | Baseline | Go if | Stop if |
| [Time per task] | [ ] | [ ] | [ ] |
| [Share of AI results accepted without major edits] | n/a | [ ] | [ ] |
| [Errors or rework] | [ ] | [ ] | [ ] |
| [Unexpected writes or access] | 0 | 0 | 1 or more |
4. PEOPLE
Business sponsor (final decision): [name]
Pilot lead (runs it day to day): [name]
Security / IT reviewer: [name]
Kill-switch owner (can disconnect at any time): [name]
Champions in the team: [names]
5. STOP RULES (pilot pauses at once if any happen)
- [A write happens without the expected approval]
- [The AI reaches data listed as out of scope]
- [A server asks for scopes beyond what was approved]
6. SIGN-OFF
Sponsor: ______ Date: ____ Security: ______ Date: ____Choosing the workflow
Pick a task that is frequent, low risk and easy to check. Good first choices summarize, look up or draft. Poor first choices send money, delete records or touch payroll and HR files.
Two quick tests help:
- Can a person check the result in under five minutes? If not, you can't judge quality during the pilot.
- Would a wrong answer be cheap to fix? If not, it isn't a pilot task yet.
Then confirm each server is fit to use. Our server selection checklist covers who publishes it, how it logs in and whether it can write.
Read-only first, and why
Start every server read-only, or with approval required for each write. The MCP tools specification says there "SHOULD always be a human in the loop with the ability to deny tool invocations." It also says clients should "log tool usage for audit purposes." A pilot is the place to prove both work before anyone relies on them.
Most business AI apps give you controls for this. In Claude, Anthropic's connector docs say an Owner adds a connector for a Team or Enterprise organization, and each connector's Tool permissions can be set to Always allow, Needs approval or Blocked. Set write tools to Needs approval or Blocked for the whole pilot.
Ask for the smallest access the workflow needs. The official MCP security best practices recommend starting with a minimal scope set of "low-risk discovery/read operations" and adding more only when needed. If a server's sign-in screen asks for far more than that, write it down. It may be a reason to stop.
Who signs off, and when
Each gate has an owner. Keep the list short so decisions don't stall.
| Decision | Responsible | Approves | Consulted | Informed |
|---|---|---|---|---|
| Charter and success measures | Pilot lead | Business sponsor | Team, IT | Leadership |
| Servers and scopes | Pilot lead | Security / IT reviewer | Vendor docs | Sponsor |
| Readiness gate (before Day 1) | Pilot lead | Sponsor and security reviewer | Champions | Team |
| Day 10 safety check | Security / IT reviewer | Security / IT reviewer | Pilot lead | Sponsor |
| Pausing the pilot | Kill-switch owner | No approval needed | None | Sponsor, pilot lead |
| Day 30 decision | Pilot lead | Business sponsor | Security, team | Leadership |
The kill-switch owner matters most. Anyone in the team should know who that is and how to reach them.
The 30 days, by gate
Before Day 1: readiness gate
Don't start until all of these are true:
- The charter is signed.
- The baseline is measured, not estimated. Two weeks of timings is a reasonable minimum.
- Each server is connected by an admin, with write tools blocked or set to need approval.
- Logging is on and someone has checked they can read it. Our MCP audit logging guide covers what to keep.
- The team has a one-page usage rule. Our AI and MCP acceptable use policy has a template.
Days 1 to 10: read-only run
The team uses the AI for the workflow every time it comes up. The pilot lead collects examples of good and bad results.
Day 10: safety check
The security reviewer reads the logs and answers four questions:
- Did any write happen without the expected approval?
- Did the AI reach any out-of-scope data?
- Did any server ask for new scopes or show new tools?
- Did anyone connect a server that isn't in the charter?
Any "yes" is a stop rule. Pause, fix and restart the clock if needed. If all four are "no," continue.
Days 11 to 25: steady run
Keep measuring. If the sponsor approves it in writing, you may allow one named write action with approval each time, such as saving a draft. Don't add new servers during this phase, or the results stop being comparable.
Days 26 to 30: decision
Pull the numbers, compare them with the baseline and write the decision.
Success measures
Choose four to six measures and set the thresholds before Day 1. Where usage data helps, Anthropic's usage analytics article says Claude Team and Enterprise dashboards show connectors "including the number of users, plus counts of read and write actions." That can confirm what the team reports.
The thresholds in this table are HYPOTHETICAL examples, not benchmarks. Use your own baseline and your business case break-even.
| Measure | Source | HYPOTHETICAL go threshold |
|---|---|---|
| Time per task | Timed sample vs baseline | At least your break-even reduction |
| Results accepted without major edits | Pilot lead's review log | 8 in 10 or more |
| Errors or rework | Review notes vs baseline | No higher than baseline |
| Unexpected writes or out-of-scope access | Logs | Zero |
| Active use | App analytics | Most of the team, most weeks |
| "Would you keep using this?" | Short team survey | Most say yes |
Go, adjust or stop
Write the decision in one of three forms. Attach the measures table.
| Decision | When to choose it | What happens next |
|---|---|---|
| Go | Every go threshold met, zero safety findings | Expand to a second team or add one write action. Add the servers to your approved list. |
| Adjust | Safe, but a measure missed by a fixable cause, such as poor prompts or a missing tool | Run one more 30-day cycle with the change named in writing |
| Stop | Any unresolved safety finding, or time savings well below break-even with no fixable cause | Disconnect the servers, record what you learned and close the pilot |
A stop isn't a failure. It saves you from funding a rollout that wouldn't pay back. For measuring results after a go, see our ROI measurement playbook.
Next step
If you want help choosing the pilot workflow, checking server scopes or setting thresholds, our MCP readiness audit covers all three. If the pilot shows you need a server that doesn't exist yet, see eSEOspace MCP development.
More in the MCP Guide
Latest research: State of MCP: October 2026
Frequently asked questions
Why 30 days?
It is long enough to cover four weekly cycles and short enough to keep attention. A monthly task needs a longer pilot, because 30 days gives you only one run. Match the length to how often the task happens.
Who should be the business sponsor?
The person who owns the budget for the team doing the workflow. They make the day-30 call, so they should sign the charter and agree on the thresholds up front.
Can we allow write actions during the pilot?
Only one named write, approved by the sponsor in writing, with approval required every time. Keep deletes, payments and bulk changes out of a first pilot.
What if the team stops using it halfway?
Treat it as a finding. Ask why: slow results, confusing approvals or wrong answers. Low use with a clear cause usually means adjust, not go.
How does this differ from the pilot rollout playbook?
This page is the plan and the decision rules. The rollout playbook covers the admin steps inside Claude and ChatGPT and the weekly team routine. Use the charter here, then follow the playbook to run it.
