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

Discloses output details (event names, parameters, etc.) and pagination support. Lacks mention of side effects or permission requirements, but tool is read-only analysis. No annotations to contradict.

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?

Concise, uses few sentences, front-loaded with purpose. Could be slightly more structured but effective.

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 annotations and presence of output schema, description covers purpose, usage, and pagination. Missing error handling or performance details but adequate for a code analysis 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?

Description does not describe input parameters beyond mentioning 'path' implicitly and 'supports pagination'. Schema has detailed parameter descriptions but coverage is 0% in description; description adds minimal value to parameter understanding.

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 the tool analyzes event definitions across project or specific contract. Distinguishes from sibling tools like analyze_modifiers or analyze_low_level_calls by focusing on events.

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 states when to use (understanding events, indexed parameters, auditing logging) and what not to do (does not find emissions). Suggests alternative action (search source code).

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 provides behavioral context: returns functions grouped by call type with source locations, supports pagination, and is critical for reentrancy and proxy pattern analysis. It doesn't mention permissions or side effects, but as a read-only analysis tool, this is sufficient.

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 four sentences, front-loaded with purpose and usage. Every sentence adds value: purpose, security context, output format, and critical use cases. No wasted 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 presence of an output schema (not shown but context indicates it exists), the description does not need to detail return values. It covers key behavioral aspects like grouping, source locations, and pagination. The scope is well-defined for a security analysis tool among many siblings.

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?

Context signals indicate 0% schema description coverage, so the description must compensate. However, the description only lists the call types and mentions pagination, but does not explain parameters like path, limit, offset, contract_key, or visibility_filter. The agent must infer these from the schema alone, which may still be adequate but relies heavily on 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 the tool finds all functions using low-level calls (call, delegatecall, staticcall, assembly). It distinguishes from sibling tools like analyze_events or analyze_modifiers by focusing on low-level call vulnerabilities.

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 recommends using this tool for security auditing, explaining that low-level calls bypass Solidity type safety. While it doesn't state when not to use it, the context is clear and helpful for an 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 provided, the description carries the burden. It states the output type (definitions with source and function list) and pagination. However, it does not disclose whether it is read-only, any required permissions, or potential side effects. For an analysis tool, the behavior is largely implied but not explicit.

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 with three sentences that are front-loaded with purpose and use cases. It avoids fluff but could be slightly more structured with parameter hints.

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 (nested parameters, many siblings, output schema exists), the description covers purpose and output shape but omits optional filtering capabilities (contract_key, modifier_filter). It adequately handles pagination but is not fully complete for a tool with optional parameters.

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% at the top level, and the tool description only mentions pagination (hinting at limit/offset). The nested schema has detailed descriptions, but the tool description adds no extra meaning for the key parameters like path, contract_key, or modifier_filter.

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 'Analyzes' and the specific resource 'custom modifier definitions and their usage across functions', distinguishing it from sibling tools like analyze_events or analyze_low_level_calls.

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 gives explicit use cases: auditing access control, finding implementations, understanding guards. It also mentions pagination support. However, it does not explicitly exclude sibling tools or state when not to use.

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?

The description discloses that the tool returns 'variable details including type, visibility, and declaration location' and supports pagination. While no annotations exist, the description implies a read-only analysis tool and does not contradict any known behaviors. It could mention non-destructiveness explicitly, but the context is sufficient.

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 with three sentences. The first sentence states the main purpose, the second provides context and distinction from siblings, and the third mentions output details. No unnecessary words 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?

Given the complexity (multiple filter options, pagination) and the presence of an output schema, the description covers all necessary aspects: purpose, usage guidance, output details, and alternatives. It is complete for an analysis 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?

The input schema already provides detailed descriptions for each parameter (e.g., 'Path to the Solidity project directory', 'Maximum number of results to return'). The description adds only general mentions of filtering options like 'visibility, include/exclude constants and immutables', but does not provide additional semantic value beyond what the schema conveys.

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 'Analyzes state variables across the project or for a specific contract' and provides concrete use cases like 'auditing storage layout, finding public state, or understanding contract data.' It also distinguishes from a sibling tool by mentioning 'For storage slot layout, use get_storage_layout.'

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 when to use this tool (e.g., 'when auditing storage layout, finding public state, or understanding contract data') and when not ('For storage slot layout, use get_storage_layout'). It also mentions optional filtering capabilities, providing clear 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?

