When Anthropic released the Claude Code source, the obvious reaction was to go hunting for implementation details.
That part was expected.
What was more interesting was what the code quietly revealed about constraints, tool design, internal agent architecture, and how Anthropic appears to think about model supervision in practice.
This was not just a source release. It was a small disclosure of operating their true philosophy.
And some of the most useful lessons are not about Claude specifically. They are about how anyone building MCP servers, tools, and agentic workflows should think.
The first lesson: tool verbosity is not your friend
One of the clearest implementation details is that tool descriptions are hard-capped at 2,048 characters.
That matters.
A lot of people building MCP servers seem to assume richer descriptions are always better. In practice, that often turns into context bloat: massive action descriptions, repetitive parameter text, and endless schema noise dumped into the prompt.
Claude Code’s implementation says the opposite.
There is a point where additional description stops improving tool use and starts degrading the context budget.
So the takeaway is pretty simple: stop writing bloated tool descriptions. Past a certain point, they are not helping the model. They are just competing with everything else that matters.
If Anthropic is hard-capping descriptions, that should probably reset expectations for the rest of us.
Tool naming is stricter than people think
Another useful detail is how tool names are normalized.
Everything passes through a format like:
mcp__<server>__<tool>
Any non-alphanumeric characters get replaced with underscores. Claude.ai server names get extra collapsing and stripping to protect the delimiter format.
That is not just cosmetic. It tells you something important about the interface contract.
If your MCP server names, tool names, or API action names are messy, symbolic, or inconsistent, the platform is going to sanitize them anyway. You do not really control the final shape unless you start with something clean.
The practical implication is obvious: design tool names as if they need to survive normalization. Because they do.
That means fewer clever separators, less punctuation, fewer overloaded names, and more boring, durable identifiers.
Boring wins here.
Skills are on a budget too
The source also shows that skill listings are budget-capped at 1% of the context window.
That is an extremely revealing number.
Bundled skill descriptions are preserved. Custom skill descriptions, however, may be shortened if the listing exceeds the budget.
Again, the message is consistent: verbosity is not neutral. It is taxed.
A lot of developers treat skills like documentation pages. That is probably the wrong mental model. A skill listing is closer to a routing surface. It needs to be legible, compact, and discriminative. Its job is not to explain everything. Its job is to be selected correctly.
So the design pattern here is not “write more.” It is “compress harder.”
The best skill descriptions will be the ones that waste the fewest tokens while still making correct invocation more likely.
Permissioning tells you what Anthropic considers dangerous
There is also a quiet but important product decision in the skill approval model.
Simple skills, those with no allowed tools and no model override, are auto-approved without a permission prompt. More powerful skills require explicit approval rules.
That is a clean trust boundary.
Anthropic is effectively separating lightweight prompt packaging from capabilities that materially expand execution power. That is the right distinction. It also suggests a useful way to think about your own agent platform:
Prompting alone is one class of power. Tool access is another. Model escalation is another.
Those should not all be permissioned the same way.
Too many systems flatten these differences. Claude Code’s implementation suggests Anthropic does not.
The most interesting thing in the release was not public-facing at all
Buried in the code is a built-in advisor tool.
And it is far more interesting than a normal user-facing tool.
The advisor is not a shell tool. It is not a local file tool. It is not some fancy wrapper around grep or bash. It is a server-side review tool that forwards the entire conversation history to a stronger reviewer model.
It takes no parameters.
That alone is notable.
The model does not pass a handcrafted summary. It does not bundle selected artifacts. It calls advisor, and the system forwards the full interaction history: the task, the tool calls, the outputs, the prior reasoning trajectory embedded in the conversation, everything.
That means Anthropic is operationalizing a pattern many people have talked about conceptually but have not really productized cleanly: in-session model oversight by a stronger model.
Not after the fact. Not as a separate workflow. Right in the loop.
There is a new internal advisor tool
From the code, the purpose is not “PR review” in the ordinary sense.
There is apparently a separate /review flow for explicit user-invoked review tasks. Advisor is different.
Advisor looks like an internal quality-control mechanism for the agent itself.
The instructions are unusually revealing. The model is told to call advisor:
- before substantive work
- when stuck
- when considering a change in approach
- before declaring the task complete
That is a strong statement about failure modes.
Anthropic seems to be assuming that the dangerous moments in an agent loop are not just execution errors. They are moments of premature commitment: committing to an interpretation, building on a weak assumption, hardening the wrong approach, or confidently stopping too early.
That is where advisor enters.
So the point of the tool seems to be less “review my code” and more “review my trajectory.”
That is a much more important use case.
No, it does not look employee-only
At first glance, it might be tempting to assume advisor is an Anthropic-internal feature only.
The code does not really support that conclusion.
Anthropic employees do appear to get broader access. There are checks involving USER_TYPE === 'ant', and internal users seem to bypass some model restrictions. But external users are clearly accounted for on supported first-party models, and the code includes comments about cleaning up SDK typing “when this feature ships publicly.”
That is not how you talk about something that is permanently employee-only.
The better reading is:
It is hidden, rollout-gated, beta, and first-party constrained. But it is not conceptually restricted to employees.
That distinction matters.
First-party only is the real constraint
The stronger limitation is not employee status. It is platform control.
The advisor tool relies on a beta header and is explicitly refused for Bedrock- and Vertex-style paths. It can also be feature-gated through GrowthBook config and hard-disabled via environment variable.
So this is not just a clever tool hanging off the client. It depends on infrastructure Anthropic controls end to end.
That makes sense, because advisor is not a normal client-side tool call. It is a server-side orchestration feature. The client injects advisor instructions into the system prompt and adds a server tool schema when advisor is enabled. The API can then emit special tool-use and tool-result blocks for advisor, including normal text, encrypted redacted content, or an error code.
In other words, this is not an MCP server pattern in the ordinary external sense. It is platform-native supervision.
Anthropic is not just exposing tools to the model. It is exposing managed escalation.
The user configures availability. The model decides invocation
This is one of the cleaner architectural choices in the whole flow.
The hidden /advisor command does not appear to invoke the advisor directly. It configures which advisor model should be available.
After that, if advisor is enabled, the client includes the tool in the request and appends the relevant instructions. The model then decides whether to call it.
That split is important.
The user or product decides whether the capability exists in-session.
The model decides when to use it.
That is a more agentic pattern than a traditional command-driven UX, and it is a good reminder that configuration and invocation should not always be coupled.
You do not need the human micromanaging every escalation point. You need the human to set the operating envelope, and then the system to use judgment inside it.
At least, that is the ideal.
Anthropic’s tool instructions are worth studying
The ADVISOR_TOOL_INSTRUCTIONS block may be one of the most useful artifacts in the source release for people building tools.
Not because it is magical. Because it is disciplined.
The instructions are specific about:
- what the tool is
- what it sees
- when it should be called
- when it does not need to be called
- how much weight to give its advice
- how to reconcile conflicts between advisor guidance and primary evidence
That last part is especially strong. The model is told not to silently switch directions if previously retrieved evidence conflicts with the advisor’s recommendation. It is told to surface the conflict and resolve it explicitly.
That is good tooling guidance because it acknowledges reality: stronger models are not infallible, and orchestration quality depends on handling disagreement, not pretending disagreement will not happen.
This is what useful tool instruction writing looks like. Not vague “use this tool when helpful” language. Not generic policy prose. Concrete operational guidance tied to real failure states.
Anyone building MCP tools should study that style.
The bigger pattern: model hierarchies are becoming product features
The most important thing revealed here may be the least flashy.
Claude Code appears to be treating model hierarchy as an operational primitive.
A weaker or cheaper model handles the main interaction loop. A stronger reviewer model is available as a supervisory layer. The review can be invoked at critical decision points. The system preserves traceability around when it was called and which model was used.
That is a serious architecture pattern.
It suggests that the future of agent systems may not just be “one model with tools.” It may increasingly be:
- one model doing the work
- another model reviewing the plan
- another system enforcing permissions
- another layer deciding what context and capabilities are exposed when
That is less like chat and more like an execution stack.
And honestly, that is probably where serious agent systems were always going.
What builders should take from this
The practical lessons from this source drop are not subtle:
Tool descriptions should be shorter.
Tool names should be normalization-safe.
Skill descriptions should be lean and selection-oriented.
Permissioning should distinguish between prompt packaging and real capability expansion.
Tool instructions should be concrete, situational, and written around failure modes.
And if you are building agent systems, you should probably be thinking harder about supervisory models, not just better tool catalogs.
The advisor tool is the standout example because it shows Anthropic thinking beyond basic tool use.
They are not just asking, “What can the model do?”
They are also asking, “Who checks the model before it commits?”
That is the more important question.
And judging from this code, Anthropic seems to know it.
Reburn Report 
Leave a comment