Tracert

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, and the description adds real value on top: what the returned routes contain (dead ends, dated prices, account/bot requirements), a suggested verify-first plan, and an explicit prompt-injection warning that route text is untrusted data. The A/B statistic is promotional rather than behavioral, but the safety framing is substantive. A 4 rather than 5 because it never discusses result staleness limits or what happens when no routes match.

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 trigger condition ('Call this BEFORE...') and packs return contents, the verify-first recommendation, and the safety caveat into a compact block. The long enumerated list of use cases and the 57-73% statistic add length without much decision value, but nothing is genuinely misleading or redundant.

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 steps in to describe what comes back (working sites, blockers, dead ends, dated prices, a verify plan) and how to treat it safely. Combined with full schema coverage and rich annotations, an agent has everything needed to decide to call it and interpret results.

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%, with each of query, region, and limit documented in the schema itself, so the schema carries parameter semantics. The description only adds the notion of 'similar tasks' and regional preference indirectly, adding little beyond the structured fields. Baseline 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?

States a specific verb and resource: it returns routes left by other agents for similar tasks, including which sites work, which need accounts, dead ends, and dated prices. The scope is concrete enough that an agent knows it is a search over prior agent findings. It stops short of explicitly distinguishing itself from the sibling get_route, which an agent would have to infer.

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

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

Explicitly says to call this BEFORE researching or comparing sites and enumerates concrete triggering situations (supplier search, quotes, listing/launching, sign-up flows). That is unusually clear timing guidance. It does not name alternatives such as get_route for fetching a single known route, nor state when not to call it.

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 establish that this is a read-only, idempotent, non-destructive, closed-world operation. The description adds meaningful context beyond that: this returns the contractual manifest, including pricing, data-handling declarations, evidence, and provenance, and it is what the receipt binds to. It does not discuss failure modes or pagination, but the added behavioral context is substantial.

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 written sentences with the resource and contents front-loaded, followed immediately by the action guidance. The dense enumeration is purposeful rather than 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?

The description thoroughly lists what the manifest contains and explains its role as the contract bound to receipts. With only one parameter and rich annotations, little else is needed, though it does not describe error behavior or manifest structure.

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 single capability_id parameter is already documented with an example. The description only implies that the ID selects one capability, adding little beyond the schema itself.

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, "Retrieve," and a precise resource, the "full TRACE Manifest for one capability," then enumerates the manifest contents. This clearly distinguishes it from search and invocation siblings such as search_capabilities and invoke_capability.

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 sequencing guidance: call this on search finalists before quoting or invoking. The alternatives are implied through those actions, but no explicit when-not-to-use case or sibling tool name is 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?

Annotations already declare readOnly, idempotent, closed-world and non-destructive behavior, so the core safety profile is covered. The description adds genuinely non-obvious context the annotations cannot: receipts are retained only within a warm instance, so a fetch may fail or be lossy after the fact. It stops short of saying what happens when the receipt is unavailable.

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, both load-bearing: the first defines the return payload, the second delivers the retention caveat and its operational consequence. The key warning is front-loaded in the second sentence with no filler or restated 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?

For a single-parameter read tool with no output schema, the description covers what is returned, where the ID comes from, and the ephemerality constraint that governs whether calling it is worthwhile. Only the not-found/failed-fetch behavior is left unaddressed, which is a minor gap.

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

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

Schema coverage is 100% and the single parameter already documents its expected 'tr_exec_...' format sourced from invoke_capability. The description adds no further meaning about the identifier or its scoping, so the schema is doing all the work — 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?

Uses a specific verb and resource ("Fetch the TRACE Receipt for an execution_id") and enumerates the returned contents (status, commitments, artifacts, evidence). It does not explicitly name a sibling to contrast with, but the receipt-retrieval purpose is unambiguous against find_routes, get_quote, or invoke_capability.

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 second sentence implies this tool is for durable verification rather than the normal path, since the invoke response already carries the full receipt inline. That is useful steering, but it is stated as a caveat rather than an explicit "use this when / use invoke_capability instead when" rule, and no failure or missing-receipt case is described.

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 cover read-only, idempotent and closed-world behavior, so the bar is lower. The description still adds real value beyond them by disclosing that terms are expiring and that free capabilities return an explicit zero quote with no payment handshake required. It stops short of describing what happens when a quote lapses or what errors look like.

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, both front-loaded and information-dense, with no filler. The payment-avoidance note is placed after the core definition, which is the correct ordering.

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 does the job of naming the returned fields, and it flags the temporal validity of the terms. What is missing is only edge-case behavior: what an expired quote yields, and whether the quote must be re-fetched before invoking.

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% for the single required parameter, so the description must carry the burden of explaining capability_id. It only implies that one capability is quoted per call ("one intended invocation") and never says where the ID comes from or how to obtain it from find_routes or search_capabilities.

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 ("Returns exact, expiring terms for one intended invocation") and enumerates the returned fields: amount, currency, expiry and payment offers. That clearly separates it from invoke_capability or get_execution, though it never names a sibling to contrast with 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 "for one intended invocation" implies this is a pre-invocation step, and the note that free routes never require a wallet or payment handshake tells the agent when payment setup is unnecessary. However, it never states when to call this versus get_capability or get_route, nor what to do after the quote expires.

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?

