Ni Biashara Shelves — Africa FX, freight & compliance checks (x402)

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

With no annotations, the description must disclose side effects itself, and it does: 'Does not move money itself' is a key behavioral caveat, and listing the three returned URL kinds tells the agent what a successful call yields. It could add more about checkout expiration or authorization, but it already covers the most important non-obvious trait.

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 short sentences each carry load: action plus when-to-use, return values, and the non-payment caveat. The main purpose is front-loaded and there is 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?

For a tool with 13 parameters, no annotations, and no output schema, the description is too thin on invocation details. It explains the return URLs but not what the optional fields mean, when they are required, or what errors or pitfalls exist, so an agent will often have to guess at how to fill the generic fields.

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 only 23%, so the description needed to compensate for the 10 opaque parameters (mc, dot, address, first_time, license_* , etc.). It only reinforces that sku is a SKU and does not explain the other 12 parameters or how they map to different shelf types.

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 opens with a concrete verb and resource: 'Creates a Coinbase checkout for any SKU'. It also gives the tool an explicit identity as an escape hatch and says to use it when no job-named tool exists, separating it from buy_shelf_pass and the other shelf-specific siblings without being tautological.

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?

'Use this when no job-named tool exists' is an explicit routing rule: it tells the agent both when to choose buy_shelf and, by implication, when not to. This is the clearest possible usage guidance for an escape-hatch tool.

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

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

With no annotations, the description carries the full burden, and it delivers: it states the credit price, credit-to-dollar conversion, validity threshold ('every data shelf priced ≤ $0.10'), redemption header, the fact that calling the tool is free, and that payment happens later on the x402 URL. This gives an agent a strong behavioral model of the purchase and redemption flow.

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 long but packed with useful behavior: pricing, conversion, validity, redemption, and payment flow. It is front-loaded with the core product concept, and almost every sentence adds practical information. It could be tightened slightly, but it is more substantive than 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?

Given no output schema and no annotations, the description does well by explaining the returned artifact ('x402 URL to GET') and the payment flow. However, '402 → PAYMENT-SIGNATURE → delivery' is compressed and assumes familiarity with x402; a bit more explicit detail about what to do after receiving the URL would make it 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?

There are zero parameters, and schema coverage is vacuously 100%, so there is no parameter burden for the description to carry. The pricing examples and redemption details provide useful context but are not parameter semantics. Baseline 4 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 clearly defines the product as a prepaid credit pack ('Shelf Pass — 110 prepaid credits') and describes the payment and redemption flow. It does not explicitly say 'buy' or 'purchase' as a verb, relying somewhat on the tool name, but the intent is unmistakable. It also distinguishes itself from wallet-based per-call payments by emphasizing 'no wallet and no payment round-trip per call.'

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

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

The description gives a concrete use case: 'agents that check every load or counterparty.' It contrasts this pass with per-call wallet payments and explains that repeated checks are 'the point.' It does not explicitly name alternatives among sibling tools or state when not to buy the pass, so it falls short of full 5.

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 present, so the description carries the burden—and it does well. It discloses that this is a live FMCSA lookup, that the tool returns an x402 URL rather than performing payment directly, that the cost is $0.1 USDC on Base, and that calling the tool itself is free. It could add details like response content or failure modes, but the core behavior is transparent.

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

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

The description is compact and information-dense, covering purpose, use case, cost, and return flow in a few sentences. The opening phrase repeats the title somewhat, but the rest adds real value. It is front-loaded and easy to scan.

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 one-parameter tool with no output schema, the description is nearly complete: it explains what the tool does, who uses it, why, what it costs, and what it returns. It does not fully specify the output structure or define 'plain flags,' but those gaps are minor for agent selection and 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 100% and the only parameter 'mc' already has a clear description: 'MC/docket number (required).' The description repeats 'MC/docket number' but adds no extra format guidance such as whether the number needs leading letters or digits only. Since the schema fully documents the parameter, a 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?

