Volley

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

Annotations declare non-readOnly, idempotent, non-destructive, closed-world, and the description meaningfully enriches them by spelling out the upsert semantics: re-adding an existing diagram replaces the passed fields while it 'keeps its place'. That explains the idempotentHint and clarifies that nothing is destroyed or reordered, which the annotations alone don't convey.

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, zero filler. The primary action is front-loaded and the second sentence handles the duplicate/upsert edge case rather than padding the first.

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-param mutation with no output schema, the description covers the essential behavior including the re-add edge case. Minor gaps remain — existence requirements for collectionId/diagramId and any failure behavior — but annotations already carry the safety profile, so this is close to 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 50% (note and scenario are documented; diagramId and collectionId are bare strings). The description restates scenario/note intent and adds useful update semantics ('the fields you pass replace its old ones'), but it does not compensate for the undocumented identifiers or explain their format.

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: appends one saved diagram to the end of a collection, with a scenario name and note. The scope ('one saved diagram', 'end of a collection') is precise enough to separate it from siblings like save_diagram and save_collection, though it never names 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?

Usage is implied by 'add one saved diagram to the end of a collection' — an agent can infer this is the tool for populating a collection. However, there is no guidance on when to prefer this over save_diagram or save_collection, no stated prerequisites (must the diagram/collection already exist?), 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?

Annotations only declare readOnlyHint/openWorldHint, and no output schema exists, so the description's disclosure of the return shape (errors with line and column, or 'ok' with lane, message and payload count) is genuinely load-bearing context. It stops short of auth or rate-limit notes, but the return-behavior disclosure is real added value.

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 first two sentences are well front-loaded and earn their place. The remaining two-thirds is a syntax catalog for Volley source that helps author parameters but is bulky and likely duplicated across sibling tools, diluting selection-relevant 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?

For a read-only, two-parameter tool with no output schema, the description covers what is returned in both the error and success cases, which is the main gap structured data would otherwise leave. Only the missing sibling differentiation 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 coverage is 100%, so both id and source are already documented in the schema, and the description does not add id-vs-source selection rules. The syntax reference implicitly describes valid 'source' content but is not tied to the parameter, so the 3 baseline is appropriate.

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 sentence gives a specific verb and resource: 'List parse errors and warnings for a Volley diagram, each with line and column.' It also states the negative case ('Returns ok ... when there are none'). However, it never distinguishes itself from the similarly-named verify_diagram sibling, so an agent may not know which validation tool to pick.

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 and no alternative named, even though verify_diagram and describe_diagram are obvious candidates for confusion. The description only implies usage by listing what it returns, leaving the selection decision 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: it spells out the shape of the returned Markdown (lanes, ordered messages, notes, sections, full request/response payloads), which matters because there is no output schema.

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 tight sentences: the first front-loads what the tool does and what it returns, the second covers inputs. The enumeration of output fields is long but earns its place since no output schema exists to carry that 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?

For a read-only, two-parameter tool with no output schema, the description covers purpose, output shape, and input modes adequately. The only meaningful gap is routing guidance relative to the many sibling tools that also operate on diagrams.

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 100%, and the schema already explains that id is 'used instead of source'. The description restates the same source-or-id alternatives without adding syntax, format, or mutual-exclusivity detail, so the baseline of 3 is appropriate.

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 ('Read ... as Markdown') and resource ('a Volley diagram'), then enumerates exactly what the output contains (lanes, ordered messages with numbers, notes, sections, payloads). This clearly separates it from an SVG producer like render_svg, but it never names check_diagram, verify_diagram, or get_diagram, so sibling differentiation is left 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?