No annotations provided, but the description discloses that output is a string suitable for rendering, may be large for big projects, and suggests using max_nodes to limit. This is good behavioral context beyond minimal requirements.

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?

Four sentences, front-loaded with purpose and format, each sentence earning its place. No fluff.

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 output schema exists, description covers return type and format. Could mention error handling or contract_key subfields, but overall complete for the tool's scope.

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 provide parameter details (coverage 100% in schema), but the tool description adds value by summarizing filtering options (contracts, entry points) and size warning. Baseline 3, plus extra context.

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 exports the project's function call graph in Mermaid or DOT format, specifying verb and resource. It distinguishes from sibling tools (e.g., get_function_callees) by focusing on visual export.

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 says 'Use this when you need a visual representation...or for documentation', providing clear context but no explicit when-not-to-use or comparison to alternatives like get_function_callees/get_function_callers.

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 fully bears the burden. It discloses that the tool returns uncalled functions with metadata, supports pagination, and has a false negative limitation for dynamic calls. This goes beyond the input schema and provides useful behavioral context.

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 five sentences covering purpose, usage, capabilities, return, limitation, and pagination. It is well-structured and front-loaded with the core purpose, though it could be slightly more 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 complexity of dead code analysis and the presence of an output schema, the description adequately covers key aspects: purpose, usage, limitations, and pagination. It lacks prerequisites (e.g., project must compile) but is otherwise sufficient.

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% (though the schema itself includes parameter descriptions). The description adds context for some parameters (exclude_entry_points, exclude_test_frameworks, include_inherited, pagination) but does not cover contract_key or exclude_paths. It adds moderate value beyond 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 uses the specific verb 'Finds' and the resource 'functions with no callers (potential dead code)', clearly distinguishing it from sibling tools like get_function_callers or run_detectors. The purpose is immediately clear.

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 states when to use the tool ('code cleanup, auditing, understanding coverage') but does not explicitly mention when not to use it or provide alternatives from the sibling list. It does note a limitation (dynamic calls not detected), which offers some 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?

No annotations are provided, so the description must disclose behavioral traits. It only mentions the return value ('Returns the full ContractModel with all relationships'), but does not address side effects, error handling, permissions, or any destructive behavior. The description fails to compensate for the lack of annotations.

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 three sentences, each serving a distinct purpose: stating the function, providing usage context, and indicating output and alternatives. No superfluous words or details, and the purpose is front-loaded.

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 that schema description coverage is 0% and there is an output schema (though not shown), the description partially compensates by detailing the return content (inheritance, functions, etc.). However, it does not explain how to use the parameters (especially include_functions) or cover potential error states, making it adequate 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 input schema has one required parameter 'request' with nested properties (path, contract_key, include_functions). Schema description coverage is 0% per context signals, meaning the schema descriptions are not considered. The description adds some meaning by listing what is returned (inheritance, functions, etc.), hinting at the effect of include_functions, but does not explicitly document parameter usage or syntax beyond what is in 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 uses the specific verb 'Gets' and resource 'detailed metadata for a specific contract', listing concrete elements like inheritance hierarchy, functions, state variables, and events. It also distinguishes from sibling tools by mentioning 'get_contract_source' for source code and implying it's used after listing or searching.

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 ('when you need complete information about a contract after finding it with list_contracts or search_contracts') and provides an alternative for source code ('For source code, use get_contract_source instead.'). However, it does not explicitly mention other contexts where the tool should not be used, though the guidance is clear enough.

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 mentions that the tool returns 'categorized dependencies with optional circular dependency detection,' but does not disclose performance implications, whether it modifies data, or permission requirements. For a read-only analysis tool, this is adequate but lacks depth.

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 with two sentences. The first sentence defines the core functionality, and the second provides usage guidance. No extraneous information, well front-loaded, and efficient.

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 presence of an output schema, the description need not detail return values, but it does mention categorization and circular detection. However, it lacks completeness by not clarifying how to specify the contract or the role of the 'path' parameter. For a tool with many optional parameters, more context would be beneficial.

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 description does not mention any parameter details despite the input schema having multiple optional parameters (contract_key, detect_circular, etc.) with zero schema coverage. The schema itself contains parameter descriptions, but the tool description adds no additional semantics, leaving the agent to rely solely on 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 uses the verb 'maps' to clearly indicate the action, specifies the resource as 'dependencies for a specific contract', and lists the types of dependencies (inheritance, external calls, library usage). This effectively distinguishes it from sibling tools like get_inherited_contracts or get_derived_contracts.

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: 'when understanding what a contract depends on, finding coupling issues, or detecting circular dependencies.' While it does not provide explicit when-not-to-use or alternative tools, the guidance is clear and actionable, earning a 4.

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, so description carries full burden. It explains return format (string) and optional line range filtering via start_line and max_lines. However, it lacks details on error scenarios, permissions, or performance implications.

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. First sentence states core purpose, second adds usage guidance and parameter details. Highly efficient and well-structured.

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 retrieval tool with an output schema, description covers purpose, usage context, and filtering options. Lacks mention of error handling or prerequisites beyond list_contracts, but sufficient for agent understanding.

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 description must add meaning beyond schema. It mentions start_line and max_lines parameters and their filtering role, but does not explain contract_key or path. Some value added but not comprehensive.

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 explicitly states verb 'Retrieves' and resource 'source code of a contract from the original Solidity file', clearly distinguishing it from sibling tools like get_function_source or get_contract by specifying it returns only the contract's portion of the file.

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?