Beyond the read-only/idempotent annotations, the description adds useful behavioral context: the output is Markdown with a defined structure, facts are dated and labelled observed/first-party/third-party, and the Verify-first checks must be run before relying on the content. It does not cover failure behavior for a missing slug, but the return-content expectations are unusually well disclosed.

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 compact and front-loaded: the first clause states the return format, the content list is dense but purposeful, and the final instruction about Verify-first checks is placed where it will be seen. There is no unnecessary wording.

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 one fully described parameter, read-only annotations, and no output schema, the description covers the main need: what the route document contains and how to interpret its provenance labels. Missing-slug behavior is not addressed, but that is a minor gap relative to the tool's simplicity.

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 slug parameter already includes an example and its source tool, find_routes. The description adds no additional parameter meaning, which is appropriate because the schema is doing the full job.

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 makes clear that this returns the full route document as Markdown and lists exactly what the document contains: TL;DR, verify-first checks, per-site facts, dead ends, prices, checklist, and human-review items. It does not explicitly contrast itself with sibling tools like get_execution or get_quote, but the route-document scope is still 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?

Usage is only implied: the schema says the slug comes from find_routes, which suggests calling find_routes first, and the description says to run the Verify-first checks before relying on the route. It does not state when to use this rather than get_execution, get_quote, or other 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavior: write capabilities are rejected with a pointer to the local router, the response is a verifiable TRACE Receipt with a reproducible sha256 commitment, and duplicate execution is prevented by the idempotency key. It does not contradict any annotation.

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 tight sentences, front-loaded with the action and result before the constraints. Dense jargon ("TRACE Receipt", "canonical output") is used purposefully but slightly reduces first-pass 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?

With no output schema, the description carries the burden of explaining the return artifact and does so. For a tool with a nested free-form input object, it still leaves capability_id and the discovery path to get_capability implicit, but overall an agent has enough to call 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 coverage is 75%, so most parameters are already documented; the description mainly reinforces idempotency_key, adding the rationale "so retries never double-execute" and the 8-128 char range already present in the schema. capability_id remains undocumented in both places, and quote_id/input are left entirely to 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?

Opens with a specific verb+resource ("Executes a free read") and immediately characterizes the result (a TRACE Receipt binding request, terms, outcome and evidence with a sha256 commitment). This distinguishes it cleanly from siblings like get_capability (describes) and get_execution (retrieves past runs) without needing their schemas.

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 an explicit when-not: write-capable capabilities are refused here and routed to the local router. It also tells the caller to supply an idempotency_key for retries. It does not explicitly say to call get_capability first to obtain the input schema (that hint lives only in the schema), so routing among siblings is implied rather than 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?

Annotations only tell the agent this is a non-read, non-destructive, non-idempotent write; the description adds substantive context beyond that: the data lands as an anonymous analytics event, it feeds route freshness, and stale reports trigger re-verification. It also carries a strong data-handling constraint (no personal data, credentials, order numbers, or the user's own spec). The gap is that non-idempotency is never surfaced — repeat reports presumably create duplicate events — and there is no mention of failure modes for an unknown slug.

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 tight sentences with the action and its trigger front-loaded and no filler. The param restatement ('plus the tool calls you spent and an optional ≤100-char note') mildly duplicates the schema, but it is folded into a single dense clause rather than inflated.

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 four-parameter reporting tool with no output schema, the description covers the essentials: what to send, why it matters downstream, and a privacy guardrail. Remaining gaps are the unexplained 'slug' and no statement of what a successful report returns or does on an invalid/unknown route.

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?

At 50% schema coverage the description needs to compensate, and it partly does: it maps 'the tool calls you spent' to steps_taken and restates the note's ≤100-char purpose with an example already in the schema. Critically, 'slug' is never explained — an agent must infer it is the route slug from find_routes/get_route — and the outcome values are only repeated, not defined (e.g. what distinguishes 'stale' from 'partly_worked').

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 ('report whether it held') and enumerates the exact outcome vocabulary (worked, partly_worked, stale, failed) plus the accompanying fields. An agent can immediately distinguish this mutation/reporting tool from the read-oriented siblings like find_routes, get_route, and get_execution.

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 trigger condition is explicit and front-loaded: 'After using a route, report whether it held.' The rationale ('keeps routes fresh and flags stale ones for re-verification') clarifies why an agent would call it. It stops short of stating when not to report or which sibling to consult first (e.g. get_route to obtain the slug), so it is clear context rather than complete 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, and the description reinforces them ('never charges and never writes external state') plus adds gateway-specific behavior about what is executable versus merely discoverable. The added context is genuinely useful, but it largely restates the safety profile the annotations already carry.

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 tight sentences, each front-loaded with the core purpose first, then return shape, then safety and gateway constraints. No filler or repeated 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?

With no output schema, the description compensates by naming the return shape (candidate set with evidence-grounded match reasons, price, latency, status), and it explains the hosted-gateway invocation constraint. Nothing essential to correct selection or invocation 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?

Schema coverage is 100%, so parameter meaning is already fully documented in the schema. The description only gestures at price and 'free or pay-per-use' filtering without explaining how limit, media_type, or payment_modes behave, 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?

Names a specific verb and resource ('Find an external service') and scopes it to outcomes current tools cannot handle, which cleanly separates it from invoke_capability (execution) and get_capability (detail lookup). An agent can tell what this tool produces without opening the 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?

The conditional 'complete an outcome your current tools cannot' gives clear when-to-use guidance, and the note that writing capabilities are marked invocable_here:false implies the follow-up path. It stops short of naming sibling alternatives (get_capability, invoke_capability) explicitly.

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