Blog · July 7, 2026

Your MCP server's system prompt only gets bigger. Ours has a budget CI enforces.

Give an MCP server a new capability and the obvious place to explain it is the always-on instructions field — the text every client pays for on every single connect, before a tool is ever called. It's the easiest place to add a paragraph, and that's the problem: nothing stops the next capability, and the one after that, from adding another paragraph next to it. Six months in, the "always-on" text is a wall of edge cases nobody re-reads, paid for in full by a session that only ever needed the first three sentences of it.

The instinct to fix this is usually "trim it," which just delays the same failure. The actual fix is deciding, structurally, what earns a permanent seat in the text every session pays for — and building something that stops a future edit from sneaking past that decision.

Two tiers, not one file

Ledgenter's MCP server splits agent-facing content into two tiers on purpose. The always-on instructions is the orientation a cold session needs before it can do anything useful: what the objects are, the core loop (whoami → inbox → claim → work → record), the handful of rules that apply everywhere. A CI test estimates its token count and fails past a hard ceiling — a real number a test asserts against, not a target we eyeball, targeted around 650-750 with headroom to 900 before it trips. A recurring unattended tick (a cron loop, not a human watching) gets one more short addendum on top, capped at its own separate ceiling — "drain, then exit" — and interactive sessions never pay for it, because the two run shapes need different orientation and there's no reason to charge one for the other's paragraph.

Everything else — the fifteen-plus topics that used to be candidates for "just add it to the instructions" — lives behind guide(topic), called on demand. Git and repos, runs and subagents, tasks and dependencies, sessions and loops, the glossary. An agent that needs depth on one thing asks for that one thing and gets a real answer; a session that doesn't need it never sees the token cost. The same content is mirrored as MCP resources (ledgenter://guide, ledgenter://guide/{topic}) for hosts that prefer reading a resource to calling a tool, and again in the CLI's guide command — three surfaces, one source.

The part that isn't a convention

A two-tier split is easy to propose and easy to erode — the next contributor adds a paragraph to the always-on text because it felt important in the moment, and eighteen months later you're back where you started. So the tiers aren't a style guide; they're one module (guide/content.ts) that all four channels — the MCP instructions, the guide tool, the MCP resources, and the CLI — render from, plus three checks that run in CI, not in someone's head:

• A token budget on the always-on text. Add a paragraph to CADRE_INSTRUCTIONS and the test that counts its tokens fails if you crossed the line. The question stops being "does this feel important" and becomes "does it fit inside the number we already agreed on" — and if it doesn't, it goes in a guide topic instead, which is exactly the fallback that's supposed to absorb it.
• Reference integrity. Every tool name mentioned in a topic's relatedTools has to exist in the live tool registry, and every topic a seeAlso points at has to resolve. Rename a tool and forget to update the guide, and CI catches the dangling reference instead of an agent hitting a name that used to work.
• Coverage. A newer gate (shipped this week) walks every topic id and fails if it's neither routed to by name from the durable "how to use this" doc that seeds our own distributable skill, nor listed in an explicit allowlist with a reason it's intentionally skipped. Silent drift — a topic that quietly stopped being pointed at from anywhere — has to become a deliberate decision, on the record, instead of a topic that just goes stale.

None of the three checks makes the content better. What they do is make the two-tier decision durable: the always-on text can't quietly regrow because a number enforces it, the on-demand depth can't quietly rot because a reference check and a coverage gate both watch it, and all four surfaces stay identical because they're one file, not four copies someone forgot to keep in sync.

The generalizable part

This isn't really a Ledgenter-specific concern. Any MCP server — or any system that hands an agent a standing block of context on every connect — runs into the same fork eventually: keep appending to the one thing every session reads, or decide what's truly universal and put a real fence around it, then give everything else an on-demand path with the same content-integrity guarantees. The fence is the part that's easy to skip, because it's not visible in a demo and it doesn't show up until the instructions have already grown past the point where trimming them is politically easy. Building the fence on day one — a number a test checks, not a rule someone remembers — is cheaper than trimming a wall of text everyone's afraid to touch later.

This post was shipped by one of those fires.