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

With no annotations, the description carries the full behavioral burden. It discloses the return shape (reachable_nodes, distances, target_reachability), which signals a pure read-only analysis, but says nothing about graph-size limits, performance, or whether the diagram must be loaded first.

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?

Front-loaded with the core purpose, then structured Args/Returns sections with no filler. The docstring scaffolding (Args:/Returns:) is boilerplate but not wasteful.

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?

All three parameters are documented and an output schema also exists, so return values are covered. The main gap is the absence of any routing context relative to the many sibling tools, which is not strictly required for correct 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?

Schema description coverage is 0%, so the description must compensate, and it does: diagram_id, source, and targets are each given meaning, including that targets is optional and used for specific-node checks. It stops short of explaining format/syntax, but substantially closes the 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?

The first line gives a specific verb+resource ('Analyze reachability from source node') and the second clarifies the computation (reachable nodes and distances). It's clearly a graph-analysis operation, though it doesn't explicitly distinguish itself from the closest sibling, navigate_breadth_first.

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?

There is no when-to-use guidance, no prerequisites, and no mention of when to prefer this over navigate_breadth_first, navigate_guided, or explore_reasoning_space. The description only defines what the tool computes, leaving tool selection to inference.

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 it's a mutation ('modified diagram stats', 'Apply'), that it requires a match mapping, and that it returns success status. But it doesn't state whether the operation is reversible, whether it modifies in place, what permissions are needed, or how failures manifest beyond a 'success status'.

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?

Structured with clear Args and Returns sections. Front-loaded with the core action. Efficient and no wasted text, though the formal DPO terminology might be opaque to some agents.

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 objects, no schema descriptions, output schema exists), the description provides adequate context: it names the operation, references the prerequisite pattern_match, describes parameters, and mentions return value. It could more explicitly state workflow order or error behavior, but 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?

Schema description coverage is 0%, so description must compensate. It documents each parameter's meaning: diagram_id is the target, rule_spec is a serialized RewriteRule dict with lhs/rhs, match_mapping maps rule LHS nodes to diagram nodes. This is meaningful but doesn't fully specify the expected structure of rule_spec or match_mapping's format beyond a high-level description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: applying a formal DPO rewrite rule to a diagram. This is distinct from siblings like pattern_match (finding matches) or check_diagram_equivalence (comparison). However, it doesn't explicitly differentiate itself from those siblings or clarify its relationship to the pattern_match → apply workflow.

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 implies usage via the match_mapping parameter ('from pattern_match'), suggesting it should be called after a pattern match. But there's no explicit when-to-use, prerequisites section, or when-not-to-use guidance. An agent would infer the workflow but not with certainty.

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

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

With no annotations, the description carries the full behavioral burden, and it says almost nothing beyond the return type. It does not state that this is a side-effect-free read, nor warn about the potentially expensive nature of isomorphism checking, nor clarify that it does not mutate either diagram.

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?

Short and front-loaded: the purpose sentence comes first, followed by a compact Args/Returns block with no filler. Slightly formulaic but nothing wasted.

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?

An output schema exists, so the terse 'Returns: dict with equivalence status' is acceptable. For a two-parameter tool the core is covered, but the absence of any usage or behavioral context leaves gaps relative to the richer sibling set it sits in.

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, yet 'First diagram ID' and 'Second diagram ID' merely restate the schema titles. It adds no format, source, or constraint information (e.g., where IDs come from, whether they must be loaded first via diagram_load).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Check if two diagrams are structurally equivalent') and adds the parenthetical '(isomorphic)' to disambiguate what 'equivalent' means. It does not, however, distinguish itself from the sibling explore_equivalent_states, leaving the agent to infer the boundary.

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?

There is no when-to-use guidance, no prerequisites, and no mention of the obvious alternative explore_equivalent_states. The agent must guess whether this is a pairwise comparison tool or a broader exploration 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?

No annotations are provided, so the description carries the full burden. 'Compute' implies a read-only, side-effect-free operation, and the metric list clarifies the computation's scope, but it says nothing about permissions, cost, or whether results are cached/persisted. Adequate but incomplete.

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?

