Using MCP to give coding agents product context

Long prompts mix relevant and irrelevant context, become expensive to repeat, and often lose the status of individual decisions. Retrieval gives the agent a smaller contract: find the project, inspect the published flow, read its related roles and models, and load acceptance cases for the task at hand.

The agent can ask for more context when needed. That makes missing information visible instead of hiding it inside a giant document the model may not weigh correctly.

Expose stable identifiers and relationships, not only rendered prose. An agent should be able to distinguish the current published revision from a draft and follow references without guessing names.

An MCP connection should not become a side door around workspace permissions. Tool calls need the same project-level read and write checks as the product interface. Results should be scoped to the connected identity, and sensitive mutations should fail immediately when authority is missing.

Separate reading approved context from proposing changes. A coding agent may need broad read access to implement a task, while specification edits should remain proposals that a human reviews before publishing.

Begin with the task and the source revision. Retrieve the affected flow, then follow only its referenced roles, models, glossary terms, and acceptance cases. Add repository instructions from the codebase itself. If the implementation touches an unmentioned behavior, stop and request a product decision.

This creates a clean evidence chain: task to revision, revision to structured entities, entities to acceptance tests, and code changes back to the task. The chain matters more than the size of the prompt.

MCP does not make stale content correct, resolve contradictory decisions, or remove the need for review. It improves access to whatever source you expose. The specification still needs ownership, a published state, and an explicit revision process.

It also does not replace repository context. Product intent explains what the system should do; the repository explains how this particular system is organized and constrained. Reliable agents need both, kept in their proper places.