Compiles a repository into a cache-pinned, secret-redacted LLM context bundle in XML, Markdown, or JSON to give AI coding agents token-budgeted project context.
Compile a repository into a cache-pinned, secret-redacted LLM context bundle (xml or md).
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Repository root path (default '.') | |
| format | No | Output format | |
| budget_tokens | No | Target token budget (default 32000) |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that the output is cache-pinned and secret-redacted, which are important traits. However, it omits whether the operation is read-only or writes files, what permissions are needed, and how budget_tokens is enforced, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero filler. It packs the key operation and two distinguishing behavioral traits into one clause, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generation tool with no annotations and no output schema, the description is thin. It names the output artifact and two traits, but does not state what the tool returns (file path? inline bundle?), whether it writes to disk, or how the token budget affects the result, so the agent lacks enough context to call it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters, establishing a baseline of 3. The description adds only a parenthetical '(xml or md)' for the format parameter, which actually omits 'json' from the enum, creating a slight mismatch rather than adding useful parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Compile a repository into a ... LLM context bundle'. It clearly distinguishes this tool's output artifact (context bundle), but it does not explicitly contrast with siblings like ctxray_repo_map or ctxray_skeletonize, leaving the agent to infer when this tool is preferred over those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no named alternatives. The agent must infer from the purpose that this tool is for generating an LLM context bundle, but no condition or sibling comparison is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.