Reads a file's structural skeleton, showing signatures and docstrings while omitting implementation details.
Reads the semantic AST skeleton outline of a single file, omitting internal implementations while preserving signatures and docstrings.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Relative or absolute path to the file |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states what is omitted (internal implementations) and what is preserved (signatures and docstrings), giving agents a clear expectation of the result. It does not discuss error behavior or output format, but the read-only nature is clear from the verb.
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?
The description is one tightly written sentence with no filler. The main action and resource are front-loaded, and the qualifiers about what is omitted and preserved add meaningful detail without bloat.
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 simple single-parameter tool, the description is largely complete: it says what the tool does, what the output includes, and what it excludes. It lacks explicit guidance on when to prefer it over sibling tools, but the tool's scope is narrow enough that an agent can invoke it correctly with the provided information.
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 fully documents the single filePath parameter. The description adds no new parameter-level meaning beyond confirming the tool operates on a single file, which is already implied by the schema.
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 clearly states a specific verb ('Reads') and a specific resource: the semantic AST skeleton outline of a single file. It further distinguishes itself from codebase-wide or context-extraction siblings by emphasizing 'single file' and the outline nature of the result.
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?
The description implies when to use this tool—when you want signatures and docstrings without implementation detail—but never explicitly states alternatives or exclusion criteria. An agent has to infer the use case from the wording rather than being told when to choose this over extract_relevant_context or get_codebase_map.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.