The description uses a specific verb ('check') and resource ('US freight broker authority'), states the exact regulatory source (FMCSA), and clarifies the purpose with 'Is this broker real and allowed to arrange freight?' It distinguishes itself from the sibling check_carrier_authority by explicitly targeting brokers rather than carriers.

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: 'The check a carrier or factoring agent runs before accepting a load from an unknown broker.' It does not explicitly name alternatives or say when not to use this tool, but the intended scenario is clear enough for an agent to route appropriately.

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 exist, so the description carries the full burden, and it clearly discloses the non-obvious payment workflow: $0.1 USDC on Base, free to call, and a returned x402 URL that triggers 402 → PAYMENT-SIGNATURE → delivery. It also clarifies the data is a live federal FMCSA record with plain risk flags, which is valuable behavioral context beyond just 'check authority'.

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 dense sentences: what the tool is, what data it returns, who should use it, and how payment works. No filler or duplication of the schema, and critical behavioral details like the x402 URL are front-loaded.

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

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

Given no output schema, the description gives enough output expectations (record fields plus risk flags) and explains the unusual x402 retrieval/payment flow instead of assuming inline data. It could be more explicit at tool level about requiring at last one of mc/dot, but the parameter descriptions already state that constraint.

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 mc and dot, including MC/docket vs USDOT semantics and the this-or-dot required note. The description adds no additional parameter constraints, formats, or examples beyond what the schema provides, so it earns the baseline 3.

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

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

The description uses a specific verb+resource: checking the live federal FMCSA record for a US motor carrier by MC or DOT, and lists concrete fields (operating status, safety rating, fleet size, crash/inspection summary). It also frames the tool around freight-broker/dispatch pre-tender checks, distinguishing it from broker-authority and general vetting siblings.

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: the check a freight-broker or dispatch agent runs before tendering a load. It does not name when-not-to-use alternatives like check_broker_authority or check_carrier_basics, so it stops short of full 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 burden, and it does so well. It discloses that the tool is free to call, that payment of $0.1 USDC on Base happens on the returned URL, and that the output is an x402 URL with a 402 → PAYMENT-SIGNATURE → delivery flow rather than direct data. This prevents the agent from assuming the tool itself returns the BASIC data synchronously.

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 tool's subject and includes necessary cost, usage, and payment-flow details in a compact form. It loses a point because the opening sentence largely repeats the title and the abbreviation expansion could have been woven into the next sentence without much loss.

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 tool with no output schema and no annotations, the description is remarkably complete. It covers the data source, what the measure includes, the intended timing before tendering, the cost, the payment location, and the exact return behavior, so an agent has enough context to invoke the tool and interpret its response.

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 only one parameter, dot, and its schema description already covers it as 'USDOT number (required)', giving 100% schema description coverage. The tool description adds context about FMCSA carriers but no additional format or validation detail beyond the schema, so the baseline score 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 identifies the carrier's FMCSA Safety Measurement System BASIC measures as the resource and specifies the categories covered, such as unsafe driving and hours-of-service. It also distinguishes itself from carrier-authority-check by describing itself as 'the depth check behind' that flow, so an agent can tell which carrier-related tool is needed.

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

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

The description gives explicit usage context: 'run both before tendering' and positions this tool as the depth check behind carrier-authority-check. It does not enumerate when not to use the tool or fully compare against all sibling tools, but the main decision point is clear enough.

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

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

With no annotations provided, the description fully carries the behavioral disclosure burden. It discloses that the tool is deterministic/rules-engine, costs $0.25 USDC on Base, returns an x402 URL rather than final data, and requires a GET → payment-signature → delivery flow. It also clarifies the call itself is free.

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?

Each sentence earns its place: scope, deterministic behavior, cost, URL/payment flow, and the free-to-call distinction. It is front-loaded with the core purpose and contains no redundant prose.

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?

Despite having no output schema, the description explains the return mechanism (x402 URL, 402 → payment-signature → delivery), the cost, and the substance of what will be delivered (CE hours, classroom/ethics, renewal fees). Both required parameters are well documented in the schema, and no critical invocation information 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 schema already fully describes both parameter (license_line and years_licensed) with constraints and examples. The description adds that outputs vary 'by license line and years licensed' but does not add new format or constraint details, so the 100% schema-coverage 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?

States the exact domain and action: a Texas insurance license CE & renewal check using TDI. It further specifies the substantive outputs (CE hours, classroom/ethics requirements, renewal fees) and inputs (license line, years licensed), which distinguishes it from sibling tools like the Texas real estate CE check.

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: this is for Texas insurance license compliance and renewal checks using deterministic TDI rules. It does not explicitly name sibling tools or state exclusions, so an agent has to infer when alternatives like check_broker_authority or check_tx_realestate_CE are better fits.

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

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