Provides explicit usage context: 'Use this when you need to read the actual implementation after finding a contract with list_contracts.' Also gives an alternative for full file reading, though does not name the specific sibling 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 full burden. It discloses that the output is a recursive tree, and that max_depth can limit recursion, with a truncated flag returned if exceeded. No additional behavioral traits like permissions or performance are mentioned, but core behavior is transparent.

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 sentences: purpose, usage guidelines, and behavioral detail. Every sentence adds value, with no redundancy. Front-loaded with the main action.

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 main behavior (recursive tree, depth limit) and output format (truncated flag). Given the complexity and the presence of an output schema, the description is largely complete. It could explicitly contrast with the upward traversal sibling for extra clarity, but is already sufficient.

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 describes parameters (path, max_depth, contract_key) with descriptions. The description adds the note about max_depth limiting and a truncated flag, which goes beyond the schema. However, coverage is sufficient for understanding, and the description does not significantly enhance understanding beyond the schema's own documentation.

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 gets all contracts that inherit from a specific contract (downward traversal). It distinguishes from the sibling tool 'get_inherited_contracts' which likely does upward traversal, making the 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?

Explicit use cases are given: finding implementations, impact analysis, discovering variants. It does not explicitly exclude alternatives, but the context of siblings implies when not to use (e.g., when looking for parent contracts).

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, so description must disclose behavior. It reveals returned categorization (internal, external, library), low-level call flag, and non-recursive nature. No contradictions with annotations.

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, front-loaded with purpose. Every word earns its place; 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 complexity (call graph analysis), the description covers purpose, usage, limitations, and return categories. An output schema exists, so return value details are not needed here. Minor gap: no mention of required parameters.

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 already provides detailed descriptions for all parameters (e.g., path, function_key, include_query_context), so baseline is 3. The description adds no extra parameter details, but the schema suffices.

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 explicitly states the tool retrieves functions called by a specific function (outgoing edges), distinguishing it from siblings like get_function_callers. It also categorizes callees, adding specificity.

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 advises using when tracing internal function behavior, finding dependencies, or understanding control flow. It also notes the tool does not recurse, implying repeated calls for deeper traces. However, it does not explicitly contrast with siblings.

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, so description carries full burden. It discloses return categories (internal, external, library) and general use cases, but lacks details on limitations (e.g., recursion, analysis requirements). Adequate but not exhaustive.

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 concise sentences plus a short phrase about usefulness. No wasted words, front-loaded with core purpose.

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?

With an output schema present and no annotations, the description explains purpose and return categorization well. Could mention prerequisites or error conditions, but overall complete for agent to use correctly.

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?

