School Signals and DfE AI Safety Evidence (USDC on Base)

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

The description states the tool charges 295 or 149 USDC via x402 payment settlement and gates the download link on that payment — a financial side effect — while annotations declare readOnlyHint=true and destructiveHint=false. That is a material inconsistency about whether the tool mutates anything.

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 clauses, each carrying distinct information: price/product mapping, return payload, and the alternative tool. The pricing and purpose are front-loaded 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 return-value burden well: it documents the signed 48-hour download link, file SHA-256, order URL, and the unpaid fallback to x402 terms. What remains unaddressed is the contradiction between the paid, state-changing behavior and the read-only 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 coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks by mapping each enum value to its price (295 USDC for school-signals-england-snapshot, 149 USDC for dfe-ai-safety-toolkit) and by noting that without payment the x402 terms are returned, explaining the optional x402_payment parameter's role.

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 the specific action (buy a paid file via x402) plus the two purchasable products and their exact prices, which also separates it from the sibling create_transfer_order path. An agent can identify the tool's job 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?

Explicitly routes the agent: use this for automatic x402 payment, and 'If your client caps automatic payments, use create_transfer_order instead.' It also states the no-payment branch, so both the happy path and the alternative are covered.

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=false, idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description adds valuable context: the tool is free, and with tx_hash it verifies canonical USDC, recipient, exact amount, success, time window, 10 confirmations, and that the hash was never used before. It does not detail failure modes or authentication requirements, but this is a strong addition beyond the annotations.

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

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

The description is a single, tightly structured sentence: it front-loads 'Free.' and then cleanly separates the two usage modes with 'With only order:' and 'With tx_hash:'. Every clause earns its place with no redundancy.

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

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

Given the tool's two-mode complexity, no output schema, and full schema coverage, the description is largely complete. It explains the return of a download link and the extensive verification steps, but omits what happens on verification failure and does not guide tool selection relative to siblings.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description significantly enriches semantics: `order` alone yields status and a fresh download link once paid; `tx_hash` triggers a detailed set of verification checks. This adds meaning far beyond the schema's minimal 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?

The description clearly states what the tool does in two modes: with only `order` it returns status and download link; with `tx_hash` it verifies a Base transaction. It uses specific verbs and resources, but does not explicitly distinguish itself from siblings like `create_transfer_order` or `buy_file_x402`.

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 how to use the tool's two parameter combinations (order only vs. order + tx_hash), which implies usage. However, it never states when to choose this tool over alternatives such as `create_transfer_order` or `buy_file_x402`, nor does it provide exclusions or prerequisites beyond the free note.

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, idempotentHint=false, openWorldHint=true), and the description adds genuinely new context: a 24-hour expiry, the Base network, the requirement that the amount be exact and the USDC canonical, and the single-transfer constraint. It does not say what happens on over/underpayment or expiry, but the added behavioral detail is meaningful.

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 dense sentences with the distinguishing point ("Free.") front-loaded and the follow-up call placed last. 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 and does well: it tells the agent the order expires in 24 hours, that the response implies an exact amount and recipient to pay, and what to do next. It omits what identifiers the response returns (order id, address shape), 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?

Only one parameter (product) and schema description coverage is 100%, so the schema fully documents it. The description adds no meaning about the parameter itself, so 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 ("Creates a 24-hour order") plus the asset and chain (exact USDC on Base), and names the notion of a "plain USDC transfer order" that contrasts with the sibling buy_file_x402 flow. It never explicitly names that alternative, so an agent must infer the selection boundary rather than read it.

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

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

Gives a clear operational sequence: create the order, send exactly that amount in one transfer, then call check_transfer_order with the tx hash. It establishes when to use this tool within the workflow but does not state when NOT to use it or how it differs from buy_file_x402.

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 readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds information the annotations do not: the call is free of charge and the products are paid via x402 or plain transfer on Base, which tells the agent no payment is consumed by this call.

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 compact sentence with the most decision-relevant fact ('Free.') front-loaded. The telegram-style fragment omits a verb-subject (e.g. 'Lists'), which costs a little readability but wastes no words.

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

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

For a no-argument, no-output-schema listing tool, the description covers the essential content (what comes back and how payment works). It could be slightly more explicit about ordering/pagination, but nothing critical for correct invocation is absent.

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 (empty schema, additionalProperties false), so per the baseline there is nothing for the description to disambiguate. No parameter detail is needed or missing.

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 concrete resource (every product) and enumerates the payload fields (price in USDC, route, licence, payment method), so the agent knows this is a catalog/discovery read. It doesn't explicitly name a sibling, but the free catalog framing clearly separates it from buy_file_x402 and the transfer-order tools.

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

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