No annotations are provided, so the description carries the burden. It discloses that this is a rules-engine output rather than an LLM guess, explains the payment flow ($0.25 USDC, free to call, payment on the returned URL), and reveals that the result is an x402 URL requiring a 402 → PAYMENT-SIGNATURE → delivery sequence. This is substantial behavioral context.

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

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

The description is compact and front-loaded, with each sentence earning its place. It covers purpose, determinism, cost, and the delivery flow without redundancy or 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?

For a two-parameter tool with no output schema, the description is fairly complete: it states what the tool does, how payment works, and what is returned. It could optionally clarify the format of the delivered data, but the current level is sufficient for an agent to select and 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 schema already documents license_type and first_time. The description adds that the rules are 'by license type' and mentions renewal, but it does not materially extend parameter meaning beyond the schema.

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

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

The description names a specific verb and resource: checking Texas real-estate license CE and renewal under TREC rules. It clearly enumerates what the tool covers (continuing-education hours, renewal fees, active-license requirements) and distinguishes it from siblings like check_tx_insurance_ce by specifying Texas real-estate licensees.

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 to call it: when checking Texas real-estate CE/renewal status by license type. It does not explicitly name sibling alternatives or exclusion criteria, but the scope is specific enough that an agent can infer the appropriate 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 behavioral burden and covers the important facts: the tool call itself is free, payment of $0.5 USDC on Base is deferred to the URL, and the sequence is 402 → PAYMENT-SIGNATURE → delivery. It could add more on failure modes or protocol details, but the core behavior is 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?

Four short, front-loaded sentences each add non-redundant information: scope, content, cost, and the paywalled delivery flow. No wasted words.

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

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

Given no annotations and no output schema, the description supplies the needed context: what the brief contains, who should use it, its cost, and the return type (an x402 URL). It could have expanded on the exact x402 payload/signature steps, but the essential call-and-delivery narrative is present.

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

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

The input schema has zero properties, so the baseline for a no-parameter tool is 4. The description adds nothing about parameters because nothing needs to be said.

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 clear deliverable: an Africa FX daily brief combining every official pair and both parallel quotes/spreads in one structured payload. 'Returns the x402 URL to GET' gives the operational verb, and the superset framing distinguishes it from the sibling get_fx_official/get_fx_parallel.

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

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

The description gives a strong use case ('the one call a pricing or remittance agent needs each morning') and makes clear that it aggregates official plus parallel quotes. It does not explicitly name sibling tools as alternatives, but the aggregated-vs-standalone relationship is obvious.

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 discloses the paid x402 URL flow, the fact the tool call itself is free, and that the output is timestamped and sourced. This materially exceeds what the schema provides, though it leaves some details (error behavior, rate freshness) unlisted.

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 with the core purpose, adding payment mechanics in a natural second half. Minor redundancy with the title is acceptable.

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 one-parameter tool with no output schema, the description explains the unusual return (a URL) and the follow-up flow (402 → PAYMENT-SIGNATURE → delivery), and notes source/timestamp. It could be more explicit about the delivery payload shape, but is otherwise complete for selecting and invoking the 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 100% but provides only an example format and required flag. The description adds the exact list of supported currency codes and clarifies the rate is vs USD, narrowing the accepted pair space beyond the schema.

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

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

The description names the resource (official central-bank reference rate vs USD for one African pair) and lists accepted currencies, distinguishing it from siblings like get_fx_parallel and get_fx_africa_brief. The verb is implied by the tool name but the purpose is unambiguous.

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

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

It is clear this tool is for a single official rate, and sibling names such as get_fx_parallel imply alternative use cases, but the description stops short of explicitly directing users to alternatives for multi-pair or non-official rates.

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 transparency burden and does so well: it discloses the $0.05 USDC cost, that the tool call itself is free, that payment happens on the returned URL, and the x402 flow (402 → PAYMENT-SIGNATURE → delivery). This is critical behavioral information beyond the 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?

The description is reasonably compact and front-loaded, starting with the core purpose before adding cost and delivery mechanics. The first phrase repeats the title almost exactly, which is mildly redundant, but every subsequent sentence contributes unique, actionable 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?