Tool description does not cover parameters (schema coverage 0%), but the input schema itself has thorough descriptions for path, function_key, and include_query_context. Baseline 3 is appropriate as agent can rely on 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 gets all functions that call a specific function, with specific use cases (entry points, usage patterns, impact). It distinguishes from siblings like get_function_callees by focusing on incoming edges.

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 when to use it (finding entry points, understanding usage, impact assessment, dead code detection, refactoring). Could improve by noting when not to use or comparing to alternatives, but current context is sufficient.

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 discloses that the tool returns the function body with line numbers, indicating the output format. It also implies a read-only operation by saying 'retrieves'. There is no mention of side effects, but the description is sufficiently transparent for a read-only 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 three sentences long, each serving a distinct purpose: stating the action, suggesting when to use, and describing the output and requirements. 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 tool's simplicity and the presence of an output schema, the description is complete. It covers what, when, and the output format. It could mention the return type briefly, but the output schema likely covers that.

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 already includes detailed descriptions for each parameter (path, signature, contract_name). The description adds value by explaining that these collectively uniquely identify the function, which is not explicitly stated in the schema. The description uses the term 'contract_key' loosely, but the intention is clear.

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 retrieves the source code of a specific function, with a specific verb ('retrieves') and resource ('source code of a specific function'). It distinguishes from sibling tools like list_functions and search_functions by explicitly stating its purpose of reading implementation details after those discovery tools.

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 advises to use this tool after finding a function with list_functions or search_functions, providing clear context for when to invoke it. It does not explicitly mention when not to use it, but the guidance is still strong and actionable.

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?

The description discloses behavioral traits: returns a recursive tree structure, uses max_depth to limit traversal, and returns a truncated flag if depth exceeded. No annotations are present, so the description fully carries the burden.

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: purpose, usage guidelines, and behavioral details with parameter hint. 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?

The tool has moderate complexity with a single required object parameter. Description explains output type (recursive tree) and truncation behavior. No annotations provided, but output schema exists. Some minor gaps (e.g., exact output structure) are covered by schema.

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% (the free text does not describe parameters), but the description adds value for max_depth by explaining its effect. The schema itself provides parameter descriptions, but the tool description could be enhanced by mentioning path and contract_key.

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 'Gets the inheritance tree of parent contracts (upward traversal)', specifying the verb, resource, and direction. It distinguishes from sibling 'get_derived_contracts' which provides downward traversal.

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 the tool: 'when understanding what a contract inherits, finding the source of inherited functions, or analyzing the inheritance hierarchy.' It does not explicitly mention when not to use, but the context of siblings implies alternatives.

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 implies a read-only behavior by stating it retrieves statistics. It does not mention side effects or authorization needs, but the nature of the tool (aggregation) suggests safety. Could be improved by explicitly stating it does not modify data.

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 that efficiently convey the tool's purpose, usage context, and limitations. 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?

For a simple read-only aggregation tool with one parameter and an output schema, the description covers all necessary aspects: what it does, when to use it, what it returns (counts/distributions), and how it differs from detail 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?

The description does not explain the single parameter (path). Schema description coverage is 0% (the top-level parameter lacks a description field), so the tool description should have compensated. However, the schema includes a description inside the nested definition, but the tool description itself adds no parameter context.

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 gets aggregate statistics about the entire project, specifying contract counts by type, function counts by visibility, and security findings by impact level. It distinguishes itself from sibling tools by directing users to list_contracts and run_detectors for details.

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 states when to use: 'as a starting point when exploring an unfamiliar codebase or generating project summaries.' Also clarifies what it does not provide ('not detailed data') and recommends alternative tools for detailed analysis.

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 that constants and immutables are excluded, inherited storage can be toggled, and pagination is supported. This goes beyond what the schema indicates, though performance or permission details are 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 three sentences long, front-loads the purpose, and every sentence contributes meaningful information. There is no wasted text.

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 of storage layout analysis, the description covers essential aspects: exclusions, inheritance option, pagination, and use cases. An output schema exists, so return values need not be described. A minor gap is lack of mention that the tool is read-only, but overall it is fairly 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 description adds value by mentioning pagination and the include_inherited option, which hints at limit/offset and include_inherited parameters. However, it does not describe path or contract_key structure, and the schema descriptions already cover them, so the added value is moderate.

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 computes storage slot layout, including slot numbers, byte offsets, and variable sizes, and lists use cases. It is specific about the resource and action, though it does not explicitly distinguish from sibling tools.

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 lists when to use the tool (upgrade safety, storage collision detection) but does not provide explicit guidance on when not to use it or alternatives among the many sibling tools. Usage is implied rather than spelled out.

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, so description carries full burden. It discloses return metadata (name, path, type flags, inheritance list), states it does not include function details, and mentions pagination support. No contradiction.

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 concise sentences. First sentence states operation and options. Second gives use cases and limitations. No wasted 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 presence of an output schema, description does not need to detail return structure. It covers main use cases, limitations, and pagination. Sufficient for a listing 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 description must compensate. It mentions path and type filtering and pagination (offset/limit), but does not detail sort_by, sort_order, exclude_paths. Partial compensation; still helpful.

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?