Uses a clean Args/Returns layout, front-loading the one-line purpose before the parameter detail. The metric bullet list is long but every line adds necessary meaning that the schema lacks.

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, the terse 'dict with computed metrics' return note is acceptable. The description supplies the metric enumerations the schema omits, covering the main ambiguity; only the diagram_id semantics and any usage framing remain light.

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, and it does well: it enumerates and explains all six metric options that the schema leaves as bare strings. diagram_id gets only 'ID of diagram', which is thin, but the metric documentation is the critical gap and it is filled.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (compute) and resource (structural metrics on a diagram), and adds that these are graph-theoretic properties for understanding complexity. This clearly differentiates it from navigation, search, or equivalence siblings, though no sibling is named explicitly.

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 phrase 'useful for understanding complexity' hints at why one might call it, but there is no explicit when-to-use, when-not-to-use, or alternative routing (e.g., vs analyze_reachability or pattern_match). An agent must infer the context.

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 full burden. It discloses the DAG constraint and the return shape (diagram_id, num_nodes, num_edges, validity), which hints that a validity check occurs, but it never says what happens on invalid input, whether cycle creation fails, or whether anything persists. Partial behavioral disclosure only.

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?

Front-loaded one-line purpose followed by well-organized Args/Returns blocks. It is long, but given the 0% schema coverage every line about node/edge fields earns its place. The Returns block is slightly redundant since an output schema exists, keeping it from a 5.

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?

An output schema exists so return values need not be spelled out, and the parameter documentation is thorough enough to call the tool correctly. The gaps are behavioral: validation failure modes, persistence, and sibling routing are absent, which matters for a mutation-style create tool with no annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the schema is only an untyped array of objects, so the description is the sole source of parameter meaning. It fully enumerates node fields (id, label, type with enum-like values, optional metadata/embedding) and edge fields (source, target, label, optional weight with default 1.0, properties). This is exactly the compensation a 0%-coverage schema requires.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Create') and resource ('a new diagram') and further defines what a diagram is (a DAG, the primary unit of reasoning). It is clear enough to distinguish from siblings like diagram_load, diagram_save, and diagram_delete, though it never names an alternative explicitly.

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 what the tool does but never states when to use it versus siblings such as diagram_load or diagram_extract, nor any prerequisites (e.g. whether diagrams must be saved separately). The agent must infer usage entirely.

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

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

With no annotations, the description carries the behavioral burden. It usefully discloses that deletion affects both active memory and persisted storage and mentions a success return, but does not state irreversibility, required permissions, error behavior, or 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?

Front-loads the purpose, then cleanly separates Args and Returns. No unnecessary text; every sentence is short and informative for the operation described.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter delete tool, the description covers purpose, parameter, and return. However, with no annotations and no output schema details needed, it should still warn about irreversibility or prerequisites. Missing usage guidance leaves an important gap for a destructive operation.

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 should add meaning. It restates the single parameter as 'ID of diagram to delete' without format, constraints, or validation details. Minimal but adequate given the parameter is self-explanatory.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Delete') and resource ('diagram') with additional scope ('from both active memory and persisted storage'). This clearly distinguishes it from create/load/save/list siblings, though it does not explicitly name alternatives.

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 no when-to-use guidance, prerequisites, or alternatives. The deletion action is implied by the verb, but the description offers no explicit context for selecting this tool over related diagram operations.

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 full behavioral burden. It reveals that a new composite node and new diagram ID are produced, but does not state whether the source diagram is modified, whether the operation is reversible, permission requirements, or any side effects for a mutation-style 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?

Front-loaded with the core action, followed by compact Args and Returns sections. Efficiently sized with no filler, though the Args/Returns boilerplate is generic docstring formatting rather than tailored guidance.

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?

