FRD Orchestration with MCP: Deterministic Context Control for Agents (No Drift)

Source: Dev.to

Introduction

Some time ago I wrote an article explaining the value of orchestrating multiple Feature Requirement Documents (FRDs) to keep full control over building a NestJS boilerplate from scratch, step by step.

• FRD‑00: orchestration
• FRD‑01: skeleton
• FRD‑02: ORM + migrations
• FRD‑03: auth + JWT
• FRD‑04: unit testing

It worked, but a classic problem showed up: when FRDs live as “loose” files in the workspace, the agent can read the wrong .md, mix phases, or cache the wrong context.

Before

FRDs as files inside a folder → the agent might read the wrong document / mix phases / cache context.

After

An MCP tool get_frd("00".."04") returns the correct FRD by ID → phase‑controlled delegation, less drift, and more repeatability.

The Weak Point of File‑Based Context

In the earlier article I showed the benefits of using FRDs to guide an agent through building a boilerplate. The workspace looked like this:

folder name: api-products
 ├─ FRD-00-master-orchestration.md
 ├─ FRD-01-boilerplate-core-products.md
 ├─ FRD-02-products-database.md
 ├─ FRD-03-auth-security.md
 ├─ FRD-04-unit-testing.md
 └─ Start the orchestration..

Even though FRD‑00 defines the order and delegates each phase, the weak point remained: file selection inside the workspace.

Typical failures when an agent works with file‑based context:

• Reading the wrong .md file.
• Mixing phases (skipping steps).
• Running commands outside the target folder.
• Non‑deterministic steps.

Solution: Deterministic Retrieval via MCP

What is MCP?

Model Context Protocol (MCP) is a protocol that lets you expose tools (functions) to an agent/IDE so it can request information in a controlled way, instead of “guessing” by reading workspace files.

Instead of “searching for files,” the agent requests exactly the document it needs through a tool:

get_frd("00") → main orchestration
get_frd("01") → phase 1
get_frd("02") → phase 2
get_frd("03") → phase 3
get_frd("04") → phase 4

Result

Orchestration no longer depends on the agent’s “file picking.” At each phase, the agent requests the correct FRD, in the correct order. The spec input is stable, so two separate runs tend to produce the same outcome.

Policies can be enforced, for example:

• “You can’t request FRD‑03 unless FRD‑02 is completed.”
• “Always request FRD‑00 before any other.”

In VS Code, open the MCP Servers view and verify that frd-orchestrator is active.

MCP Server Configuration

// .vscode/mcp.json
{
  "servers": {
    "frd-orchestrator": {
      "type": "stdio",
      "command": "/Users/jorgegomez/.local/bin/uv",
      "args": ["run", "main.py"]
    }
  }
}

Note: On my machine, uv is located at /Users/jorgegomez/.local/bin/uv. Adjust the path as needed for your environment.

When the server starts, the VS Code console shows that the MCP server is running.

Example Interaction

Each phase triggers get_frd("0X"), and the server responds by reading the exact file from disk.

[FRD-Orchestrator] get_frd tool requested with frd_id=02
Reading FRD from disk: .../frd/FRD-02-products-database.md

[FRD-Orchestrator] get_frd tool requested with frd_id=03
Reading FRD from disk: .../frd/FRD-03-auth-security.md

[FRD-Orchestrator] get_frd tool requested with frd_id=04
Reading FRD from disk: .../frd/FRD-04-unit-testing.md

Explicit tool calls replace “free‑form” workspace reading. With MCP, context stops being “workspace exploration” and becomes “controlled retrieval,” reducing errors, speeding up orchestration, and making the flow reproducible.

Benefits at Scale

The approach scales in enterprise environments. With MCP, AI stops being “just a chat” and becomes a controlled component to automate tasks, flows, and workflows aligned with each company’s business logic. This is the direction developers should head today: AI + deterministic tools + reproducible processes.

Call for Feedback

If you made it this far, I’d love for you to review this approach and share your thoughts. I’m fully open to feedback, criticism, and suggestions for improvement—both on the FRD design and the MCP implementation. If you spot anything that could be cleaner, safer, or more reproducible, please let me know in the comments.