Clearly states it lists all contracts in a Solidity project with optional filtering. Distinguishes from siblings by specifying its scope and what it omits (function details), directing users to get_contract for deeper info.

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 when to use: discovering contracts, filtering tests/libraries, finding specific types. Also says when not to use: don't need function details, use get_contract instead.

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 states it does not run detection and returns metadata, implying a read-only operation. However, it doesn't explicitly mention its read-only nature, authentication needs, or side effects. For a listing tool, this is adequate but could be more transparent about required permissions or lack of destruction.

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 includes all essential elements: purpose, usage context, return values, and distinction from sibling. Every sentence is informative with no wasted 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 tool's moderate complexity (4 parameters, output schema exists, no annotations), the description covers the purpose, return values, and distinguishes from the main sibling. It mentions filtering but not pagination or the required path parameter. Still, it provides sufficient context for an agent to select and use the tool correctly, especially with the presence of an output schema.

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 for parameters exist (path, limit, offset, name_filter) but the tool description does not explain them in detail beyond mentioning filtering by name. It adds value by linking the name_filter to the tool's purpose, but misses clarifying that path is required or pagination parameters exist. With schema descriptions covering the parameters, the baseline is 3, and the description provides modest added context.

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 all available Slither security detectors with metadata, using specific verb 'Lists' and resource. It distinguishes itself from sibling 'run_detectors' by explicitly stating it does not run detection. Also mentions filtering by name.

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 when to use: 'to discover what security checks are available before running analysis, or to filter detectors by name'. It also gives a clear exclusion: 'Does not run detection; use run_detectors for that'. This provides good guidance, though it could mention other alternatives or when not to use.

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, so description carries full burden. It discloses that it returns contracts with implementation details and supports pagination. However, it does not explicitly state that the operation is read-only or mention any side effects, authentication needs, or performance considerations. The description is adequate but not comprehensive.

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 four sentences, each conveying essential information without redundancy. It is front-loaded with the main purpose, then use cases, then behavior. Very efficient.

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 main use cases and pagination. However, given the complexity of the search and presence of an output schema, it could mention error handling, result format, or limitations (e.g., case sensitivity). It is adequate but not thorough.

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 detailed descriptions for all parameters (function_signature, contract_key, path, limit, offset). The description adds no additional meaning beyond mentioning 'signature string' and 'pagination', which are already covered. Since schema_description_coverage is effectively high (schema descriptions are present), baseline is 3.

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 uses a specific verb 'Finds' and resource 'contracts that implement a specific function signature', clearly stating the tool's purpose. It distinguishes from sibling tools like search_functions or get_function_callees by focusing on implementations across contracts.

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 the tool: 'when looking for overrides of a virtual function, finding all implementations of an interface method, or understanding polymorphism'. It also mentions pagination support. However, it does not explicitly state when not to use or provide alternatives among siblings.

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 fully carries the burden of behavioral disclosure. It tells what is returned (signatures, visibility, modifiers, arguments, return types), what is not included (source code), and mentions pagination and sorting capabilities. This is sufficient for an agent to understand the tool's 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?

