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

With no annotations provided, the description carries the burden of behavioral disclosure. It reveals the matching logic (exact or suffix) which is valuable, but it does not state whether the operation is read-only, what the return format is, or any performance implications. This is a partial disclosure.

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 two sentences, front-loaded with the core purpose, followed by a concise explanation of matching behavior. There is no redundant text or filler; every word earns its place.

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 one-parameter tool, the description covers the essentials (purpose and matching behavior), but it lacks a distinction from the closely related sibling 'find_imports' and does not mention output format or side effects. Given the low complexity, it is slightly incomplete.

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?

The schema has 0% description coverage, so the description must compensate. It clarifies the 'target' parameter by stating it is a module path and gives examples ('os', 'fmt', 'utils.foo'), and explains the matching rules. This adds meaning beyond the bare schema definition.

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 the tool's purpose clearly: 'Find files that import the given module/target.' It uses a specific verb and resource, and provides examples of matching patterns. However, it does not explicitly distinguish this from the sibling tool 'find_imports', which could cause confusion for an agent.

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 explains matching semantics (exact or suffix module paths) which implies when to use it, but it does not explicitly state when to prefer this over alternative tools like 'find_imports' or provide exclusions. There is no mention of use cases or limitations.

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

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

With no annotations, the description must disclose behavioral traits. It mentions source order, which is useful, but does not specify the output format, error handling, or any side effects. It is implied to be read-only but not explicitly stated.

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 a single, front-loaded sentence with a clear verb and object. No unnecessary words or redundancy.

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 no annotations and no output schema, the description lacks essential context: it does not explain what constitutes an import, what the output looks like, or any prerequisites. An agent cannot fully predict the tool's behavior from this description alone.

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 must compensate. It only refers to 'a single file', which adds no meaning beyond the schema. It does not clarify whether the path should be absolute or relative, what file types are supported, or how the file is resolved.

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 the verb 'List' and the resource 'what a single file imports', plus the qualifier 'in source order'. It is specific and unambiguous, but it does not explicitly differentiate from the sibling tool find_importers, which is the reverse operation.

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?

No guidance is provided on when to use this tool versus alternatives like find_importers. The description only states what it does, without context about typical use cases or exclusions.

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

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

With no annotations, the description carries full disclosure. It accurately describes the return content (name, kind, line range, signature) and notes it is a read operation without side effects. It lacks mention of error conditions or performance, but for a simple listing tool this is sufficient and not misleading.

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 two sentences, front-loaded with the core action and immediately followed by usage context. Every sentence earns its place; no fluff or redundancy.

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 single-parameter, read-only tool with no output schema, the description adequately covers the purpose, return content, and rationale. It does not discuss error handling or file size limits, but these are unlikely to be critical for a symbol-outline tool, and the guidance about selective retrieval fills the main gap.

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 must explain the 'file' parameter, but it does not go beyond the schema's type 'string'. It is implied that 'file' is a path, but no format, expected extension, or validation is mentioned. The description adds no detail about the parameter, leaving the agent to infer.

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 the tool lists every symbol in a file, in source order, with a specific verb and resource. It distinguishes itself from siblings by framing it as an alternative to reading whole files, making its purpose unambiguous.

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?

It explicitly instructs 'Use this instead of reading a whole file' and explains the benefit: the agent can pull only the symbol bodies it needs. This provides clear when-to-use guidance and implicitly differentiates from file-reading or symbol-lookup tools.

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

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

With no annotations, the description carries the full burden. It discloses the efficient byte-range read (no whole-file read), which is a positive behavioral trait. However, it does not mention error handling (e.g., symbol not found), behavior when both id and name are provided, or any prerequisites like an index. These gaps are notable for a tool with zero annotation support.

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 no waste. The primary purpose is front-loaded, followed by a key behavioral detail and a clear usage instruction. Every word earns its place.

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?

The description covers the return type (byte range) and parameter selection, but omits error scenarios, precedence rules when both id and name are given, and any dependency on an index (given siblings like index_folder). It is adequate for straightforward calls but not fully complete.

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?

