File skeleton

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry behavioral disclosure itself. It does disclose one important behavior—function bodies are elided by default—and notes the file must be indexed, but it does not mention side effects, accessibility requirements, or behavior for missing/unindexed files.

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?

Two succinct sentences; the main capability is front-loaded and the elision default is added as a precise second sentence. No filler or redundant restatement of the tool name.

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 tool with five parameters, no output schema, and no annotations, the description is too thin. It leaves 'source-backed headers' undefined, omits return-shape details, and does not clarify how max_tokens/profile/include_private affect results.

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 0%, so the description needed to compensate, but it only loosely clarifies that the path is repository-relative and indexed. The optional parameters profile, max_tokens, and include_private are not explained anywhere, leaving their semantics to inference from names alone.

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 names a specific verb ('Return') and resource ('imports and source-backed headers from one indexed repository-relative file'), making the tool's scope clear. It also distinguishes itself from sibling tools like get_repo_map or find_symbols by emphasizing a single-file skeleton rather than repo-wide mapping or symbol search.

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 intended use is implied: use when you need a file's imports and headers rather than full bodies. However, it does not state when to prefer this over siblings such as get_symbol_context or get_impact_slice, and it gives no explicit exclusions or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.