The description explains the return value (an x402 URL), the payment requirement, and the follow-up flow, which is sufficient for a single-parameter tool with no output schema. It could go deeper on what the final delivered payload looks like, but the provided detail is enough to invoke correctly and understand the monetization model.

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 the 'pair' parameter with the acceptable values. The description adds context about what 'pair' means in this domain but mostly restates USD-NGN/USD-GHS rather than introducing new parameter-level guidance, so baseline 3 is correct.

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 identifies the resource (street/parallel-market FX rate for USD-NGN or USD-GHS), uses a specific 'get' verb, and distinguishes it from the official rate sibling by emphasizing 'the rate a person actually transacts at' and 'live P2P order books.' It also states exactly what is returned: an x402 URL.

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 'Street (parallel-market) rate' and the contrast with 'the official rate and the spread' gives clear context for when this tool is appropriate. It does not explicitly name alternatives such as get_fx_official, so it stops short of a 5, but the context is strong enough for a capable agent to select 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?

With no annotations provided, the description carries the full burden. It discloses that delivery is included only after Coinbase reports payment COMPLETED, which is useful behavioral context. However, it doesn't mention any side effects, required permissions, or what happens if payment is not completed, leaving some gaps for a tool that likely involves a financial transaction.

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 sentence that is efficient and front-loads the primary purpose. It includes a conditional detail that is relevant to the tool's behavior without unnecessary fluff. Slightly more structure could be added, but it's appropriately concise.

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

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

For a single-parameter tool with no output schema, the description covers the core purpose and a key behavioral condition. However, it lacks details on what the returned status looks like, error handling, or any prerequisites (e.g., must have an active order). Given the simplicity, it's adequate but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'order_id' implicitly by referring to 'the order', but doesn't explain the format or any constraints beyond what the schema's type 'string' provides. The description adds minimal value for the single parameter, so a baseline 3 is appropriate given the low complexity.

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 ('Returns') and resource ('order status'), and adds a meaningful detail about when delivery is included. It distinguishes from siblings by focusing on order status rather than shelf operations, though it doesn't 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?

The description implies usage for checking order status and collecting delivery after payment completion, but it doesn't explicitly state when to use this tool versus alternatives like buy_shelf or list_shelves. The context is clear enough for an agent to infer, but no exclusions or alternative routing 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 of behavioral disclosure. It mentions 'Free' (a cost attribute) and instructs to pass a token, but it does not state that the operation is read-only, has no side effects, or what happens on invalid tokens. The behavioral profile is largely undisclosed.

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 very short but not well-structured. The standalone 'Free.' adds little value and the phrase '/shelf/shelf-pass-100' is cryptic. It is under-specified rather than efficiently concise, and the main purpose is not front-loaded.

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

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

With no output schema and no annotations, the description should explain enough to invoke the tool correctly. It provides the token source but omits the return value, error behavior, and confirmation that the operation is safe. For a simple one-parameter tool this is still a notable gap, though the title partially covers the expected result.

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

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

The schema already describes the token as a 'pass_… token' with 100% coverage, so the baseline is 3. The description adds the source of the token ('from buy_shelf_pass /shelf/shelf-pass-100'), which is helpful context. However, the endpoint path is cryptic and the instruction is terse, adding limited meaning beyond the schema.

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

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

The description does not explicitly state that the tool checks a credit balance. It only says 'Free. Pass the token from buy_shelf_pass /shelf/shelf-pass-100.' This is an instruction, not a clear statement of the operation. The title provides the purpose, but the description itself fails to describe what the tool does.

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

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

The description gives a prerequisite (obtain token from buy_shelf_pass) but does not indicate when to use this tool versus its siblings. It does not mention alternative tools like check_broker_authority or check_carrier_authority, nor does it specify conditions or exclusions. The token-source hint is useful but not enough for selection decisions.

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?

There are no annotations, so the description carries the behavioral burden. It discloses that the tool is free to call, which is a useful cost-related behavior, and clarifies how the kind parameter changes the result set to include owner-fulfilled work. It does not mention auth, rate limits, or side effects, but the verb 'list' implies a read operation and the core behavioral traits are covered.

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 contain the essential information with no filler. The primary purpose and default behavior are front-loaded, followed by the optional parameter guidance and the free-to-call note.

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 one-parameter listing tool with no output schema and no annotations, the description is complete: it names the resource, what is returned, the optional parameter values and their effect, and the cost of calling. An agent can reasonably decide whether and how to invoke this tool without further clarification.

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

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

