Chapter 3: The Decision Framework
This is the chapter that saves the most wasted effort.
It is tempting to reach for MCP because it sounds strategically correct: open standard, interoperability, future-proof surface. Those are real benefits, not reasons by themselves.
The rule: build an MCP server only when natural language improves the workflow, more than one client needs the capability, and someone has agreed to own the auth, audit and incident bill. Fail any one and you stop and simplify.
Question 1: Is a Human Interface Already Better?
If the task is clearer, faster, cheaper, or safer in an existing human interface, start there.
A developer fluent in gh is slower through a GitHub MCP server for routine repository work. An operator debugging AWS under pressure wants the console or CLI. MCP works best when language is a helpful control surface. It is weak when the task requires dense visual context, exact repeatability, or expert command over a mature UI.
The test: if you would never ask a skilled human to do this job through chat, be suspicious of building it for a model through chat.
Question 2: Do You Need MCP or Just a Better Prompting Method?
Sometimes the problem is process, not connectivity.
Teaching a model to review code, write migration plans or follow a rubric is methodology, and MCP is for access to capabilities and context. Use MCP when you need the model to reach external systems or discover structured capabilities. Use prompt systems, skills (packaged instructions a host loads on demand; see Appendix D), or workflow templates when you mainly need the model to think in a repeatable way.
Many good systems combine both: a prompt template that structures the workflow, and an MCP server that supplies the tools and data.
Question 3: Do You Need a Protocol or a Direct Integration?
If you control both the client and the backend, and only one client will ever call the capability, use direct function calling: one process to deploy, no auth surface to publish, no per-client testing. Choose MCP when several clients must reuse the capability, when it must be portable across vendors, or when third parties will integrate with it. A protocol boundary is worth its cost only if it buys reuse, governance, or ecosystem reach.
What You’re Signing Up For
Question 3 asks you to own this bill:
- Auth and token handling. An OAuth-protected resource, token validation on every call, scopes, and no token passthrough (Chapters 18 and 19).
- Per-client compatibility. Every host honors a different subset of the protocol, and you test each one (Part V).
- Schema versioning and rollout. Tool names and parameters are a public contract; changing them needs deprecations and sunsets (Chapter 28).
- Audit and logging. Who called what, as whom, with which arguments (Chapters 26 and 23).
- Incident response. A runbook for the day a model does something nobody intended (Chapter 24).
If nobody’s name goes next to each line, the answer to Question 3 is no.
Red Flags: Do Not Build an MCP Server Yet
- The use case is a single workflow for a single team and could be a script.
- The only operation is a simple read that can be pasted into context another way.
- The proposed server is just a raw export of an existing API surface.
- The team has not identified who owns auth, audit, incident response, or client compatibility.
- Nobody can explain which client behaviors matter and which are optional.
Chapter 5’s notes server fails the first red flag on purpose. It is a teaching slice, not a product.
And one more: “We should build an MCP server because everyone else is.” That is panic with better branding, not strategy.
A Practical Comparison
Build it when the MCP column is the one that fits:
| Shell script or CLI | Direct platform tools | Prompt or skill | MCP server | |
|---|---|---|---|---|
| Clients that need it | One user | One product | Any host that loads it | Several |
| Portability across vendors | Not needed | Not needed | Partial | Needed |
| Actions plus readable context | Actions only | Yes, inside one product | Neither; it’s guidance | Yes |
| Crosses several internal systems | Rarely | Rarely | No | Often |
| Governance/audit needed | By the user | By the product | No | Yes, centrally |
| Weak when | Multiple clients, discoverability, governance | Portability and reuse matter | External data or side effects are required | The operational cost outweighs the reuse |
The common hybrid is MCP for the capability layer and native extension logic for the product-specific UI.
The Decision Rule
Do not ask, “Can this be an MCP server?”
Ask:
- Does natural-language access materially improve this workflow?
- Does a shared protocol surface create meaningful reuse or control?
- Am I willing to own the operational and security consequences of exposing this capability to a model?
If the answer to any of those is no, stop and simplify.
If the answer to all three is yes, proceed. The rest of this book is about doing it without lying to yourself about the costs. For the same rule as a one-page tree, see Appendix L.
Running the Rule
Case A: “Give our developers a GitHub MCP server.” Q1 fails. The developers live in gh, and routing “merge this once CI is green” through a tool catalog adds a round trip and an approval prompt to one command. Q3 would also add a token-handling surface over credentials they already hold. Verdict: don’t build it. If an agent needs GitHub, give it gh in a sandbox and a skill that says how your team uses it.
Case B: “Incident timelines need to be reachable from a desktop assistant, the IDE and the on-call chat bot.” Q1 passes: “What changed in payments in the hour before the alert?” is a natural-language question over messy data, and the alternative is three dashboards. Q2 passes: three clients, one capability. Q3 fails until the platform team agrees to own the OAuth resource and the audit trail, and then it passes. Verdict: build it, and start local and read-only (Chapter 2), since a read-only tool has no side effect to approve.
The server I run for Atelier customers passed for the same reasons. A content change is a Markdown edit committed and pushed to the site’s repository; its update_page tool does that from a sentence (Q1). The customer can use ChatGPT, Codex or Claude against one endpoint (Q2). And Q3 has a named answer for each line of the bill: Clerk OAuth on every tool call, a safe policy tier that can write only Markdown, YAML and CSS under content/ and static/, a structured audit line for every allowed and denied call, and a per-user rate limit on writes.
Failure Modes
- Built too early. One client, one team, and now you own an auth surface and a compatibility matrix for nothing.
- Built too late. Three vendor-specific integrations already exist, and moving them onto one server is a migration with three sets of users.
- Decided once, never revisited. The answer was “direct integration” for one client; a second client arrived, and nobody reran the three questions.
Implementation Checklist
- The three questions have written answers, with the name of an owner beside each line of the Q3 bill.
- A cheaper option from the comparison table was tried or explicitly ruled out.
- The decision is dated and has a trigger for revisiting it, such as a second client or a new tenant.
What Comes Next
If you passed all three questions, Part II builds the smallest server that proves it.