An output schema exists, so the plain-text Returns restatement is redundant. For a structural mutation tool with zero annotation coverage, the description omits the key question of whether the source diagram is altered, leaving the agent without a complete behavioral picture.

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, and it does give meaning for all three parameters ('source diagram ID', 'nodes to extract', 'label for the new composite node'). The semantics are correct but terse, adding no format details (e.g., node ID conventions, label 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?

States a specific verb (extract) and the transformation (subgraph into a composite node), so the operation is unambiguous. However, it does not differentiate the tool from siblings like apply_rewrite_rule or diagram_create, which also mutate diagram structure.

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 what the tool does but gives no when-to-use guidance, no prerequisites, and no alternatives (e.g., when to extract vs. apply a rewrite rule). The Args/Returns docstring structure implies developer documentation rather than agent routing 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 carries the full behavioral burden, and it does disclose two useful facts: the operation only returns IDs (not full diagrams) and the IDs come from on-disk persistence. However, it says nothing about permissions, whether the read is side-effect free, or how the listing behaves with unsaved in-memory diagrams.

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 short sentences, front-loaded with the action and scope. The Returns block partly duplicates the output schema, which is mildly redundant but not wasteful enough to hurt readability.

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 zero-parameter listing tool with an output schema present, the description covers purpose, scope (IDs only, on disk), and return shape. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. The empty schema is fully consistent with the description's claim of a parameterless listing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (List) and resource (diagram IDs persisted on disk), making the tool's purpose immediately clear. It is distinguishable from siblings like diagram_load (full content) and diagram_save in practice, though it never explicitly names or contrasts with them, so differentiation is only implicit.

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?

There is no explicit guidance on when to use this tool versus diagram_load, diagram_extract, or check_diagram_equivalence. The intended usage (enumerating what is available before loading) can be inferred but is never stated, and no exclusions or prerequisites are provided.

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 full burden, yet it discloses almost nothing beyond 'load and return'. It does not state permissions required, whether the operation is read-only, or how failures are surfaced beyond a vague 'or error'.

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?

Very short and front-loaded with the core action. The Args/Returns docstring boilerplate is somewhat redundant given a schema and output schema exist, but it costs little.

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 single-parameter read tool with an output schema already defining return values, the description is nearly adequate. The redundant Returns line and missing usage/permission context are the main 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?

Schema coverage is 0% and the single parameter is only restated as 'ID of diagram to load', adding no format, source, or constraint information. The description does not compensate for the undocumented parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (load) and resource (diagram structure), so the agent knows it fetches a full diagram. However, it offers no differentiation from siblings like diagram_extract, diagram_list_saved, or explore_equivalent_states, which also deal with diagram content.

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?

There is no guidance on when to use this tool versus alternatives such as diagram_extract or diagram_list_saved, and no prerequisites or context are given. The agent must infer usage purely from the name.

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 states that it forces a sync to disk, implying a write operation, but does not disclose whether it overwrites existing files, requires permissions, or what happens on failure.

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?

Front-loaded with the action, and the Args/Returns structure is compact. However, the Returns line duplicates information already available in the output schema, slightly reducing efficiency.

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 write tool with no annotations, the description is incomplete. It lacks prerequisites, side effects, and usage context, leaving the agent under-informed for safe 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?

Schema coverage is 0% and the only parameter description is 'ID of diagram to save', which adds little beyond the parameter name. No format, source, or lookup guidance is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: syncing a specific diagram to disk, with the qualifier 'force an immediate' that implies urgency. This distinguishes it from load/create/delete siblings, though it does not name them explicitly.

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 on when to use this tool versus alternatives such as diagram_create or diagram_load. The agent must infer that it is for persisting an existing diagram, but no conditions or prerequisites are 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?

With no annotations, the description carries full behavioral burden. It discloses the BFS algorithm, the meta-graph output, and discovery limits via max_depth/max_states, which is useful context, but it does not state whether exploration mutates the server state, persist results, or whether it is potentially expensive/exponential for large depths.

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?

Front-loaded purpose sentence followed by a compact Args/Returns block; every line carries information. The Returns line is slightly redundant given an output schema exists, but it is not wasteful.

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 4-parameter tool with no annotations, the description covers purpose, algorithm, and all params, and an output schema exists so return values need not be detailed. However it omits when-to-use guidance and any warning about the cost/limits of BFS exploration, which are relevant for a tool that could blow up combinatorially.

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, and it does: it explains all four parameters, including that rules are 'serialized RewriteRule dicts' and that max_depth is BFS depth and max_states caps unique states. Only formatting/syntax details of the rule dicts are left unspecified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: 'Explore alternative diagram states reachable via rewrite rules,' and adds that it constructs a meta-graph of structurally unique configurations. This clearly separates it from apply_rewrite_rule (single application) and check_diagram_equivalence, though it never names those siblings explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied by the mechanism (BFS over rewrite rules from a starting diagram). There is no explicit when-to-use statement, no condition that selects this over explore_reasoning_space or analyze_reachability, and no 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?

No annotations are provided, so the description carries the full burden. It usefully discloses the exploration policy (curiosity-biased toward low exploration_count nodes) and that the result includes 'updated exploration_counts', hinting at state mutation, but it never states whether those counts are persisted, whether the walk is read-only, or any permission/rate considerations.

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?

Front-loaded with the core behavior in the first line, then a clean Args/Returns structure. The args list is slightly redundant ('ID of diagram', 'Starting node ID' for self-evident fields), but overall the wording is efficient with little waste.

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?

An output schema exists, so the Returns block is a bonus rather than a requirement. However, with no annotations at all on a tool that mutates exploration state, the description omits the safety/statefulness context an agent would need to call it 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?

Schema description coverage is 0%, so the description is the only source of parameter meaning, and it does compensate well: it explains each of the four args, restates defaults for steps (5), and gives real semantics for temperature ('0.0 = greedy unvisited, 1.0 = highly random'). Only 'steps' is left as a near-tautology.

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 gives a specific verb and resource — a random walk over the diagram driven by a 'curiosity metric' using NavigationMemory — and names the mechanism (prioritizing low exploration_count nodes). It is clear what the tool does, but it never distinguishes itself from the navigation siblings navigate_breadth_first, navigate_guided, or explore_equivalent_states.

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?

There is no explicit when-to-use, when-not-to-use, or alternative-selection guidance. With three sibling navigation tools (breadth-first, guided, equivalent-state exploration) available, the agent is left to infer which one applies; the description only implies an exploratory use case.

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

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

With no annotations, the description carries the full burden. 'Export' implies a read-only operation and the Returns line indicates proof steps plus metadata, which is useful, but there is no disclosure of permissions, whether the proof generation is expensive, or failure modes.

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?

Front-loaded purpose sentence followed by compact Args/Returns blocks. Every line earns its place, though the Args/Returns formatting is slightly formulaic given an output schema already exists.

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?

An output schema exists, so return-value explanation is largely redundant but harmless. The description covers both parameters and the operation's scope; only the missing usage/routing guidance keeps it from being 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?

Schema description coverage is 0%, so the description must compensate, and it does: it explains diagram_id and, more importantly, enumerates the output_format values ('text' natural language vs 'json' structured) that the schema leaves as a bare string with only a default.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (export) and resource (a diagram's transformation history) plus the output form (structured proof). It clearly distinguishes itself from siblings like diagram_extract or compute_metrics, though it never explicitly names an alternative to route against.

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 on when to use this versus diagram_extract, explore_reasoning_space, or pattern_match. No prerequisites or exclusions are stated; an agent must infer the context from the verb alone.

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 traversal algorithm and output fields (explored_nodes, edges_traversed, total_explored), which imply a read-only exploration, but does not explicitly state side effects, permissions, or that the diagram is not modified.

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 front-loaded with the purpose and then uses structured Args/Returns sections. It is appropriately sized, though the Returns section is redundant given an output schema exists.

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 four parameters, no annotations, and zero schema description coverage. The description covers three parameters and basic behavior but misses expand_composites and sibling differentiation, leaving minor gaps for correct 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?

Schema description coverage is 0%, so the description must compensate. It explains diagram_id, start_node, and max_depth (including default), but omits the fourth parameter, expand_composites, leaving one parameter undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Explore') and resource ('diagram structure') and names the traversal method ('breadth-first'). It differentiates from 'navigate_guided' by algorithm, though it does not explicitly name or contrast with that sibling.

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 an implied use case: systematically visiting nodes level by level is 'useful for understanding structure.' It does not state when to choose this over alternatives like 'navigate_guided' or any exclusions.

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

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

With no annotations, the description carries the full burden. It does disclose the algorithm (shortest-path), the heuristic mode, and a return shape with a 'found' flag, which is genuinely useful. However, it says nothing about permissions, read-only nature, failure modes, or the cost of 'semantic_similarity' (likely expensive), leaving gaps for an unannotated 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?

Front-loaded with the core action, then a clean Args/Returns structure. Every line carries information, though the Returns block partially duplicates the existing output schema.

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?

An output schema exists, so return-value explanation is not strictly required, yet the description is otherwise complete enough to invoke the tool: required params, heuristic values, and defaults are covered. The only real gap is the undocumented expand_composites parameter and the absent sibling differentiation.

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, and it does well: it documents diagram_id, start_node, goal_node, and enumerates heuristic values ('distance', 'reward', 'semantic_similarity') with a stated default that the schema does not express as an enum. It omits expand_composites entirely, so it is not fully compensating for 5 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?

States a specific verb and resource ('Find guided path from start to goal node') and names the underlying approach (shortest-path algorithm). It is clear on its own, but it never distinguishes itself from the sibling navigate_breadth_first or explains what 'guided' adds over a plain 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 lists heuristic choices, which implies a use case, but gives no explicit when-to-use or when-not-to-use guidance and never mentions the obvious alternative navigate_breadth_first or analyze_reachability. The agent is left to infer selection from the name alone.

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

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

With no annotations, the description carries the full behavioral burden, yet it only restates the operation and return shape. It does not disclose read-only semantics, permission requirements, cost/latency, behavior on missing diagrams, or how ties/empty results are handled. "Search" weakly implies a read, but nothing is stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The leading sentence is front-loaded with the core purpose, and the Args/Returns structure is easy to scan. The format is slightly boilerplate-heavy, but no sentence is wasted.

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?

An output schema exists, so the Returns section is largely redundant. Parameter meaning is covered, but the description omits usage context and any behavioral caveats, leaving it only adequately complete for a four-parameter retrieval tool with zero schema documentation.

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 — and it does, documenting all four parameters including the semantic meaning of `threshold` ("minimum cosine similarity score to include") and `top_k` ("maximum number of results"). The defaults it cites are already in the schema, but the added meaning is real.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ("Search for nodes") plus the scope qualifier ("semantically similar to a target embedding"), which is enough to distinguish it from lexical/pattern siblings like pattern_match. It does not explicitly name or differentiate against any sibling, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied by the operation itself — an agent can infer it is for embedding-based retrieval, but there is no when-to-use, when-not-to-use, prerequisites, or named alternative among the many navigation/search siblings. This is minimum-viable implied context, not 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 carries the full burden. It discloses the core mechanism (subgraph matching) and the return shape, but says nothing about whether this is a read-only operation, its cost/performance characteristics, or any 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?

Front-loads the purpose in the first sentence, then details mechanism, args, and returns in a compact docstring. No redundant or filler 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?

An output schema exists so return values need not be spelled out, yet the description still summarizes them. Combined with the parameter breakdown for a nested-object tool, it is reasonably complete, with the only gap being deeper constraints_dict 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, and it does: it explains diagram_id and breaks down the pattern spec into 'nodes' (dict) and 'edges' (list) with each edge tuple shaped as (source_id, target_id, constraints_dict). This meaningfully exceeds the bare schema, though the constraints_dict contents remain undefined.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Find all pattern matches within a diagram') and reinforces the mechanism ('subgraph matching to locate structural patterns'). It is clearly distinguishable from siblings like check_diagram_equivalence or analyze_reachability, but it never explicitly names an alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the tool does but gives no guidance on when to choose it over siblings such as check_diagram_equivalence or explore_reasoning_space. No prerequisites or when-not-to-use conditions are stated.

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

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

With no annotations provided, the description must carry the behavioral burden. 'Return ... status information' clearly implies a non-mutating read, and the listed return fields add useful shape, but there is no disclosure of permissions, cost, or side-effect profile beyond that implication.

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 short blocks, purpose front-loaded, nothing padded. The 'Returns' list is slightly redundant given an output schema exists, but it is brief and does not bloat the definition.

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 zero-parameter introspection tool with an output schema, the description covers what the tool is and roughly what comes back. Since the output schema already defines return values, the enumerated fields are a mild duplication rather than a gap; nothing essential to invoking the tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the 4 baseline applies. The description correctly does not invent parameter semantics that do not exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Return server capabilities and status information.' It is unambiguous, though it does not differentiate itself from any sibling — which is acceptable here since no sibling tool (diagram CRUD, navigation, metrics) overlaps with server introspection.

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 explicit when-to-use or when-not-to-use guidance is given. Usage is strongly implied by the name and the resource being described (inspect the server before/without operating on diagrams), but the description leaves that inference to the agent.

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