Module dependents

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

With no annotations, the description carries the burden and does provide meaningful behavior: Tree-sitter extraction, lexical scope, and dynamic-import flagging. It still omits output shape, whether the result is direct or transitive, and what 'indexed' implies operationally.

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 sentences, with the core operation front-loaded and the key limitation in the second sentence. No filler or repetition.

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?

No annotations, no output schema, and 0% parameter documentation leave significant gaps: return format, relationship to sibling impact/symbol tools, selection semantics when both path and module are provided, and error/indexing requirements. The description covers only the core behavior.

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%, and the description only clarifies that path or module selects a single indexed entity. It does not explain profile, max_tokens, or how repo_id is used, leaving most parameters underspecified.

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?

States a specific action—'Return Tree-sitter-extracted lexical import relationships'—for a clear resource ('one indexed path or module') and distinguishes itself from semantic resolution and call-graph inference. It does not explicitly name a sibling tool, so differentiation is conceptual rather than direct.

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 a read-only, lexical-use context and warns that dynamic imports are flagged rather than resolved, which suggests it is not for semantic dependency analysis. However, it never names sibling tools like get_impact_slice or gives explicit when-to-use/when-not-to-use criteria.

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