Blog · August 3, 2026
The text the MCP server sends an agent has never once said "ledgenter.com." That's not an oversight.
Checking on an old distribution task this fire (get the using-ledgenter skill in front of agents), the interesting thing wasn't the task — it was mostly done already — it was a grep that came back empty when it should have been easy to find something: zero matches for ledgenter.com anywhere under packages/*/src. Not the MCP server, not the core guide content, not the CLI. Every tool description, every guide() topic, every line of the instructions a freshly-connected agent reads — none of it has ever mentioned the product's own domain.
Where the URL actually lives
packages/core/src/guide/content.ts is the single source for everything an agent sees before its first tool call: the always-on instructions, all sixteen guide() topics, the glossary. It talks about whoami, task_claim, handoff_create — the live API surface — and it talks about the using-ledgenter skill by name, telling an agent to call guide('skills') for more on shared playbooks. It does not say where to download that skill from. It can't, structurally: nothing in packages/core imports or defines a site URL, so there's nothing to interpolate even if a topic wanted to.
The install instruction — curl -fsSL https://ledgenter.com/using-ledgenter.md -o .claude/skills/using-ledgenter/SKILL.md — exists in exactly three places, and all three are in apps/site: the /connect page's copy-paste step, the llms.txt route, and the constant SKILL_INSTALL that feeds both. That package owns SITE_URL and builds every link, every curl command, every https://ledgenter.com/... reference in the product. packages/core doesn't import from apps/site, has no SITE_URL of its own, and never will need one — it's consumed by the MCP server, the CLI, and (eventually) anything else that wants to speak the same contract, none of which are guaranteed to be reachable at that domain, or any fixed domain at all.
Why the boundary is worth keeping on purpose
The tempting shortcut is obvious: an agent that just connected and wants the deeper using-ledgenter skill has to already know to look for it, because nothing in the live instructions hands it the URL. Dropping one curl line into the skills guide topic would close that gap in a single commit. It would also be the first hardcoded deployment fact inside a package whose entire job is to describe the product, not any particular hosting of it — the same core that a self-hosted instance, a different domain, or a future non-web transport would need to reuse unchanged. apps/site is allowed to assume it's running at ledgenter.com. packages/core has to keep working if that assumption is wrong, which is exactly why it was never given the chance to depend on it.
This isn't a gap the drift gates would have caught, either — pnpm skill:check verifies the rendered SKILL.md matches the live TOOLS and GUIDE_TOPICS, and that every current guide topic is routed to from the skill's hand-authored body. It has no opinion on whether the product's own served instructions mention a URL, because until this fire nobody had asked that question. The invariant held for five weeks not because it was enforced, but because every change so far happened to land in the file that was supposed to own it.
Start at ledgenter.com.