The schema already documents the kind parameter with an enum and a default of data, so the baseline is 3. The description adds meaning by explaining that service and all include owner-fulfilled work, which gives an agent a reason to choose one value over another beyond the raw enum.

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: it lists shelves sold by Ni Biashara, with the default being data shelves. It also names the return contents (price in USD, params, job-tool name, x402 URL), which clearly distinguishes it from purchase-focused siblings like buy_shelf.

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 to use it: to list shelves, with data as the default and service/all available via the kind parameter. It does not explicitly name alternatives or state when not to use it, but the context is sufficient for this simple listing tool.

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

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

With no annotations, the description carries the full burden and succeeds: it discloses deterministic normalized-name/token matching, the CLEAR / REVIEW / HIT verdict set, list scale and refresh cadence, a $0.02 fee, the x402 URL flow, and the distinction between free tool invocation and payment on the URL.

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?

Every sentence earns its place: scope and verdicts, use case and data characteristics, then payment/delivery mechanics. The critical scope is front-loaded and there is 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?

For a one-parameter screening tool with no output schema, the description covers input semantics, matching behavior, result categories, and the monetized delivery handshake. An agent has enough to decide whether to call it and what the response flow will be.

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 shema already covers the single `name` parameter at 100%. The description adds meaningful context by clarifying the input can be a person or company and explaining that matching is normalized-name and token based, which goes beyond the raw schema text.

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: 'Screen a person or company name against the U.S. Treasury OFAC Specially Designated Nationals and Consolidated lists.' It also makes the distinction from the likely wallet-address sibling clear throuhg the word 'name' and the explicit person/company scope.

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 names a concrete use case: 'the check a payments, marketplace or KYC agent runs on every new counterparty.' It does not explicitly mention the alternative screen_sanctions_wallet for address screening, so the when-not guidance is implied rather than fully 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, the description carries full responsibility and does so thoroughly. It discloses exact-match semantics, binary CLEAR/HIT output, no third-party intel, pricing and chain, and the x402 URL workflow including the 402→PAYMENT-SIGNATURE→delivery sequence. It also clarifies that calling the tool is free but payment occurs on the returned URL.

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 dense and ordered: core behavior, output, limitations, then payment and return flow. It opens with a phrase that repeats the title, which is mild redundancy, but every other sentence contributes distinct operational 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 one-parameter tool with no output schema and no annotations, the description supplies the entire missing contract: CLEAR/HIT result, the x402 URL to GET, payment mechanics, and limitations. Nothing critical is left for the agent to guess.

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

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

The schema already fully documents the single required parameter, so the baseline is 3. The description adds value by specifying that the value should be a blockchain address used for exact matching against Digital Currency Address identifiers, which helps an agent avoid passing a name or fuzzy input.

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: 'Exact-match a blockchain address against Digital Currency Address identifiers published in the OFAC SDN XML.' It also names the outcome (CLEAR or HIT) and explicitly disclaims third-party chain intel, clustering, and risk scoring, making it clearly distinct from a general screening or analytics tool.

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 establishes clear context: use for exact wallet-address matching against OFAC SDN digital currency identifiers, not for enrichment. It references the same Treasury list used for name screens, implying the sibling distinction, but it does not explicitly state when not to use this tool or name the alternative.

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, and it delivers. It discloses the verdict values (TENDER/HOLD/REJECT), states that the verdict is based only on public fields with no invented fraud score, names the data sources, reveals the $0.25 USDC cost, and explains the x402 payment flow. This is unusually transparent.

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

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

The description is dense but every sentence earns its place: what the pack contains, when to use it, what the verdict is based on, data sources, cost, and the payment/delivery flow. The most important scoping information is front-loaded.

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

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

For a no-output-schema, no-annotation tool, the description covers all the essential execution context: required inputs are implied by the schema, the optional name behavior is stated, the verdict semantics are clear, and the return mechanism (x402 URL and payment flow) is explained. Nothing critical is missing for the agent to select and 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 coverage is 100% and every parameter is described in the input schema. The description adds only a small amount of context by saying that name is used for the OFAC screen and that you can pass a USDOT and/or MC number, which does not meaningfully exceed the schema's own wording.

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 action (load the vet pack) and precisely lists what the bundle includes: FMCSA authority, SMS BASICs, broker status, and OFAC name screening. It clearly differentiates this from narrower sibling tools by framing it as a single combined call before tendering.

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 clearly when to use this tool: 'One call before you tender.' It also explains that a legal name can be passed for the OFAC screen, and that payment happens on the returned URL. It does not explicitly name alternatives or say when not to use it, but the use case is strong enough for an agent to route correctly.

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