CI parity gate keeps MCP server in sync with app features
Ali Maher built a CI check for RyTask that fails the build whenever an MCP tool is missing for a declared app capability, enforcing full UI-to-agent parity automatically.
Score breakdown
The approach converts MCP coverage from an informal documentation claim into a hard CI invariant, so agent-facing surfaces cannot silently fall behind the UI as new features ship.
- 01Ali Maher built an MCP parity gate for RyTask, an open-source project tracker (AGPL-3.0).
- 02Each business module declares its capabilities and MCP tools in a single `module.testplan.ts` file.
- 03The MCP server is built from a shared registry derived from those files, removing any separate hand-maintained tool list.
Ali Maher set out to give AI agents full parity with the RyTask UI — meaning anything a person can do in the interface, an agent can do over MCP. The problem, he found, is that this kind of promise decays silently: a new feature gets wired into the UI and REST API but the MCP tool is forgotten, and "100% parity" quietly becomes something lower without anyone noticing.
To make parity machine-verifiable, each business module in RyTask exports a test-plan file (e.g., `work-items/module.testplan.ts`) that declares both the capabilities the module owns and the MCP tools that expose them.
To make parity machine-verifiable, each business module in RyTask exports a test-plan file (e.g., `work-items/module.testplan.ts`) that declares both the capabilities the module owns and the MCP tools that expose them. A registry aggregates all modules' tools, and the MCP server is built directly from that registry — there is no separate hand-maintained list that can drift. A CI script, `check:mcp-parity`, then filters for any capability lacking a matching tool (`missingTool`) and any tool that maps to no capability (`orphanTool`); if either array is non-empty, the script calls `process.exit(1)` and the build fails with an explicit report of what is broken.
Maher applies the same pattern to other invariants in RyTask: module boundary enforcement (internals of one module cannot be imported by another), multi-tenancy isolation (every tenant-scoped query is auto-constrained at the repository layer, with cross-tenant isolation asserted against a real Postgres instance), and a "closed testing" gate that fails the build if a required test file is simply absent. The project is open source under AGPL-3.0 and available at github.com/ali-maher-m/RyTask.
Key facts
- 01Ali Maher built an MCP parity gate for RyTask, an open-source project tracker (AGPL-3.0).
- 02Each business module declares its capabilities and MCP tools in a single `module.testplan.ts` file.
- 03The MCP server is built from a shared registry derived from those files, removing any separate hand-maintained tool list.
- 04A CI script called `check:mcp-parity` fails the build if any capability lacks a matching tool, or any tool lacks a matching capability.
- 05RyTask currently reports 49/49 capability-to-tool parity.
- 06The same gate pattern is also applied to module boundaries, multi-tenancy isolation, and missing test files.
- 07The project is solo-built and available at github.com/ali-maher-m/RyTask.
Topics
Summary and scoring are generated automatically from the original article. We always link back to the publisher and never republish images or paywalled content. Last processed Jun 13, 2026 · 08:58 UTC. How this works →