The description is concise at five sentences, each adding value. It is front-loaded with the core purpose and follows with usage guidance, output description, exclusions, and features. No extraneous information.

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 complexity, presence of an output schema (so return values don't need explanation), and rich input schema with descriptions, the description adequately covers filtering, exclusion of source code, pagination, and sorting. It could mention that it is a read-only operation, but that is implicitly clear. Overall complete for a listing 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?

The description adds some parameter context by mentioning filters for contract, visibility, and modifier usage, which correspond to contract_key, visibility, and has_modifiers. However, it does not detail parameters like path, limit, offset, sort_by, sort_order, or exclude_paths. Since the input schema already has detailed descriptions for these, the description adds marginal value, earning a baseline score of 3.

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 'Lists functions' with specific filtering options (contract, visibility, modifier usage). It explicitly distinguishes itself from get_function_source by stating what it does not include, and the verb 'list' combined with resource 'functions' is specific and actionable.

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 explicit usage scenarios: 'Use this when searching for functions with specific characteristics like external entry points, functions with modifiers, or private helpers.' However, it does not mention when not to use it or list alternatives like search_functions, which could provide a more targeted search.

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 carries the burden. It mentions that results are cached from initial analysis and returns findings with descriptions and source locations, but does not disclose whether the tool is read-only or any potential side effects.

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 with four sentences, each providing valuable information. It is front-loaded with the core purpose and adds filtering details and caching behavior without 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 has one required parameter and several optional filters, the description covers the main functionality. It mentions caching and return content. With an output schema present, the description is sufficiently complete for an agent to understand invocation.

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 0% description coverage, so the description must add meaning. It explains filtering by detectors, impact, confidence, and exclude paths, which maps to several parameters. However, not all parameters (like limit and offset) are explicitly mentioned, but pagination is implied by 'offset' in 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 it gets security findings from Slither's static analysis and mentions finding vulnerabilities, code quality issues, or informational findings. It does not explicitly differentiate from sibling tools but the purpose is specific enough.

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 a clear use case ('Use this to find vulnerabilities...') and mentions filtering options, but does not provide guidance on when not to use this tool or suggest alternatives among the many sibling 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?

No annotations provided, so the description carries the full burden. It discloses regex matching, case-insensitivity by default, optional case_sensitive parameter, supports pagination, and returns full metadata. This covers key behavioral traits 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?

Three sentences with no wasted words. Each sentence adds value: primary function, when to use, and behavioral notes (case-insensitivity, pagination). Front-loaded with verb and resource.

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?

Output schema exists so return values don't need explaining. However, with 0% schema coverage and multiple parameters (path, exclude_paths, limit, offset) not described, the description is incomplete for an agent to use the tool correctly without additional knowledge.

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 pattern and case_sensitive but fails to detail path (required), limit, offset, and exclude_paths. Without these, an agent may misuse or omit critical 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 clearly states it searches contracts by name using regex pattern matching. It distinguishes itself from siblings like list_contracts and search_functions by specifying the use case for partial names and naming conventions, making the purpose specific and actionable.

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 when to use: when you know part of a contract name but not exact path or when looking for conventions. It lacks explicit when-not-to-use or alternatives, but the use cases are clear enough for an agent to decide.

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 correctly implies a read-only search operation and mentions return of 'full metadata', but does not disclose any specific behavioral traits like auth requirements or rate limits. The description is adequate 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 five sentences with no wasted words. Each sentence adds distinct information: what it does, when to use it, scope options, output, and pagination. Well-structured and front-loaded.

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 has 8 nested parameters, no annotations, and an output schema exists, the description provides an adequate but incomplete overview. It covers core functionality and pagination but omits key parameter details, so the agent may need to rely on the input schema for full parameter semantics.

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 pattern and search_signatures implicitly, and hints at pagination (limit/offset), but fails to mention important parameters like path, deduplicate, exclude_paths, and case_sensitive. This leaves significant ambiguity for the 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 it searches functions by name or signature using regex, with a specific verb and resource. It distinguishes from siblings like 'list_functions' (which likely lists all functions) by specifying pattern-based search across the codebase.

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 'Use this when looking for functions...' providing clear context for usage. However, it does not mention when not to use or explicitly list alternatives, which would make it a 5.

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