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

No annotations are provided, so the description must carry full weight. While it describes what the tool returns (entry point, call path), it doesn't disclose any side effects, authentication requirements, or rate limits. The behavioral traits are only partially specified.

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 concise (two sentences), front-loads the core purpose, and contains no superfluous information. Every sentence adds value.

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 2 parameters and no output schema, the description provides sufficient context: it states the return type (entry point, call path) and usage context. However, it does not describe the return format or behavior when no entry point is found, which would be helpful for completeness.

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 50% (only 'k' has a description). The tool description mentions 'feature' but does not elaborate on the 'query' parameter's format or expected input. It adds marginal value beyond the schema, but does not fully compensate for the missing description of 'query'.

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 defines the tool's purpose with a specific verb ('Returns') and resource ('entry/boundary that dominates the feature'). It also distinguishes from the sibling 'locate' by specifying that 'entry_point' is for understanding where a feature begins, while 'locate' is for finding where a symbol is defined.

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 explicitly states when to use this tool ('where do I start to understand X') and when not to use it ('for 'where is symbol X defined' use locate'), providing clear guidance for the AI agent.

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 burden. It discloses the BFS algorithm and k-hop limit, but does not mention if it's read-only, error handling, default for k, or performance traits.

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?

One tightly packed sentence with no wasted words. Front-loaded with the core algorithm name (BFS), efficiently conveying the essential constraints.

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 output schema exists, yet the description omits what the tool returns (nodes, edges, paths?). Missing any mention of limits on k, error conditions, or relationship to sibling tools.

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 coverage is 0%, but description adds meaning for all parameters: 'k hops' for k, 'ONE edge family' for edge_type, and 'from a node' for id. The example 'calls' clarifies enum usage. However, id could be more precisely defined.

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 it performs BFS up to k hops along a single edge family from a node, using 'calls' as an example. It differentiates from siblings like 'neighbors' (likely one-hop) and 'search' (different scope), but doesn't specify the output type.

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 usage for traversal along a single edge type with limited depth, but provides no explicit when-to-use or when-not-to-use guidance. No contrast with other tools like 'neighbors' or 'locate' is given.

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 cover behavioral traits. It lists returned fields but does not mention any side effects, permissions, rate limits, or whether it is read-only. The term 'generated summary/context' implies a fetch, but explicit read-only hint is missing.

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 purpose ('A node's generated summary/context') and immediately explains parameter usage. 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?

Given the tool's simplicity (2 params, no output schema), the description covers the basics. However, it does not define 'node' or its relationship to sibling tools, and it lacks output details (e.g., format of the returned fields). Additional context would help.

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 compensates well: it explains that 'id' is for a single node and 'ids' for multiple nodes. This adds meaning beyond the bare schema. Could be improved by specifying format or constraints.

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 returns a node's generated summary/context with specific fields (title, summary, etc.). It distinguishes between single and batch retrieval via 'id' vs 'ids'. However, it does not differentiate from sibling tools like 'get_source' or 'get_minimal_context'.

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 basic guidance on using 'id' for one node and 'ids' for multiple nodes, but lacks when-not-to-use instructions or alternatives among siblings. No explicit context for selection.

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 provided, but the description discloses the approximate output size (100 tokens) and content (stats, top nodes). It is a safe read operation with no side effects mentioned. Could be improved by explicitly stating it is read-only, but the description is transparent enough.

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, no wasted words. The first sentence defines the tool, the second adds usage guidance. Perfectly front-loaded and concise.

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 output schema), the description fully covers its purpose, content, and usage context. No gaps.

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?

No parameters exist, so the description does not need to add parameter details. The baseline for zero parameters is 4, and the description explains what the output contains, adding value beyond 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 the tool provides a ~100-token orientation with stats and top nodes by importance. It distinguishes itself from siblings by noting it is not a prerequisite, implying other tools are for deeper exploration.

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?

Explicitly says to call only for a quick lay of the land, and that it is NOT a prerequisite for other tools. This provides clear when-to-use and when-not-to-use guidance.

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 adds behavioral context: the tool ranks summaries by PageRank and packs them to a token budget. However, it does not disclose potential costs, auth needs, or whether it mutates state, which is a gap for a read-oriented 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?

Two sentences: the first defines the tool's output, the second gives a usage cue. No redundancy, every word contributes value.

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 simple input schema and no output schema, the description explains what the tool returns (summaries) and the ranking method (PageRank), but lacks details on output format (e.g., text, JSON) or how the budget affects results, leaving some ambiguity.

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 coverage is 100% with one parameter 'budget' described as 'token budget (default 2000)'. The description adds the meaning of 'packed to a token budget', which aligns with the schema, but does not provide additional constraints or examples.

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 provides file/package summaries ranked by PageRank, which is a specific purpose. It also gives a use case ('orient on an unfamiliar repo'), but does not explicitly differentiate from all sibling tools, though its unique output distinguishes it.

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 usage for orientation ('Reach for it to orient on an unfamiliar repo') but does not provide explicit when-not-to-use or alternatives, leaving usage context implicit.

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 fully disclose behavior. It mentions the operation is 'expensive' but fails to explain error handling, rate limits, or what happens if the node does not exist. The return format is not described, leaving significant gaps for an agent.

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 extremely concise: two short sentences convey purpose, usage guidance, and parameter hints. No unnecessary words.

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 complexity (2 params, no output schema), the description covers purpose and parameter usage but omits the return value structure, error scenarios, and prerequisites. It is adequate but not 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?

