Panelica keeps its 404 MCP tools in sync with the panel's real API by generating the entire tool catalogue directly from the panel's live /v1/api-spec on a weekly CI run, rather than hand-maintaining a separate tool list. This means the catalogue can never silently fall behind the actual API — it either reflects the current 406 endpoints accurately, or the build fails.
The problem with hand-maintained tool lists
The obvious way to build an MCP server for an existing API is to write tool definitions by hand: one function per endpoint you care about, updated whenever the API changes. It works at first. It fails quietly later — someone adds a new endpoint to the panel and forgets to add the corresponding tool, or a parameter changes shape in the API and the hand-written tool definition keeps describing the old one. An AI client calling that stale tool either fails outright or, worse, succeeds with the wrong assumptions about what it is doing to a production server.
This class of bug is called drift, and it is exactly the kind of thing that is invisible until someone hits it in production, which is the worst possible place to discover it.
Panelica's approach: generate, do not hand-write
The Panelica MCP server's 404 tools are not written by a developer looking at the API and deciding what to expose. They are generated automatically from the panel's own /v1/api-spec endpoint — the same live, structured description of the API that the panel's own frontend and documentation are built from. When the underlying API changes, the specification changes with it, and the next generation run produces a tool catalogue that matches.
| Step | What happens |
|---|---|
| 1. Source | The panel's live /v1/api-spec describes all 406 External API endpoints, their parameters and their return shapes. |
| 2. Generation | A weekly CI job reads the specification and produces the MCP tool catalogue — names, parameters, descriptions and safety annotations — directly from it. |
| 3. Verification | The build compares the newly generated catalogue against the previous one and fails if the tool count would drop, catching accidental removals before they ship. |
| 4. Publish | A verified catalogue is published to npm as panelica-mcp, to ghcr.io/panelica/panelica-mcp:latest, and to the official MCP Registry. |
What "zero-drift" actually guarantees
Zero-drift does not mean the catalogue is static — it means the catalogue can only grow or stay accurate, never silently shrink or fall out of sync with reality. The build pipeline treats "the tool catalogue got smaller" as a build failure by default, on the reasoning that new API endpoints are additions and any decrease is almost certainly a mistake, not an intentional deprecation. If Panelica genuinely retires an endpoint, that is a deliberate, reviewed change to the generation pipeline — not something that happens as a side effect of someone forgetting to update a tool list.
Why this matters more for AI tools than for human documentation
A human reading slightly outdated API documentation notices something is wrong — a 404, an unexpected error message, a support ticket. An AI assistant calling a stale or missing tool does not have that instinct; it either fails in a way that looks like a bug in the assistant rather than the tool definition, or it calls a slightly wrong version of the tool and gets a result that looks plausible but is not what the current API actually does. Generating the catalogue from source eliminates the entire category of error, rather than relying on someone catching it in review.
How this shows up as new features ship
When Panelica added Python Application Hosting, described in Announcing Python Application Hosting, or Webhooks, described in Announcing Webhooks, the corresponding MCP tools did not require a separate engineering task to expose them to AI clients. The new endpoints appeared in the live API specification as part of shipping the feature, and the next scheduled generation run picked them up automatically — the same mechanism, no special case.
What this means if you build against the MCP server
If you are integrating an AI workflow against Panelica's MCP server, you can rely on the tool catalogue reflecting the panel's actual current capabilities without checking a changelog first. New Panelica releases with new API surface will show up as new tools on the next weekly regeneration; you do not need to manually track which panel version introduced which tool.
Read more
For the standard this all sits on top of, see What Is MCP and Why Hosting Panels Need It. For the full tool catalogue this process produces, see Introducing the Panelica MCP Server.
Build against a catalogue that stays accurate. The Panelica MCP server's tool list is regenerated from the live API, not maintained by hand. Source: github.com/Panelica/panelica-mcp. See features and pricing.