The short answer
MCP is a standard that lets an AI application call tools in another system. Point one at your specification and a coding agent can fetch the exact flow, model, and test cases a task needs — under the permissions of whoever connected it.
- The agent pulls context instead of you pasting it
- Every call runs as the connected user, not as the server
- Reading approved context and changing it stay separate
- Missing context comes back empty instead of invented
On this page · 6 sections
Pasting the spec into the prompt does not scale
A long prompt hides the one paragraph that mattered.
The usual workflow is copy and paste. Someone opens the planning document, selects all of it, drops it into the agent, and adds a sentence about the task. This works until the document passes a few thousand words.
Then three things go wrong at once. The relevant paragraph competes with forty irrelevant ones. The copy goes stale the moment somebody edits the source. And nothing in the text marks which decisions are approved and which are still an argument in a comment thread.
Paste the whole document
- Every prompt repeats the same several thousand tokens
- Settled decisions look identical to open questions
- The copy is stale as soon as the source changes
- A gap in the document reads as no constraint, so the agent fills it
Let the agent retrieve
- The agent pulls the flow the task touches, and little else
- Published revisions and drafts arrive labelled
- Every call hits the current source
- A missing entity returns empty, so the gap is visible
The right-hand column has a property the left one cannot have: when the agent needs something it does not yet have, it can ask again. Absence becomes a signal rather than silence.
What a retrieval actually looks like
Four calls, not one enormous paste.
Here is an agent picking up a task about password reset. It starts with the task title and an MCP connection, and nothing else.
→ search_flows({ query: "password reset" })
← [{ id: "flow_8kq2", name: "Reset a forgotten password",
status: "published", revision: 14 }]
→ get_flow({ id: "flow_8kq2" })
← { trigger: "User submits the reset form",
roles: ["anonymous", "user"],
steps: 9, branches: 3,
models: ["User", "ResetToken"],
testCases: ["TC-41", "TC-42", "TC-43"] }
→ get_model({ name: "ResetToken" })
← { fields: { token: "string, unique",
expiresAt: "datetime",
usedAt: "datetime | null" },
retention: "deleted 24h after expiry" }
→ get_test_cases({ ids: ["TC-41", "TC-42", "TC-43"] })
← ["An expired token shows an error and creates no session", …]That is a few hundred tokens, all of them about this task. The agent now knows the token expires, that expiry is already tested, and that reusing a token is a case someone thought about. None of that survives a copy-paste of a forty-page document, where the same facts sit three sections apart and carry no weight.
What to expose
Identifiers and relationships, not rendered prose.
Rendering the specification to markdown and returning it as one blob rebuilds the problem you were escaping. Expose entities the agent can name, address, and follow.
| Expose | What the agent gets | Why it matters |
|---|---|---|
| Project and glossary | Vocabulary plus the current published revision | The agent uses your words for your concepts |
| Flows | Trigger, actors, ordered steps, branches, outcomes | This is the behavioural contract to build against |
| Roles | Capabilities and explicit restrictions | Stops an agent from inventing an access rule |
| Data models | Fields, types, enums, relationships | Prevents incompatible assumptions in code |
| Test cases | Named, addressable acceptance criteria | Turns done into something checkable |
| Revisions | What changed, when, and who approved it | Lets the work cite the version it came from |
| Search | Identifiers back, not prose | Turns a vague task title into a starting point |
The last row is the one people skip. An agent that cannot search has to be handed identifiers by a human, which puts the copy and paste right back into the loop.
Permissions travel with the connection
An MCP server is a door into the workspace. Treat it like one.
A tool call is a request from a person, routed through an agent. It gets the same project-level checks the product interface applies: the connected identity, the projects that identity can open, the actions it is allowed to take. When authority is missing the call fails and says so — no partial result, no quiet fallback to whatever happens to be public.
Then split the surface in two. Reading approved context and changing it are different capabilities, and they deserve different scopes.
A reasonable default for a coding agent:
- Read — broad access to published flows, roles, models, and test cases in projects the user can already open.
- Propose — it may draft a specification change when implementation uncovers a case nobody described.
- Publish — never. A person accepts the consequence, and the revision records who.
A bounded-context recipe
Start at the task, follow its references, stop at the edge.
Assemble context the way you would brief a new engineer: the task, the behaviour it touches, and the things that behaviour references. Not the company wiki.
Pin the revision
Resolve the task to a project and the revision that is published right now. Everything downstream cites that number.
Fetch the flow
One flow, with its trigger, ordered steps, branches, and outcomes. This is the contract the code has to satisfy.
Follow its references only
The roles, models, and glossary terms that flow actually names. Resist the second hop into adjacent features.
Load the acceptance cases
Named test cases make done checkable instead of negotiable, and give the agent something to verify against.
Add repository instructions
Conventions, structure, and constraints come from the codebase. Product intent has no business knowing how your repo is laid out.
Stop at the edge
If implementation needs behaviour the spec never described, that is a product decision. Surface it; do not invent it.
What you get is a chain: task to revision, revision to entities, entities to test cases, test cases to a diff. When somebody asks in four months why the code behaves this way, the chain answers. Prompt size never did.
What MCP will not fix
It is a transport. It does not make the source true.
MCP improves access to whatever you point it at. If the specification is stale, contradictory, or unowned, retrieval delivers those problems faster and with more confidence attached.
| MCP does not… | You still need… |
|---|---|
| Make outdated content correct | An owner, and the habit of publishing changes |
| Resolve two decisions that contradict each other | A review step that forces someone to choose |
| Decide what counts as approved | An explicit published state, distinct from drafts |
| Replace repository context | Codebase conventions the spec should not carry |
| Remove human review | A person who accepts the consequence of a change |
Product intent explains what the system should do. The repository explains how this particular system does it. Agents need both, and they need them kept apart — the moment one starts describing the other, both start drifting.
Before you connect an agent
- Every tool call enforces the connected user's permissions.
- Responses distinguish published context from drafts.
- Results carry stable identifiers, not just prose.
- Reading and proposing changes are separate scopes.
- Any implementation can name the revision it was built from.