Schema descriptions are missing (0% coverage), so the description adds meaning by explaining the difference between `id` and `ids`. However, it implies these are mutually exclusive ('for one' vs 'for several'), which the schema does not enforce, potentially misleading an agent.

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 retrieves 'raw source' for a node, contrasting with `locate` which provides a snippet. However, it does not define what 'source' means in this context (e.g., code text), and only differentiates from one sibling, leaving ambiguity with other siblings like `get_context`.

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 explicitly says `locate` already includes a snippet, so this tool is often unnecessary, providing direct when-to-use guidance. It also labels the operation as 'expensive', implying careful use. However, it does not address alternatives like `search` or `get_context` for similar purposes.

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 carries the entire burden. It describes the output (ranked hits with summaries and snippet) but does not disclose behavioral traits like read-only nature, side effects, permissions, or limitations beyond being a one-call 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, front-loaded with the main action and output, followed by usage guidance. Every sentence adds value with no 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?

Given the tool's simplicity (2 params, no output schema), the description covers the core functionality and output structure. It lacks details on parameter ranges, error conditions, or permission requirements, but for a search tool this is reasonably 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 input schema has 50% description coverage (only 'k' has a schema description). The description adds context that 'query' represents a feature or symbol, but does not explain the 'k' parameter or provide format constraints. More parameter detail in the description would help.

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 finds where a feature/symbol lives, returning ranked hits with summaries and a top-hit snippet. It differentiates from siblings by emphasizing 'ONE call' and 'no setup call required.'

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 explicitly says 'Start here for "where is X" / "where do we do Y" — usually all you need; no setup call required first.' This provides clear context for when to use the tool, though it does not list explicit alternatives 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 must fully disclose behavior. It states the tool returns neighbors grouped by type, but it does not mention read-only status, performance implications, pagination, or potential side effects. This is insufficient for a tool that likely returns a complex structured result.

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 sentence that efficiently conveys the core functionality with no redundant words. It is appropriately sized for a simple tool.

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 no output schema and potential overlap with siblings, the description lacks important details: the meaning of 'adjacent', the structure of the response, and the enumeration of edge families. It is not complete enough for an agent to use 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?

The schema has 0% description coverage for the only parameter 'id'. The description does not explain what 'id' refers to (e.g., a node identifier in the graph). The parameter is left implicit, which may confuse agents unfamiliar with the domain.

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 that the tool returns all adjacent nodes of an id, grouped by edge family. This provides a specific verb-resource combination and distinguishes from siblings by mentioning edge family grouping. However, it could be more explicit about what 'adjacent nodes' means.

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 given on when to use this tool versus alternatives like 'get_context', 'expand', or 'pack_neighborhood'. There is no mention of prerequisites, exclusions, or typical use cases.

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 should disclose behavioral traits. It mentions 'source packed in topological order to a token budget' but does not clarify side effects, output format, or required permissions. The behavior is opaque.

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 sentence, making it concise. However, it is cryptic and lacks structure, reducing readability and clarity. It would benefit from clearer organization.

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 output schema is provided, and the description does not mention what the tool returns. For a complex operation like packing a neighborhood, this is a critical gap. The tool's role among siblings (e.g., locating, searching) is also unclear.

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 relates 'hops' to 'k-hop dependency' and 'budget' to 'token budget', but does not explain each parameter's meaning, format, or constraints. The description is insufficient for understanding parameters.

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 mentions 'k-hop dependency neighborhood' and 'packed in topological order to a token budget', which gives a vague sense of the operation. However, it lacks a clear verb and does not explicitly state what the tool returns or accomplishes, making it moderately unclear.

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. The phrase 'single-shot static fallback' hints at a fallback role but does not specify context or conditions.

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?

Despite no annotations, description reveals key behaviors: outputs summaries (not source), hybrid method, ranked ordering, no snippets, returns several candidates. This covers main behavioral aspects 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?

Two sentences with zero wasted words. Each sentence adds distinct value: first defines the hybrid nature and output type, second specifies behavior and alternative. Ideal conciseness.

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?

While it addresses purpose and one sibling, it doesn't cover the broader toolset context (e.g., when to use get_context vs. search) or return format details. Given the sibling count and no output schema, more context would improve completeness.

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 coverage is only 50% (k described, query not), and description adds no further parameter information. It doesn't clarify query syntax or how k affects results, failing to compensate for the schema gap.

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 clearly states it performs hybrid search returning ranked summaries (not source), and distinguishes itself from the sibling 'locate' by noting it returns multiple candidates. This gives a specific verb+resource with clear 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?

Explicitly advises preferring 'locate' when only one item is needed, providing a clear alternative. Implies usage for multi-result scenarios, but does not contrast with other siblings like get_context or get_source.

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