The leading 'Free.' implies this is the discovery step you run before buying, which is useful usage context, but there is no explicit when-to-use/when-not statement and no named alternative. Usage is inferable 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 already cover readOnly/idempotent/destructive safety, so the description adds real value on top: the $0.20 USDC charge, the payment mechanism being required, and the important guarantee that unresolvable or ambiguous buyers are refused *before* payment, so the agent knows a failed call is free. Missing only output shape/size and latency expectations.

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

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

Two sentences, front-loaded with the price and then the payload contents, with the refusal behavior last. Appropriately sized for a paid bundle tool; the deliverable list is dense comma-clause prose that takes a second read but every item earns its place.

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

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

No output schema exists, and the description compensates by enumerating the sections returned, plus the cost and the no-charge-on-refusal rule. What remains unstated is the response format (structured JSON vs prose) and whether renewal estimates are labeled as estimates — minor for a read-only paid brief.

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% — the allowed identifier forms (school:<URN>, trust:<UID>, org:<slug>, URN, exact name) and the x402 payment payload are fully documented in the schema. The description adds only the soft rule that ambiguous names are rejected rather than guessed, which is useful but does not extend parameter semantics much.

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 deliverable (a buyer brief) and enumerates its contents — hierarchy, edtech contracts and incumbents, renewals with windows, live tenders, trust changes, official links — scoped to exactly one buyer. That enumeration implicitly separates it from narrower siblings like school_renewals and school_signals_search, but 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?

Usage is only implied: it must be for a single resolvable buyer, and 'Unknown, ambiguous (candidates returned) or evidence-free buyers are refused before payment' tells the agent what inputs will fail. There is no explicit statement of when to pick this bundle over school_renewals or school_signals_search, nor a prerequisite check the agent should run first.

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 the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower, and the description still adds real context: a hard cost of $0.03 USDC, a 25-result cap, and the fact that empty or invalid queries are refused before charging. It does not mention whether repeat identical calls are billed again, which is the one behavioral gap left given idempotentHint=true.

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

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

Two sentences, front-loaded with price and then payload contents, with the payment-refusal rule last. Dense but every clause carries information. Slightly long within a single clause, but 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 correctly enumerates the returned fields (incumbent, value, extensions, re-procurement window, official notice links) and states the 25-record cap, which is what an agent needs to judge fitness. Payment mechanics are covered by both the description and the x402_payment schema entry. Only the billing-on-repeat 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 description coverage is 100%, so the schema already documents all seven parameters including the enums, the 1-24 month bound and the x402 payment payload. The description only loosely echoes the window/incumbent concepts without adding format or constraint detail. Baseline 3 is appropriate when the schema does the heavy lifting.

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 names a specific resource and scope: up to 25 published edtech contracts at English schools/trusts/councils ending within a window, plus the fields returned (incumbent, value, extensions, re-procurement window, notice links). That is enough for an agent to distinguish it from school_signals_search or school_buyer_brief in practice. It never explicitly contrasts itself with those siblings, 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?

Usage is implied rather than stated: the tool is for finding upcoming renewals, and the schema's buyer param points back to school_signals_search, hinting at a workflow. There is no explicit when-to-use vs. the other school_* siblings or when-not-to-use guidance. The payment precondition ('empty results and invalid filters are refused before payment') is the only concrete gating rule.

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, openWorld and non-destructive, so the safety profile is covered. The description still adds real value beyond them: the 'Free' cost signal is meaningful in a sibling set containing buy_file_x402 payment tools, and it discloses the shape of the returned counts rather than just saying 'search'.

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

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

Two sentences, no filler. The cost qualifier is front-loaded and the return contents are packed into one clause; nothing could be cut without losing routing or result 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 usefully enumerates what comes back, and annotations cover the safety profile, which is adequate for a one-parameter search. It omits any mention of result limits or pagination, the only real 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 there is a single required parameter whose accepted forms (name, URN, GIAS group UID) are documented in the schema itself. The description's id-prefix notation is output-oriented and only loosely reinforces the query formats, 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 ('Find') and resource ('buyer ids') scoped to English schools, trusts and councils, then enumerates exactly what each result carries (published edtech contracts, renewals, live tenders, trust changes). The id formats (school:<URN>, trust:<UID>, org:<slug>) make it distinguishable from the sibling school_renewals and school_buyer_brief at a glance.

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 routes the agent: 'Use before school_buyer_brief' names the sibling and the sequencing condition. It gives no when-not guidance or alternatives for the non-brief siblings, so it stops short of a 5.

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