It states the two input modes ('Pass source text or the id of a saved diagram'), which implies when the tool is usable, but it gives no guidance on when to prefer this over verify_diagram, check_diagram, or render_svg, nor any exclusions or prerequisites.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral value beyond that: it describes the shape of the returned entries and what full:true changes (every diagram's messages and payloads in one Markdown document). It omits any note on pagination, size limits or error behavior for a bad id.

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 tightly packed sentences: the first front-loads what is returned, the second covers the routing to describe_diagram and the full mode. Every clause earns its place with no filler.

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 no output schema, the description carries the burden of explaining the return value and does so thoroughly, including the alternate full-mode output format. For a two-parameter read-only tool this is complete enough for an agent to invoke it 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?

Schema description coverage is 100%, so the baseline is 3, but the description goes further by explaining that full:true returns messages and payloads as a single Markdown document and why (as context before writing integration code) — meaning the schema's terse 'Include every diagram's messages and payloads' does not fully capture.

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 (Read) and a precisely scoped resource (one of your collections, by id), then enumerates exactly what comes back: description and every entry in order with scenario name, diagram id, title and usage note. This clearly distinguishes it from list_collections and get_diagram without the agent needing to open a schema.

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 the use case ('use it to pick the right pattern for a scenario') and routes the agent to the next tool ('then describe_diagram with that id for the details'), plus the full:true workflow before writing integration code. It gives clear when-to-use context but no explicit when-not or negative conditions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the read-only, local nature of the call is covered. The description adds useful context by naming the payload (title, visibility, short link, full source), but says nothing about authorization, error behavior for a bad id, or size/limits of the source.

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

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

One sentence, front-loaded with the action and resource, with the return payload enumerated efficiently and no 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?

For a simple one-parameter read tool with no output schema, the description compensates by listing the returned fields, which is the key missing structured information. Minor gap: no indication of failure mode for an unknown id.

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?

There is a single parameter with 100% schema description coverage, so the schema already documents the id. The description only restates that lookup is by id, adding no syntax, format, or sourcing detail beyond the schema. Baseline 3 applies.

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 ("Fetch ... saved diagrams by id") and enumerates the returned fields, so the agent knows it retrieves the full stored diagram. It does not explicitly contrast with siblings like describe_diagram or check_diagram, leaving that differentiation to inference.

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 "by id" implies the tool is for looking up a known diagram id, but there is no explicit when-to-use guidance and no mention of the sibling tools (describe_diagram, check_diagram, render_svg) that an agent might confuse it with.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: results are ordered newest first and each item is a collection containing scenario names and notes. It omits any pagination or result-count limits, which is the only notable gap.

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 core action and ordering are front-loaded in the first sentence, and the query behavior is last. The middle sentence explaining what a collection is runs long with the "recipe book" analogy, which is illustrative but not strictly load-bearing.

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 read-only, single-optional-param tool with no output schema, the description covers ordering, item structure, and filter semantics, which is nearly everything an agent needs. Only pagination/limit behavior is unaddressed.

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

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

Schema coverage is 100% and the schema already says "Words to look for", so baseline would be 3. The description goes beyond it by specifying which fields are searched (title, description, scenario names, diagram titles) and the AND semantics ("contain every word"), which genuinely changes how an agent should phrase a query.

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

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

States a specific verb and resource ("List your Volley collections") plus ordering ("newest first"), and defines the domain object "collection" concretely as an ordered playbook of scenarios. It is clearly distinct from get_collection, but it never explicitly names that sibling to route between them.

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

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

Usage is implied (list all, optionally filtered) and the query parameter's behavior is described, but there is no explicit when-to-use/when-not guidance and no mention of get_collection or list_diagrams as alternatives. Adequate but leaves routing 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description still adds real behavior: newest-first ordering, AND semantics for multi-word queries, and cursor-based pagination. It omits auth/permission requirements and any rate-limit or empty-result behavior.

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

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

Three sentences, each earning its place: what it returns, how to filter, how to paginate. Front-loaded with the core action and no redundant restatement of the title.

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

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

No output schema exists, so the description correctly enumerates returned fields and explains pagination and ordering. Together with the schema's bounds on limit, an agent has everything needed to call and page through this 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 coverage is 67% (query and cursor documented; limit only bounded by default/min/max). The description adds meaning beyond the schema by clarifying that query matches titles containing every word (AND, not OR) and that cursor is the value returned by the previous page.

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 ('List the diagrams saved to your Volley account'), plus the sort order (newest first) and the fields returned (id, title, visibility, short link). This clearly separates it from sibling list_collections (different resource) and from single-item tools like get_diagram.

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?

Gives concrete usage guidance for two of three parameters: 'Pass query to find diagrams whose title contains every word' and 'pass the returned cursor to get the next one.' It does not say when to prefer this over check_diagram/get_diagram or state exclusions, so it falls short of the explicit when/when-not bar.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safe/read-only and closed-world nature is covered. The description adds that it returns SVG markup, which is useful, but it says nothing about error handling for invalid source/id or any output-size limits. Adds some value beyond annotations, but not rich 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?

Two tight sentences with zero filler. The primary action and output are front-loaded, and the input-mode note follows immediately.

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 read-only render tool with no output schema, the description tells the agent what it returns (SVG markup) and how to supply input. The only missing piece is error/edge-case behavior, which is minor here.

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 75%, so most parameters are already documented in the schema. The description adds the semantically important point that 'source' and 'id' are alternative inputs, but it does not mention theme or showPayloads. Baseline 3 is appropriate given the schema does most of the work.

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 (render), resource (a Volley diagram), and output format (standalone SVG image), which is more than the title alone conveys. It does not, however, differentiate itself from siblings like check_diagram, describe_diagram, or get_diagram that also deal with diagrams.

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 states that you can 'Pass source text or the id of a saved diagram,' which implies the two input modes, but there is no explicit guidance on when to render versus using check_diagram, describe_diagram, or verify_diagram. Usage is implied rather than contrasted with 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?

Annotations already flag destructiveHint=true and idempotentHint=true; the description explains why destruction occurs ('entries replaces the whole ordered list') rather than restating the hint. It also discloses a gating requirement the annotations cannot carry: 'Collections are part of Volley Pro.' It does not say whether updating a collection also overwrites the untouched title/visibility fields.

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 compact sentences, front-loaded with the create/update decision, then entry semantics, then the entitlement note. Every clause carries information an agent needs and nothing is padded.

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 mutation tool with annotations present and no output schema, the description covers upsert behavior, destructive replacement semantics, entry shape, and the Pro entitlement. The remaining gap is partial-update behavior for non-entries fields, which the agent cannot infer from either the description or the 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?

Coverage is only 40%, so the description must compensate, and it does for the most complex parameter: entries is explained as an ordered list where each item is a diagram id plus a scannable scenario name plus a Markdown note, and id is tied to update-vs-create. It adds the critical 'replaces the whole ordered list' semantics the schema omits, though visibility and title remain unexplained.

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 with precise upsert semantics: 'Create a collection, or with id update one.' This distinguishes it from get_collection and list_collections, and the wholesale-replacement clause implicitly separates it from add_to_collection. It stops short of naming that closest sibling outright.

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 says when to create vs update via the id, and 'entries replaces the whole ordered list' implies append-style tools are the alternative. But add_to_collection is never named, so the agent must infer the choice between adding one entry and rewriting the list.

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?

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the bar is lower, yet the description still adds valuable behavior: replacing source keeps a prior version only on Pro, and 'private' visibility is plan-gated. That is genuine auth/plan and data-retention context an agent cannot get from the annotations. The 'replaces that diagram's source' wording sits in mild tension with destructiveHint=false, but since the diagram itself persists and versioning is offered, it is a nuance rather than a 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?

The first three sentences are well front-loaded, but the bulk is a single unbroken paragraph cramming the entire DSL reference, with no line breaks or grouping. The grammar content is useful for authoring a valid source, yet its density and lack of structure make it hard to scan and it crowds out tool-level 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?

With no output schema, the description correctly states what comes back (short link, README embed). It covers create/update modes, visibility semantics, and source syntax, which is what an agent needs to invoke it. It omits account/auth prerequisites for saving and any suggested pre-save validation step.

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 67%, and the description meaningfully extends all three parameters: id (create vs replace plus versioning), visibility ('unlisted' = link-visible, 'private' = Pro only), and source (an extensive DSL grammar covering messages, payload attachment, and directives). It adds substantially more than the schema's terse field descriptions.

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?

Opens with a specific verb+resource and outcome: 'Save a diagram to your Volley account and get a short link and README embed.' It clearly separates create (no id) from update (with id) behavior, which distinguishes it from sibling save_collection by resource. It never explicitly names a sibling to contrast against, so it stops 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?

It gives real usage context for the id parameter (create vs replace) and a plan constraint ('private' is Pro only), which is more than nothing. But it never states when to prefer this tool over siblings like verify_diagram or check_diagram, nor any when-not conditions or prerequisites (e.g. validating source before saving).

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral detail beyond that: what matching means, and the four categories of result (matched, drifted, documented-but-absent, recorded-but-undocumented). It omits auth needs, limits, or how results are structured, but adds real substance.

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, front-loaded with the 'Drift check:' framing so the agent gets the gist immediately. The enumeration of result categories is long but informative; nothing is wasted, though it could be tightened slightly.

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

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

No output schema exists, so the description carries the burden of explaining return values — and it does, enumerating the four report categories. The matching algorithm is also disclosed, which is important for interpreting results. Only the concrete result format/pagination is left unspecified.

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

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

Schema coverage is 100%, so all three parameters are already documented in the schema. The description reinforces the source/id alternative and the HAR-as-JSON-string usage, but adds little that the schema does not already state, so the baseline 3 applies.

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 ('compare a Volley diagram with a HAR recording of real HTTP traffic') and frames it as a drift check. The matching semantics (by method and path) further sharpen what the tool actually does, clearly separating it from siblings like check_diagram or describe_diagram.

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 clear context for when this tool applies — verifying a diagram against recorded traffic — and even sketches the matching rule. It never names an alternative sibling (e.g. check_diagram) or states when not to use it, so it stops short of explicit routing guidance.

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