The schema has 0% coverage, so the description must clarify parameter meaning. It explicitly explains that symbol_id and name are alternative identifiers, and file is optional for name-based lookup. This adds the crucial OR relationship and the role of file, going beyond the bare 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 states a specific verb ('fetch') and resource ('symbol's exact source'), and distinguishes itself from siblings by emphasizing the precise byte range and that it returns only the needed body. This clearly separates it from tools like get_file_outline or search_symbols.

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?

Usage is implied through the description's purpose and the note 'Provide symbol_id OR name', but it does not explicitly mention when to prefer this over siblings or any exclusions. The benefit statement ('so an agent gets only the function/class body it needs') gives context but no direct comparison.

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

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

No annotations are provided, but the description discloses side effects well: it walks the tree, parses with tree-sitter, stores in SQLite, is safe to re-run, and replaces files idempotently. This gives the agent a clear expectation of write behavior.

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?

Three concise sentences cover purpose, process, safety, and return value without redundancy or extraneous detail. The structure is clean and directly usable.

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?

The description adequately explains what the tool does and what it returns, but 'counts of what was indexed' is slightly vague regarding whether counts refer to files, symbols, imports, or all of these. Still, it is sufficient given the simple interface and sibling tool context.

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?

Although the schema only states 'Path' as a string, the description adds critical meaning: path is a directory, accepts absolute or relative forms, and scopes indexing to files under it. This fully clarifies the sole parameter.

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?

Description uses specific verb 'Index' and clearly identifies the resource: every supported source file under a given path. It is distinct from sibling read/search tools, making its purpose unambiguous.

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 clearly conveys this tool is for building/refreshing the index, which is implicitly a prerequisite for search-oriented siblings. However, it does not explicitly name alternatives or state when not to use this tool.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the action but does not mention return format, potential errors, or any dependencies (e.g., whether an indexer must be loaded). For a trivial read-only query, this is acceptable but lacks detail about the output structure.

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, clear sentence with no filler. The description is front-loaded with the action and resource, making it instantly understandable.

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?

Given the tool's simplicity (no parameters, no annotations, no output schema), the description is nearly complete. It states what it returns but does not specify the format (e.g., array of strings) or any prerequisites. Since the tool is self-explanatory, this is adequate, though slightly more detail could be added.

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?

The tool has zero parameters, and the schema coverage is 100% (vacuously). Per the rubric, a 0-parameter tool gets a baseline of 4. The description does not need to add parameter details since none exist.

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 the tool's function: returning the supported languages of the indexer. It uses a specific verb ('Return') and a clear resource ('languages this indexer supports'), making it distinct from sibling tools like stats, search_symbols, or find_imports. No ambiguity or tautology.

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 implicitly indicates this is a simple query to retrieve language support. There are no closely related alternatives among siblings, so explicit when-not guidance is unnecessary. However, it does not explicitly state when an agent should call it, but the context is clear given the tool's purpose.

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

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

No annotations are provided, so the description must carry the full burden. It discloses that it returns matches with specific fields and that it is a search operation, implying read-only behavior. It does not mention pagination, limit semantics, error handling, or performance characteristics, which would be useful for a search tool.

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 two sentences with zero waste. It front-loads the core purpose and return format, then provides the filter guidance and pointer to the sibling tool. Every sentence earns its place.

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 search tool with no output schema and no annotations, the description covers the main expectations: what it searches, what it returns, and how filters work. It also points to get_symbol_source for body text. Missing details like pagination or limit behavior are minor given the simplicity of the tool.

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 must compensate. It explains kind and language filters with concrete examples, but does not explain the query parameter (beyond substring matching) or the limit parameter's behavior. It adds value for two of four parameters but leaves the other two without added meaning.

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 ('Search indexed symbols by name substring') and explicitly lists the return fields (qualified name, kind, language, file path, line range). It also distinguishes itself from the sibling get_symbol_source by indicating that tool fetches exact body text, which clarifies its own scope.

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?

It provides explicit guidance on when to use get_symbol_source instead, and explains how the kind and language filters work with examples. However, it does not mention other siblings like find_imports or get_file_outline, so it is not exhaustive but still clear about its primary use case.

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

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

With no annotations provided, the description must carry the behavioral disclosure. It indicates a read operation via 'Return', implying no side effects. However, it does not explicitly state that it is read-only, nor does it mention any requirements or limitations (e.g., behavior with empty index). This is adequate for a simple stats tool but leaves some behavioral details implicit.

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 a single, dense sentence with no redundant words. It front-loads the purpose and lists the specific data points returned, making it highly scannable.

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?

Given the low complexity (no params, no annotations, no output schema), the description adequately conveys the tool's function and return contents. It does not explicitly mention the scope (e.g., current index or project), but this is likely implied by the tool's name and context. Minor gap, but not critical.

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?

The tool has zero parameters, and the schema is empty (100% coverage). The baseline for 0-parameter tools is 4, and the description does not need to add parameter details. It correctly focuses on the output rather than inputs.

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 the specific verb 'Return' and the resource 'index stats', and enumerates the exact contents (file count, symbol count, per-language breakdown). This clearly distinguishes it from siblings like list_languages or search_symbols, which serve different purposes.

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 gives no guidance on when to use this tool versus alternatives. It does not mention any prerequisites (e.g., an index must exist) or contrast with list_languages, which also provides language-related information. The agent is left to infer the appropriate context.

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