Your MCP server will drift from your app. Here's a build gate that stops it.

Draft

When I added an MCP server to RyTask (an open-source project tracker), I made one promise: anything a person can do in the UI, an AI agent can do over MCP. No read-only second-class agent access. Full parity.

The problem with promises like that is they rot. You ship a new feature, wire it into the UI and the REST API, and forget the MCP tool. Three sprints later your "100% parity" is 86% parity and you don't know it. So I made parity a thing CI can prove, and fail the build over.

The shape of the system

Every business module in RyTask declares the capabilities it owns and the MCP tools that expose them, in one file:

// work-items/module.testplan.ts
export const workItemsTestPlan = {
  capabilities: ['create', 'update', 'assign', 'comment', 'logTime', ...],
  mcpTools:     ['create_work_item', 'update_work_item', 'assign_work_item', ...],
}

A registry aggregates every module's tools. The MCP server is built from that same registry — there's no separate hand-maintained list to drift.

The gate

check:mcp-parity walks every capability and asserts a matching tool exists, and every tool maps back to a real capability. One missing pair fails CI:

const missingTool = capabilities.filter(c => !toolFor(c))
const orphanTool  = tools.filter(t => !capabilityFor(t))
if (missingTool.length || orphanTool.length) {
  console.error('MCP parity broken:', { missingTool, orphanTool })
  process.exit(1)
}

It currently reports 49/49. The day I add a "duplicate project" feature and forget the tool, the build goes red and tells me exactly which tool is missing. Parity stopped being a docs claim and became an invariant.

Why this matters beyond my project

AI agents are becoming real users of software. If your agent surface is a hand-curated subset of your product, it will always lag the UI, and your users' agents will hit walls the humans don't. Treating the agent as a first-class client — held to the same coverage by the same CI that guards everything else — is, I think, where a lot of tools are going to end up.

RyTask does the same trick for a few other invariants: module boundaries (you can't import another module's internals), multi-tenancy (every tenant-scoped query is auto-constrained to the caller's org at the repository layer, and tests assert cross-tenant isolation against a real Postgres), and a "closed testing" gate that fails the build if a declared-required test file is merely missing.

It's all open source (AGPL-3.0), built solo. If you want to see the gates in action, the repo's here: github.com/ali-maher-m/RyTask. I'd love feedback on the approach — especially from anyone else building MCP servers for real products.

Comments

[Eleftheria Batsou]

This is a great writeup, and the "full parity or it's second-class access" promise is exactly the right bar to hold yourself to. The build gate is a clean enforcement mechanism.

One thing I'd add from experience: the drift problem doesn't stop at the MCP-vs-UI surface, it extends to the environment the MCP server runs in vs the one your app runs in. A gate that verifies tool parity but lets the runtime drift (different Postgres version, different env vars) just moves the failure one layer down.

Parity all the way down is the real win. (I work at Zerops, we obsess over exactly this.)