AgentIndex x402

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds some value beyond that with 'Fresh' (implying no cached results) and by disclosing that it will make live outbound calls against the target's x402 challenge and manifests, but it says nothing about rate limits, whether auditing certain targets requires payment, or failure/timeout behavior.

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

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

One dense, well front-loaded sentence states scope, then the return summary, then a sample pointer. No filler, though the enumerated checklist is packed tightly enough that it reads more like a feature list than guidance.

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

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

An output schema exists, so the description need not explain return values (it summarizes them briefly anyway), and the audit scope is fully covered. The remaining gap is selection guidance against sibling tools, which is a usage issue rather than a completeness hole for invoking this tool.

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

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

Schema description coverage is 100%, so both 'url' and 'method' are already documented with types and a default. The description only implies the target must be public and adds nothing about URL format, supported schemes, or how 'method' interacts with the x402/OpenAPI checks; 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?

Names a specific verb and resource ('operational audit of any public agent or paid API') and enumerates exactly what is inspected (reachability, latency, HTTP status, x402 challenge, OpenAPI, agent card, MCP manifest). It is unambiguous what the tool does, but it never positions itself against the nearest sibling, notably 'probe', so an agent must guess which audit tool to pick.

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

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

There is no when-to-use or when-not-to-use guidance. The only routing hint is 'Try GET /agent-health/sample', which is a pointer to a sample endpoint rather than a selection rule, and the sibling 'probe' is never mentioned or excluded.

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/openWorld/non-idempotent, yet the description adds substantial behavior the annotations cannot: the exact price formula (max_tokens x rate x 1.10, ceiling signed, unused tokens not refunded), a 20s server-side timeout with no charge if it fires, and a recommended 30s client timeout. This is exactly the cost/timeout/auth context an agent needs before invoking a paid endpoint.

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

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

Front-loaded with the core purpose and packed with high-value facts; almost every clause earns its place. It is dense to the point of being slightly run-on, but there is little fat to cut.

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 paid, keyless inference tool the description covers pricing, timeout semantics, auth requirements, and a discovery/sample endpoint, and an output schema already exists so return values need not be explained. Nothing essential to calling it correctly is missing.

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

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

Schema description coverage is 100% and every parameter (model, messages, max_tokens) is already documented in the schema, so the description need only complement it. It reinforces that max_tokens bounds the x402 price ceiling, but adds no new format or syntax detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource: an OpenAI-compatible chat completion / inference gateway aggregating 437 models. It clearly separates itself from single-model siblings like llm_gpt_mini by emphasizing '437 models ... in one endpoint', but it never names those siblings or explains why an agent would pick this gateway over them, so differentiation is implied rather than explicit.

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

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

Gives concrete usage context: no account, no API key, pay per call in USDC, and points to GET /v1/chat/completions/sample as a try-it path. It does not state when NOT to use it or how it compares to the llm_* siblings, so the routing guidance is present but incomplete.

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

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

With no annotations, the description carries the full burden. It usefully discloses that this is a read via eth_call (read-only) and that it operates on Base mainnet through RPC. However, it omits return-format behavior (raw uint256 vs decimals-adjusted), rate limits, or caching, leaving meaningful behavioral gaps for an unannotated tool.

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

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

A single compact sentence, front-loaded with the purpose and network, that packs in the resource, scope, and the underlying call. 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?

No annotations and no output schema, so the description bears the full disclosure burden. It conveys the conceptual return value but says nothing about the returned unit (raw base units) or structure, which matters for allowance reads. Adequate but with a clear gap for a read tool lacking an output schema.

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

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

Schema coverage is 0%, so the description must compensate. It explains the owner and spender roles well ('how much a spender is approved to move from an owner balance') and implies the token via 'ERC20 allowance'. It does not specify address/format expectations for token, owner, or spender, so it is strong but not complete.

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

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

States a specific verb+resource: reads the ERC20 allowance (approved amount) that a spender can move from an owner balance, on Base mainnet via RPC. This clearly distinguishes it from siblings like base_erc20-balance (owner's balance) and base_call (generic call) without needing 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?

Usage is only implied by the described semantics of the call ('how much a spender is approved to move'). There is no explicit when-to-use, no when-not-to-use, and no routing to alternatives such as base_erc20-balance or base_call despite a large sibling set.

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

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

With no annotations, the description carries the full behavioral burden, yet it only says the lookup goes through the 'L2 Basenames resolver'. It omits failure behavior (unregistered name, malformed suffix), return shape, and whether this is a gas-free read; an agent cannot predict what happens on a miss.

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 front-loaded sentence with zero filler; the verb, argument, output, and mechanism are all packed in without repetition.

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 annotations, no output schema, and an undocumented nested parameter mean the description should do much more. It never states the expected name format, the returned value on success, or behavior on resolution failure, leaving an agent under-briefed for a lookup 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 description coverage is 0% and the single parameter is a nested object with an undocumented 'name' field. The description adds no syntax guidance, such as whether the value needs a '.base'/' .eth' suffix, case sensitivity, or normalization rules, so it does not compensate for the coverage gap.

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

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

States a specific verb (resolve) and resource (Basename) plus the outcome (wallet address), and distinguishes itself from the many sibling base_* tools that deal with blocks, txs, and balances. The 'Base's native ENS-equivalent' gloss makes the resource unambiguous to an agent unfamiliar with the ecosystem.

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 purpose strongly implies the usage case (convert a name to an address), but there is no explicit when-to-use/when-not, no mention of the reverse operation (address -> name), and no guidance about what to do if the name is unregistered. 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that only the header and transaction hashes are returned (not full transactions) and names the underlying RPC methods, but says nothing about error handling, finality implications of the tags, or return format.

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?

A single dense sentence that front-loads the action and resource, then packs the accepted selectors and RPC mapping without any 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?

For a no-output-schema, no-annotation read tool, the description covers what is fetched and the selector options well. The remaining gap is input-structure guidance for the nested required payload, which the 0%-covered schema leaves undocumented.

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 does add value by enumerating valid tag values (latest/earliest/safe/finalized) that the untyped 'number' field could accept, but it does not explain the null/default semantics of the hash and number fields or how they interact inside the required payload.

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 (Fetch) and resource (Base mainnet block header and transaction hashes), plus the three input modes (number, tag, hash). It is clear on its own, but it never distinguishes itself from the sibling base_block-number, which appears to overlap heavily.

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 when you'd reach for it (fetching block data) and lists the accepted selectors, but gives no explicit when-to-use vs when-not guidance and does not tell the agent how this differs from base_block-number or base_receipt.

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 imply a read-only query and names the underlying eth_blockNumber call, which conveys the read semantics. However it says nothing about freshness guarantees, caching, rate limits, or network requirements for a chain-tip read.

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 front-loaded sentence with no waste; the resource and scope come first. It is appropriately sized for a trivial read tool, though 'via eth_blockNumber' is somewhat redundant with the name.

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?

There is no output schema, and the description only qualitatively states the return ('block height', 'chain tip') without format (hex vs decimal) or whether it is cached/live. For a simple read tool this is mostly adequate but leaves a small gap an agent would want filled.

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's single required 'payload' is an empty nested object with no properties, so there is effectively nothing for the description to document; baseline 4 applies. The description adds no syntax detail, but none is needed for a zero-argument call.

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+resource (retrieve latest Base mainnet block height) and even pins the underlying RPC method (eth_blockNumber) and the concept (chain tip). It is precise, but it does not distinguish itself from the sibling base_block, leaving the agent to guess how the two differ.

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

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

There is no statement of when to use this versus alternatives, no prerequisites, and no exclusion of the closely related base_block sibling. The agent gets no routing guidance beyond the name.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the two most important traits for an eth_call: it is read-only (no state change) and it returns raw, un-decoded return data. It omits auth requirements, revert/error behavior, rate limits, and whether the call can consume gas or be simulated.

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?

A single front-loaded sentence with zero filler. It leads with the tool's nature and immediately states input and output semantics.

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 annotations and no output schema, the description must carry more weight. It does convey the return shape (raw return data) and the general contract, but leaves the nested payload fields and behavioral constraints undocumented, which is a gap for a low-level RPC wrapper.

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% across a nested object with four sub-fields (to, data, value_wei, from_address). The description only loosely gestures at the 'data' field via 'raw calldata' and does not explain 'to' (target contract), 'value_wei', or 'from_address', so it fails to compensate for the coverage gap.

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

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

States a specific verb and resource: a read-only eth_call against any Base mainnet contract, with explicit input (raw calldata) and output (raw return data). The word 'Generic' and 'raw' distinguishes it from higher-level siblings like base_contract, though no sibling is named directly.

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?

'Pass raw calldata, get the raw return data back' implies this is the low-level fallback for when you already have calldata and no typed interface. However, it never states when to prefer this over base_contract or other Base read tools, nor any preconditions.

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 present, the description carries the full burden and does well: it discloses the mechanism (atomic on-chain call, real buy then real sell), the failure semantics (sell revert = honeypot, with decoded reason), and an explicit scope limitation ('Factual, never predictive'). It omits cost/gas implications and any permission or rate-limit context, keeping it out of 5 territory.

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

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

Two tight sentences, front-loaded with the decision question, followed by mechanism and the failure criterion. 'Factual, never predictive' is a compact and load-bearing disclaimer rather than 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 single-purpose check with no output schema and no annotations, the description explains the mechanism and result interpretation adequately. However, it leaves the nested input parameters undocumented, so an agent lacks guidance on token formatting and tuning the test ETH amount.

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

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

Schema description coverage is 0% and the parameters are nested under 'payload'. The description never explains 'token' format or the 'test_eth_wei' test amount (default 0.01 ETH), which is a meaningful choice point for the caller. Only the vaguest mapping ('this token') exists.

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 (simulate a buy/sell) and resource (Base mainnet token via Uniswap V2) and frames it as a honeypot check, so the agent knows exactly what capability this is. It does not explicitly contrast itself with nearby siblings like base_simulate or token_risk, so it falls short of a 5.

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

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

The opening question 'Can I sell this token?' implies the use case, and 'if the sell reverts, that is a honeypot' clarifies the outcome interpretation. But there is no explicit when-to-use/when-not guidance and no mention of alternative tools such as token_risk or base_simulate for related checks.

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 and no output schema, so the description carries the burden. It discloses the mechanism (eth_chainId / EIP-155), which usefully signals a non-destructive read, but it does not state the return format (hex string vs. numeric) or confirm read-only/idempotent behavior explicitly.

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?

A single front-loaded sentence with the resource first and the rationale trailing; zero filler, nothing to trim.

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 trivial getter the description is mostly adequate, but with no annotations and no output schema it should at least state what comes back (the EIP-155 chain ID value) and how it differs from base_network-info. These gaps keep it at minimum-viable.

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 single required parameter is an empty object (ChainIdInput with no properties), i.e. effectively a zero-argument call, so the baseline for no real params applies. The description adds nothing about the required empty payload wrapper, but there is no field-level semantics to document.

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 (Base mainnet chain ID), the standard (EIP-155), and the underlying method (eth_chainId), so an agent knows exactly what this returns. It does not, however, distinguish itself from the sibling base_network-info, which likely covers overlapping ground.

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?

"confirm which network you're actually talking to" implies a usage context (network verification) but gives no explicit when-to-use/when-not or any alternative routing. With base_network-info present as a sibling, the absence of differentiation leaves the agent to infer.

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 does well for a simple read: it pins the network (Base mainnet), names the RPC call, and discloses the return semantics (bytecode size, zero for an externally-owned account). It omits whether any auth/rate limits apply, but the safety profile is unambiguous.

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?

A single, front-loaded sentence with no filler: purpose first, then the mechanism, then the return contract. Every clause 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?

For a one-parameter read tool with no output schema, the description covers the essentials: network scope, method, and what the returned number means. The remaining gap is the undocumented nested payload/address 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 0% and there is one nested parameter object, so the schema documents nothing. The description implies the address input ('a Base mainnet address') but does not explain the required 'payload' wrapper object or the address format, leaving the nesting 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?

States a specific verb (check) and resource (whether a Base mainnet address is a contract), and names the underlying RPC method eth_getCode. It is clearly separable from siblings like base_nonce, base_block, or base_tx, though it never explicitly routes the agent away from any alternative.

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

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

Usage is only implied: an agent infers it should call this when it needs to know if an address is a contract vs an EOA. There is no explicit when-to-use statement, no prerequisites, and no mention of when another base_* tool would be the better choice.

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

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

With no annotations, the description carries the full burden. It usefully discloses the returned fields and flags that owner() is 'best-effort', which is a real behavioral caveat, but it says nothing about read-only nature, permissions, rate limits, or how a non-contract address is handled.

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?

A single front-loaded sentence that wastes no words; the resource is named first and the reported fields follow. The dense comma-separated list is efficient, though slightly crammed.

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 does the minimum viable job by naming the return fields. It still omits error/edge-case behavior (non-contract addresses) and the boundary with sibling tools, so it is adequate but incomplete.

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

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

Schema coverage is 0% and the single nested 'address' parameter has no schema description. The phrase 'on Base mainnet' implies the address must be a Base address, but no format, checksum, or example guidance is added beyond that inference.

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

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

States a specific verb+resource ('Contract introspection on Base mainnet') and enumerates exactly what it reports: contract status, bytecode size, owner(), and proxy detection. However, it does not distinguish itself from close siblings like base_proxy and base_code, which cover overlapping ground.

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

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

There is no explicit guidance on when to use this tool versus base_proxy or base_code, nor any stated prerequisites. Usage is only implied by the resource name, leaving the agent to infer the boundary with 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose the underlying view-call signature balanceOf(address,uint256), implying a read-only operation, and pins the network to Base mainnet. However, it says nothing about failure modes, address formatting expectations, or what happens for unknown tokens/ids.

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?

A single front-loaded sentence with zero filler. Every clause (ERC1155 standard, wallet+token id, Base mainnet, balanceOf signature) contributes useful information without padding.

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

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

For a read tool with no annotations, no output schema, a nested payload object, and 0% parameter coverage, the description is too thin. It leaves the return type (raw uint256 balance vs formatted value), the undocumented 'token' field, and error behavior entirely unexplained.

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

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

Schema description coverage is 0%, so the description must compensate, yet it only names 'wallet and token id' and omits the 'token' contract-address parameter entirely. It adds no format details (checksummed address, hex token id) beyond the schema's bare titles.

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

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

States a specific verb+resource: retrieves an ERC1155 multi-token balance for a given wallet and token id on Base mainnet. The ERC1155 standard inherently distinguishes it from siblings base_erc20-balance and base_erc721-tokens, though it never names those alternatives. The balanceOf(address,uint256) reference anchors the purpose to the exact on-chain 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?

There is no when-to-use guidance, no exclusions, and no mention of the sibling balance tools it competes with (base_erc20-balance, base_erc721-tokens, base_live-balance). The agent must infer selection purely from the standard name in the tool title.

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

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

With no annotations, the description carries the full burden. It usefully discloses the mechanism (balanceOf() + decimals() batched via Multicall3) and thereby hints at the return shape, but says nothing about permissions, error/revert behavior on non-contract addresses, or rate limits.

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?

A single compact sentence with the resource and scope front-loaded and no filler. Every clause 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 and no annotations, so the description should do more. It partially compensates by naming the underlying calls, letting the agent infer a balance+decimals return, but leaves parameter formats and failure behavior unspecified.

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

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

Schema description coverage is 0% and the nested payload fields 'token' and 'wallet' have no titles or descriptions. The description loosely implies a wallet and token are needed but gives no format guidance (address vs symbol, checksumming), so it fails to compensate for the coverage gap.

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

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

States a specific verb+resource ('ERC20 token balance for a wallet') and scopes it to 'Base mainnet', which separates it from generic siblings like wallet_balance or base_live-balance. It stops short of naming which sibling to use for what, but the resource 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?

No when-to-use or when-not-to-use guidance, and no mention of alternatives such as base_live-balance, base_allowance, or base_erc20-transfers. The agent must infer from the name that this is the balance-read path.

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

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

With no annotations, the description carries the full burden. It usefully discloses the hard 2,000-block limit, the single-token scope, and the underlying eth_getLogs mechanism, which are meaningful behavioral traits. However it does not state read-only semantics, pagination, or result handling, so the disclosure is partial.

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 front-loaded sentence with no waste, leading with the resource and scope before the constraint. Efficient and well-structured, though it could carry a bit more without becoming bloated.

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 and no annotations exist, so the description must cover return behavior, and it does not explain the shape of the emitted Transfer logs. It adequately covers scope and the block limit, but is incomplete for a log-retrieval tool with an undocumented nested input.

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 clarifies that 'token' is a single token and that from_block/to_block define a range (bounded to 2,000 blocks), but it omits the token's expected format (address vs symbol) and any block-number conventions, leaving gaps for the nested 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+resource ('ERC20 Transfer event logs for one token') with precise scope ('Base mainnet block range'), which separates it from the general base_events and from balance tools like base_erc20-balance. It does not explicitly name a sibling to route against, so it falls short of a 5.

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

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

There is no explicit when-to-use or when-not-to-use guidance, nor any named alternative (e.g., base_events for non-ERC20 logs). The 2,000-block cap is an operational constraint rather than usage direction, leaving the agent to infer when this tool is the right pick.

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

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

With no annotations, the description carries the full burden. It does disclose two real behavioral traits: a hard cap of 20 tokens (implying truncation) and a hard dependency on ERC721Enumerable support. It does not say what happens when that interface is absent, whether results can be paginated past 20, or anything about auth/rate limits.

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?

A single dense sentence with the scope front-loaded and the important constraints trailing it. The parenthetical ERC721 jargon is slightly heavy but every clause carries 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?

There is no output schema, no annotations, and zero parameter coverage, so the description should do more. It explains the return shape (owned token IDs, capped at 20) but omits failure behavior and parameter formats, leaving an agent with real unknowns for a query 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 description coverage is 0% and the nested token/wallet fields are undocumented, so the description must compensate. It does map 'wallet' and 'collection', but leaves 'token' ambiguous (contract address vs. token ID) and gives no format or address expectations, so it only partially fills the gap.

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

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

The description gives a specific verb+resource: it returns a wallet's owned token IDs within a single Base ERC721 collection. It also names the underlying mechanism (tokenOfOwnerByIndex / ERC721Enumerable), which cleanly separates it from siblings like base_nft-owner (reverse lookup) and base_erc1155-balance.

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

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

It states one useful precondition ('requires the collection to implement Enumerable'), which tells the agent when the call is valid. However, it never names an alternative tool or explains when to prefer this over base_nft-owner, base_erc1155-balance, or base_nft-metadata, so usage is only implied.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the non-broadcast, read-only nature and the underlying RPC method, which is genuinely valuable. But it omits auth requirements, failure/revert behavior, and how the estimate is returned, so it is only partially complete.

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?

A single front-loaded sentence stating purpose, method, and the no-broadcast guarantee with no wasted words. Efficient, though it could have used a second short sentence for the parameter/value details it currently lacks.

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

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

For a one-parameter read tool with no annotations and no output schema, the description covers purpose and the key non-broadcast behavior but leaves parameters and return/troubleshooting semantics thin. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate, yet it only echoes the field names (to/from/value/data) that already appear as schema properties. It adds no format or semantic detail — e.g. that data is calldata hex or value_wei is in wei — leaving the nested payload underspecified.

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

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

States a specific verb+resource (gas estimate) and scope: Base mainnet swaps or any call, via eth_estimateGas. Clearly says it does not broadcast. It doesn't explicitly name siblings like base_simulate or base_call, so it stops short of a 5, 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?

Implies when to use it (when you want a gas estimate without sending a transaction), which is useful context. However it never names the alternative tools (base_simulate, base_call, base_pending) or states when-not to use it, leaving the agent to infer the boundaries.

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 does reasonably well: it discloses real constraints (max 4 topics, max 2,000 blocks per query) and the shape of the returned raw logs (topics, data, block, tx hash). It stops short of stating auth requirements, rate limits, or error/empty-result behavior, so it is not a 5.

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 dense sentence, front-loaded with the resource and method, with no filler. It is a run-on list but every clause (method, filters, limits, return shape) 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?

For a nested-payload tool with no annotations and no output schema, the description supplies the missing return-shape and the query-size limits, so an agent knows what it will get back and what it can ask for. The remaining gap is parameter-level detail (requiredness, address format) that neither schema nor description covers.

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

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

Schema description coverage is 0%, so the description must compensate; it explains address filtering, topic count, and the block-range cap, which maps to the nested payload fields. However it never states that from_block/to_block are required block numbers, that address and topics are optional/nullable, or the OR-semantics of topic positions.

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 resource (smart contract event logs on Base mainnet) and the underlying method (eth_getLogs), which cleanly separates it from sibling read tools like base_receipt, base_tx, or base_call. 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?

Usage is implied by the verb and resource, but there is no explicit when-to-use / when-not-to-use guidance and no named alternative among the many base_* and log-oriented siblings. It filters by address and topics, but the definition never says to prefer it over, say, base_receipt for a single tx.

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 disclose a real behavioral trait: a single Multicall3 round trip regardless of token count, which tells the agent this is batched and cheap. However it omits what happens when the tokens list is omitted, error behavior, and any auth/rate-limit 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?

A single front-loaded sentence stating the return payload first and the efficiency guarantee second, with no filler. Every clause 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 and no annotations, so the description should say more. It states what is returned conceptually but not the response shape, and it is silent on the optional tokens parameter's default and on error/edge behavior for a nested-object input.

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%, so the description must compensate. It maps 'one wallet' to the wallet field and 'up to 20 ERC20 token balances' to the tokens array, which partially covers both params, but it adds no address format, token-address format, or default behavior when tokens is omitted.

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: 'Native ETH balance plus up to 20 ERC20 token balances for one wallet on Base mainnet.' The batching capability implicitly distinguishes it from single-token siblings like base_erc20-balance, though no sibling is named explicitly, keeping it 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?

There is no when-to-use guidance, no prerequisites, and no alternatives named. The 'for one wallet on Base mainnet' phrase is scope, not usage guidance, so the agent gets no help choosing between this and base_erc20-balance or wallet_balance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It clearly discloses the read-only informational nature and the returned fields, but says nothing about data freshness (gas price and block height are volatile), caching, rate limits, or whether any authentication/network is required.

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?

A single front-loaded sentence that names the resource, the scope restriction (mainnet), and the three return values with their units. Every clause earns its place 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?

With no output schema, the description does the right thing by enumerating return values and units (wei and gwei). It is nearly complete for a zero-arg read tool; the only gaps are freshness/liveness of the returned data and confirmation that no input is needed.

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%, but the sole parameter is an empty wrapper object with no properties, so there is effectively no parameter semantics to convey. Nothing is lost by the description omitting it, though it could state plainly that no input is required.

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 resource (Base mainnet network info) and enumerates exactly what it returns: chain ID, block height, and gas price in wei and gwei. The phrase 'in one call' signals it aggregates what siblings like base_chain-id, base_block-number, and gas_price expose individually, though it does not name those siblings explicitly.

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

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

'In one call' implies the tool is for when you need all three values at once rather than making separate calls, which is useful implied guidance. However, there is no explicit when-to-use, when-not-to-use, or named alternative, so the agent must infer that individual sibling tools exist for single-value needs.

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 supplied, so the description carries the full burden, and it does disclose the key behavioral trait: the return is an on-chain pointer (IPFS/HTTP/data URI), not the document. It stops short of stating read-only nature, error behavior for nonexistent tokens, or non-ERC721 inputs.

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 front-loaded sentence that identifies the resource, the network, the mechanism and the crucial caveat with zero 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?

There is no output schema and no annotations, and the nested parameters are undocumented, so the description should carry more weight than it does. It covers what is returned well but leaves parameter meaning and failure behavior to inference.

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

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

Schema description coverage is 0% and the single nested payload object (token, token_id) is undocumented. The description mentions 'ERC721 token' and 'tokenURI' but never clarifies that 'token' is the contract address versus 'token_id' the integer identifier, so it fails to compensate for the coverage gap.

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

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

States a specific verb+resource: the NFT metadata URI for an ERC721 token on Base mainnet, retrieved via tokenURI. The scope qualifiers (ERC721, Base mainnet) separate it cleanly from base_erc1155-balance, base_erc721-tokens and base_nft-owner without opening any 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?

Gives a clear context for use and an explicit exclusion ('not a fetch of the document itself'), which prevents the agent from expecting resolved JSON metadata. It does not, however, name a sibling alternative to use when the agent actually wants the fetched document content.

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

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

With no annotations, the description carries the full burden. It does disclose the chain (Base mainnet) and the underlying call (ownerOf(tokenId)), which tells the agent this is a read against a specific ERC721 method. However it omits notable behavior such as reverting for nonexistent tokens or rate-limit considerations.

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

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

Two short sentences with the core purpose front-loaded in a question and the mechanism immediately after. No wasted text, though the rhetorical question adds little informational value.

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 annotations, no output schema, and undocumented nested parameters, so the description should do more. It never states that the return is an owner address (or how a zero/invalid result appears), which is essential for interpreting the 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?

Schema coverage is 0% and the input is a nested object with two undocumented fields. The description clarifies token_id via 'ownerOf(tokenId)' but says nothing about the required 'token' field (the contract address), leaving half the payload semantics unstated.

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 ('ERC721 owner lookup', 'ownerOf(tokenId)') on a named chain (Base mainnet), which is more precise than the bare tool name. It doesn't explicitly contrast itself with close siblings like base_nft-metadata or base_erc721-tokens, but the ownerOf framing makes the intent distinguishable.

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

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

No statement of when to use this versus alternatives such as base_nft-metadata (token metadata) or base_erc721-tokens (tokens held by an address). Usage is only inferable from the one-line purpose.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the backing method (eth_getTransactionCount) and the meaning of the value, but omits the critical nonce nuance — whether the count is taken at latest or pending, which changes the result when unconfirmed transactions exist — and says nothing about failure modes or network assumptions.

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 resource front-loaded and a useful clarifying gloss after the dash. Slightly dense, but nothing is wasted.

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

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

For a one-parameter read tool with no output schema this is close to adequate — it says what the value is and where it comes from. The missing latest-vs-pending semantics and the undocumented nested payload keep it from being 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% and the single parameter is a nested object (payload.address) that the description never mentions structurally. 'For any Base mainnet wallet' loosely implies the address is the input, but the required wrapper object and its address field are undocumented.

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

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

States a specific resource (next transaction nonce) and scope (any Base mainnet wallet), plus the underlying RPC call eth_getTransactionCount, so an agent can tell it apart from siblings like base_tx, base_block, and base_pending without opening the schema. It does not explicitly name a sibling it is not, which keeps it 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?

No when-to-use or when-not-to-use guidance, and no alternatives named. The purpose implies you call it before submitting a transaction, but that is left entirely to inference.

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

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

No annotations are provided, so the description bears full behavioral burden. It notes the block is unconfirmed, which is useful, but does not disclose return volatility, timing dependence, or that the payload takes no fields. For a tool wrapping a chain call with zero annotation coverage, this is thin.

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?

Single efficient sentence that front-loads the resource and appends the underlying RPC identifier. No redundancy, though it packs two ideas (pending state + RPC call) without much elaboration.

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 minimal zero-parameter read tool, the description covers what it fetches and that it is unconfirmed. However, with no annotations and no output schema, it does not describe the shape or liveness of the returned block, leaving a gap for an agent relying solely on the definition.

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

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

Schema coverage is 0% and the single 'payload' object has no properties, so the description and schema together give the caller no parameter guidance. The description mentions no arguments, leaving the empty payload undocumented.

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

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

States a specific verb+resource: 'current pending Base mainnet block'. It also identifies the underlying RPC call (eth_getBlockByNumber('pending')), which disambiguates it from the sibling base_block (mined blocks). Clear, though it could more explicitly contrast with base_block.

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 parenthetical '(mempool, not yet mined)' implies when this is relevant versus base_block, but there is no explicit when-to-use or when-not-to-use guidance, and no alternative is named.

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

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

With no annotations, the description carries the full behavioral burden. It helpfully discloses the output (implementation address) even though no output schema exists, and 'detection' implies a read-only probe, but it never states what is returned for a non-proxy contract, whether the address must be checksummed, or any rate-limit/auth characteristics.

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

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

Two tight sentences, front-loaded with the core question, then the supporting detail (patterns and return value). Every clause earns its place with no filler.

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

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

For a read-only detection tool with no annotations and no output schema, the description covers the essential pieces: what it detects, which standards, and what it returns. Minor gaps remain around non-proxy return behavior and input format expectations.

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

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

Schema description coverage is 0% and there is one nested object parameter, so the description must compensate. Mentioning 'Base contract' implies the nested address is the contract to inspect, but it adds no format, validation, or network-scoping detail beyond what the schema shape already conveys.

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 (detect/check) and resource (Base contract proxy), plus the exact patterns it recognizes (EIP-1967 transparent/UUPS, beacon, EIP-1822) and the return value. This clearly separates it from generic siblings like base_contract or base_code, though it never names or contrasts with those siblings explicitly.

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

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

Framing it as a yes/no question ('Is this Base contract an upgradeable proxy?') implies the use case of checking a contract before interacting with it, but there is no explicit when-to-use guidance, no stated alternatives (e.g. base_code/base_storage), and no exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the full burden, and it does convey that the call is an on-chain read via Multicall3 returning estimates rather than executing swaps. However, it does not state that it is side-effect-free, does not mention rate limits, and gives no indication of failure behavior or stale-price handling.

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?

A single dense sentence front-loads the purpose, then adds the comparison mechanism and return shape. It is efficiently sized, though the trailing clause is a run-on and slightly harder to parse than it needs to be.

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 helpfully names what is returned (amount received, chosen path, price impact), covering the return side. But it leaves input semantics (token format, amount units) entirely unaddressed, which is a meaningful gap for a quote tool with a nested payload.

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

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

Schema description coverage is 0% and the single payload object nests three required fields (token_in, token_out, amount_in) with no explanation in either schema or description. The description adds nothing about expected token format (address vs symbol) or the units/decimals of amount_in, which is critical for a quote tool.

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 action set ('slippage estimate, swap quote, and best DEX price on Base') and enumerates the venues compared (Uniswap v2, v3, Aerodrome). This clearly distinguishes it from siblings like base_allowance, token_risk, or gas_price, so an agent can identify it 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 comparison behavior implies when the tool is useful (obtaining a best-price quote across DEXes), but there is no explicit when-to-use vs when-not, no mention of prerequisites, 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?

With no annotations, the description carries the full behavioral burden. It usefully enumerates the returned data (status, gas used, event logs) and implies a read-only RPC lookup, but says nothing about behavior for unmined/unknown hashes, error handling, rate limits, or auth requirements.

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?

A single front-loaded sentence that names the resource, the RPC method, and the returned fields with no filler. Every clause 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?

There is no output schema and no annotations, so the description is the only source of truth. It lists the receipt contents, which helps, but omits the nested 'payload' input shape and the failure mode for unmined or unknown transactions, leaving gaps for a tool whose structured fields are silent.

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

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

Schema coverage is 0% and the single parameter is a nested payload.hash object, so the schema alone does not explain it. The description compensates partially by naming eth_getTransactionReceipt, which tells the agent the hash is a transaction hash, but it never mentions the 'payload' wrapper or confirms the hash format.

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

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

Names a specific verb+resource ('Transaction receipt'), the underlying RPC call (eth_getTransactionReceipt), and the chain scope (Base mainnet), so it is clearly distinguishable from siblings like base_tx or base_block. It stops short of explicitly contrasting itself with base_tx, but the receipt-vs-transaction distinction is implicit in the wording.

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 a mined Base mainnet transaction' gives an implicit precondition (the transaction must already be mined, so pending txs will not yield a receipt), but there is no explicit when-to-use, when-not-to-use, or named alternative such as base_tx for pending transactions.

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

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

With no annotations, the description carries the full burden. It does disclose that the tool is a dry-run ('before sending it') and what it returns, which is valuable, but says nothing about permissions, rate limits, or the fact that no state is mutated beyond the implicit 'simulate' framing.

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?

A single front-loaded sentence covering purpose and outputs with no filler. Slightly run-on, but every clause adds 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?

Because no output schema exists, the description appropriately enumerates return values (success, estimated gas, decoded revert reason). It is nonetheless incomplete on the parameter side, leaving the nested payload object entirely undocumented for a simulation 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 description coverage is 0% for the nested payload (from_address, to, data, value_wei) and the description adds no parameter meaning whatsoever. Field names are self-explanatory but a nested value_wei/data/from_address object deserves at least format clarification and none is given.

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 ('Simulate') and resource ('a Base mainnet transaction') and even enumerates the result categories (success, gas, revert reason). It clearly differs from base_call/base_estimate-gas in intent, though it never explicitly names those 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?

'before sending it' gives a clear temporal context that implies when to use the tool (pre-flight check). However, there is no explicit guidance on when-not to use it or which sibling (e.g. base_estimate-gas, base_call) to prefer.

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

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

With no annotations, the description carries the full behavioral burden. It helpfully discloses the RPC method and the decoded return format (hex, unsigned integer, zero-filled if unset), but it does not address permissions, rate limits, error behavior, or other operational traits.

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 front-loaded sentence with no wasted words. It states the action, network, method, and return encoding efficiently.

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

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

For a simple read-only RPC wrapper with no output schema, the description does explain the return shape. However, it leaves address and slot semantics entirely to the sparse schema, so the definition is only minimally complete for invocation.

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

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

Schema description coverage is 0%, and the nested address and slot properties have no descriptions. The description does not explain what address or slot represent, what format they expect, or how they map to the payload object.

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

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

The description gives a specific verb (Read) and resource (contract storage slot on Base mainnet), and names the underlying RPC method eth_getStorageAt. It clearly distinguishes this tool from sibling chain tools like base_call, base_code, and base_block.

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 the tool is for reading a storage slot, but it never states when to choose it over alternatives such as base_call or base_contract. There are no conditions, exclusions, or prerequisites to guide tool selection.

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 disclose one genuinely useful behavioral trait: ERC20 values are normalized by decimals() while ERC721 returns a raw count. However, it says nothing about read-only nature, error behavior for non-ERC20/721 or non-existent tokens, or chain-access semantics.

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?

A single front-loaded sentence with zero wasted words. The entity, chain, and both standard-specific behaviors are packed efficiently 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?

No output schema exists and no annotations are present, so the description must stand alone. It covers the return-value semantics well for both standards, but leaves the required 'token' parameter's format undefined, which is a material gap for actually 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 description coverage is 0% and the single nested 'token' parameter is undocumented. The description hints it expects a contract via the word 'contract', but never clarifies whether 'token' is a hex address or symbol, nor its format, so it fails to compensate for the coverage gap.

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

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

The description states a specific resource (total supply) scoped to Base mainnet and to ERC20/ERC721 contracts, and even distinguishes the two standards' return semantics. It is clearly separable from balance/allowance siblings by resource, but it never names an alternative tool 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: an agent infers it should call this when it needs total supply of a token contract. There is no explicit when-to-use statement, no prerequisites, and no mention of when a sibling like base_erc20-balance or base_call would be the better choice.

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

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

With no annotations, the description carries the full burden. It usefully discloses the backing method (eth_getTransactionByHash) and that data is 'live from Base mainnet', which tells the agent this is a fresh read rather than cached. However, it says nothing about behavior for an unknown hash, hash format expectations, or rate limits.

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?

A single dense sentence with the resource and lookup key front-loaded, followed by the returned fields and the data source. No filler and nothing 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?

For a one-parameter read tool with no output schema and no annotations, the description compensates well by listing the returned fields and naming the data source. The remaining gap is error/not-found behavior and the hash format contract, which are minor for a simple lookup.

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

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

Schema description coverage is 0% and the single nested 'hash' property is undocumented in the schema. The description's 'by hash' clarifies that the argument is a transaction hash (not a block hash or address), which adds real meaning, but it does not specify the expected hex format or length.

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 ('Base transaction lookup by hash') and enumerates exactly what it returns (sender, recipient, value, calldata, gas, block). This clearly separates it from siblings like base_receipt, base_block, and base_call without needing to open a schema.

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

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

Usage is implied by 'lookup by hash' - the agent can infer it needs a transaction hash - but there is no explicit when-to-use guidance, no mention of the alternative base_receipt for status/logs, and no stated prerequisites or failure conditions.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered structurally. The description adds the Base-mainnet scoping and the default $0.001 amount, but reveals nothing about rate limits, failure modes, or how shortfall is computed.

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 with the core purpose front-loaded and no wasted clauses. The trailing sample-endpoint pointer is marginally useful but slightly off-topic for a parameter-level description.

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

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

With an output schema present, the description needn't enumerate returns, and it still names the key fields (balance, can_pay, shortfall). Annotations cover the safety profile, so almost everything an agent needs is present, though it omits any note about chain scope limits or error responses.

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% for both parameters, including the 0.001 default, so the description's mention of the default simply repeats the schema. Baseline 3 is appropriate since 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?

States a specific verb+resource ('Check whether a Base wallet holds enough USDC to pay an x402 amount') and names the decision it feeds (can_pay/shortfall). It is clearly distinguishable from the sibling wallet_balance, which reports holdings rather than a spendability verdict.

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 checklist agents run before spending' gives a clear usage context (pre-transaction preflight). It does not name an explicit alternative or a when-not-to-use condition, so it falls 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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds genuinely external-behavioral context: the Jev primary backend with a Groq-hosted LLM fallback and a hard 'under 4.5s guaranteed' latency bound, which materially affects how an agent schedules and retries 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?

Front-loaded and dense: capability, label count, output shape, and reliability all land in the first two clauses with no filler. The trailing 'Try GET /classify/sample' is a useful discovery pointer, though the dash-chained structure makes it slightly harder to scan than separate sentences.

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

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

An output schema exists and the description still names the return fields (confidence, alternate label), which is a bonus rather than a redundancy. Safety hints and latency are covered, so the only omission is failure behavior for oversized text or unavailable backends, which is minor for a two-param read-only 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 description coverage is 100%, so both parameters are fully documented in the schema (text up to 4000 chars, 2-20 labels). The description restates the 2-20 label bound and adds no syntax, escaping, or label-selection guidance beyond it, so the baseline 3 applies.

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

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

States a specific verb+resource ('text classification') and is unusually precise about mechanics: custom labels (2-20), confidence score, alternate label, and a latency/fallback story. However it never positions itself against obvious siblings like sentiment, intent, spam_check, or toxicity, so an agent must infer the distinction from the phrase 'your own custom labels' alone.

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

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

Gives concrete use-case examples ('a support ticket, a review, or any text') which implies when the tool fits, but offers no explicit when-not and never names an alternative. For a cluster containing sentiment, intent, spam_check, and toxicity, the absence of routing guidance between fixed-label and custom-label classifiers is a real gap.

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 behavioral disclosure burden. It reveals the asynchronous nature (message id + poll URL returned, answer comes later), states it is free with no payment, and indicates the declare fields are optional. It does not mention side effects, retention, or authentication, but covers the most important behavioral traits for a contact tool.

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

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

A single dense sentence carries the action, the optional feature, the free/payment reassurance, and the follow-up routing. Every clause adds value and there is no redundant or filler text.

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

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

The description includes enough for an agent to send a message, understand the async workflow, and know how to poll for the answer. The return values are mentioned, which is useful even though an output schema exists. It lacks deeper explanation of declare semantics (e.g., expected format of skills/endpoint), but that is a minor gap given the tool's simplicity and the presence of an output schema.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for the declare parameters (what_i_do, endpoint, skills map to declares_what_i_do, declares_endpoint, declares_skills) but does not explain sender, subject, body, or reply_to. The required fields are somewhat self-explanatory by name, but the description only partially compensates for the zero-coverage 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?

States a specific verb ('Write') and resource ('Kairos'), and clarifies the optional 'DECLARE yourself' feature. It distinguishes itself from the sibling poll_contact_kairos by explicitly naming it as the follow-up for retrieving the answer, so an agent can tell write from poll without opening 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?

The description implicitly frames the usage: use this tool to send a message, then use poll_contact_kairos or GET /contact/{id} for the response. It provides clear workflow context but does not explicitly state when to avoid this tool or compare it with other contact mechanisms.

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 only says 'free' (ambiguous) and the purpose, but does not state that the tool is read-only, has no side effects, or any limitations. Given it simply returns a schema, the agent can infer safety, but that's not explicitly 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 two short sentences, the first front-loading the primary action and target, the second providing context about what the schema represents. No extraneous words or repetition.

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

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

For a simple getter tool with no parameters and an existing output schema, the description is essentially complete. It tells the agent what it returns and for what purpose. The only minor gap is not explaining what a coordination thread turn is, but that is expected knowledge in the domain.

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 has zero parameters, so the baseline is 4. The description doesn't need to add parameter semantics since there are none. The empty input schema with additionalProperties false is already clear.

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 the tool returns a JSON Schema for coordination thread turns, and adds context that it represents a structured turn in a multi-agent conversation. It distinguishes from other schema-returning tools by specifying the target schema, though it doesn't explicitly name sibling 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 description implies usage: you call this to get the schema for coordination thread turns. However, there's no explicit guidance on when to use it versus related tools like validate_coordination_thread_turn or when not to use it. The context of siblings suggests it serves as the schema source, but that's not 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 the burden for behavioral disclosure. It does state that the tool returns a schema and is free, and it lists the bundle contents, but it does not explicitly state that the call is side-effect-free or describe any other operational constraints.

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 one compact sentence that front-loads the main action and then packs the relevant scope ('turns, cards and open pledges', 'handoff between runs') into a short clause. The only slightly odd element is the telegraphic '— free', which is brief but not wasteful.

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

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

For a parameterless schema-fetch tool with an output schema present, the description covers the main use case and the content of the schema. It does not need to explain return values, though it could have noted the relationship to the sibling coordination_thread_schema.

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

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

There are zero parameters and the schema coverage is 100%, so parameter documentation is unnecessary. The description adds no parameter-related information, but none is needed; this matches the baseline for a parameterless tool.

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 operation and resource: 'Return the JSON Schema for coordination thread snapshots (v1)' and clarifies the snapshot contents ('turns, cards and open pledges'). It does not explicitly distinguish itself from the closely named sibling coordination_thread_schema, 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?

The phrase 'for handoff between runs' gives a clear intended context, and 'free' adds a cost signal. However, there is no explicit when-to-use/when-not-to-use guidance or mention of any alternative 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds that prices are live and include 24h change, which is useful output context, but it says nothing about rate limits, error behavior for unknown tickers, or partial-failure handling for a multi-coin request.

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

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

Two tight sentences with no filler, and the core capability (live spot prices + 24h change) is front-loaded before the accepted identifier forms and the sample hint.

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

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

An output schema exists, so return-value documentation is unnecessary, and the annotations cover safety. The description covers what is queried and in what currencies; only failure modes and the multi-coin limit (which the schema handles) are left implicit, so it is nearly complete for this simple 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 description coverage is 100%: the schema documents both coins (tickers/CoinGecko ids, formats, up-to-20 cap) and vs_currency (default usd, other fiats). The description's 'Accepts tickers or CoinGecko ids' and 'USD or another fiat' merely restate the schema, so the baseline of 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?

The description names a specific resource and verb-equivalent ('Live spot prices for crypto coins ... in USD or another fiat, with 24h change'), making the tool's output scope unambiguous. It does not explicitly distinguish itself from the nearby gas_price sibling, but the resource (coin spot prices) is distinct enough that confusion is unlikely.

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?

'Try GET /crypto/sample' hints at how to explore the endpoint, and the coin/currency framing implies the usage context. However, there is no explicit when-to-use vs when-not guidance and no named alternative (e.g., gas_price) is referenced, leaving the agent to infer selection.

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, idempotentHint and openWorldHint=false, and the description adds meaningful context beyond them: $0.001 per call, no account/OpenRouter required, a 20-question batch cap, and the fact that answers are calibrated probabilities rather than generated text. Error behavior and rate limits are still unstated.

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 front-loaded sentences that establish scope, cost and a sample endpoint with little waste. The marketing parenthetical 'Powered by Jev (TypeSafe System One)' and the sample-endpoint plug are the only soft spots.

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

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

With an output schema present, return values need no explanation, and the description covers the key operational facts: state token cap, question cap, question types and where to find criteria shapes. The only gap is guidance on when to prefer this over a sibling 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%, so the baseline is 3, but the description adds real meaning by mapping the three abstract type tokens ('noul', 'choice', 'score') to yes/no, multiple-choice and ordinal-scale questions, and by clarifying that all questions share one state and that criteria shapes live in /decide/sample.

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 (ask typed questions), resource (one shared piece of context), and the distinctive output (real probabilities, not generated text). It is clearly distinguishable from sibling text-generation or lookup tools like summarize or fact_check without opening any 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?

Usage is implied — batch multiple probability judgments over a single context in one call — and the 'not generated text' phrasing implicitly contrasts with LLM-based siblings. But it names no alternative and gives no explicit when-to-use or when-not-to-use conditions.

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

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

With no annotations, the description bears the behavioral transparency burden. It adds the cost-related trait 'free, no payment,' which is useful, but it does not disclose whether the tool is read-only, how it handles ambiguous or empty input, or what form the result takes. The 'kit's entry point' phrase adds little concrete behavior.

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

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

The first sentence is appropriately concise, but the second sentence is off-topic, grammatically awkward, and does not earn its place. It confuses rather than clarifies, and it does not support tool selection or invocation.

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 detection tool with an output schema, the description covers the basic input and free access. However, the misleading sibling sentence and lack of clarity about what counts as 'same kind of work' leave the context incomplete for an agent choosing among 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?

The schema provides only 'text' as a string with 0% coverage, so the description must compensate. 'Detect the language of a piece of text' does clarify that the text parameter is the content whose language should be detected, but it adds no constraints, examples, or edge-case guidance.

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

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

The first sentence, 'Detect the language of a piece of text,' clearly states the verb, resource, and scope. However, the second sentence muddies sibling differentiation by claiming read_pdf, read_web_page, extract_structured, and summarize do 'the same kind of work,' which is inaccurate and confusing.

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 mentions that this tool is free and that other tools are paid, but it never states when to use this tool versus its siblings. There is no explicit condition, task context, or when-not-to-use guidance, so an agent gets no actionable routing.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the digest is stable, uses SHA-256, and requires no account or payment. It does not mention whether content is canonicalized before hashing, whether tool_use_id is included in the digest, or any size or rate limits, but for a simple utility the core behavior is at least surfaced.

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 compact sentence that front-loads what the tool does and adds a brief value proposition. There is no filler, and every phrase contributes either to the tool's function or its access characteristics.

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

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

The tool is simple and has an output schema, so the return shape does not need to be described. However, with no annotations and no parameter descriptions, an agent may still be uncertain about how tool_name, content, and tool_use_id are used. The use case is clear, but the definition is not fully self-sufficient for correct invocation.

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

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

Schema description coverage is 0%, and the description provides almost no parameter-level meaning. The mention of 'MCP tool_result' hints that 'content' is the payload being hashed, but tool_name and tool_use_id are not explained at all. The description does not compensate for the schema's lack of field documentation.

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 tool's function: producing a stable SHA-256 digest of an MCP tool_result for payload verification before payment. The resource and operation are specific enough to distinguish it from generic hashing tools. However, it does not explicitly name or contrast itself with the sibling verify_tool_result_digest, leaving some differentiation to inference.

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

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

The description implies the intended use case: agents verify payloads before settling payment. The 'free, no account' note adds an access-related condition. But it never states when not to use this tool or how it relates to verify_tool_result_digest, so an agent must infer the division of labor between producing and verifying a digest.

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 of behavioral disclosure, and it does so well: it explains the ranking mechanism, the curated snapshot source, precomputed embeddings, the one embedding call per query, and the exact output fields including the relevant score. It also addresses cost/auth expectations by stating free/no account/no payment.

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 two tight, information-dense sentences. Purpose and constraints are front-loaded, and later details (embedding mechanism, returned fields) are relevant and non-redundant. Every clause 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?

The description gives a strong overview of what the tool returns and how ranking works, and an output schema exists to document return structure. The main gap is the unexplained 'max_results' parameter and the lack of explicit exclusions or alternative routing, though the simple parameter set and default value reduce the risk.

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 has 0% description coverage, so the description must compensate, but it only partially does. 'Matching a need' implies the meaning of 'q', yet 'max_results' is never explained; an agent must infer that it caps the number of returned matches. The description focuses on output fields rather than parameter behavior.

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 ('Discover') and resource ('MCP servers'), and further clarifies the scope: matching a need, ranked by semantic similarity over a curated snapshot. This clearly distinguishes it from sibling tools like discover_semantic, which appears to be generic semantic discovery.

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 states the intended use case ('matching a need') and adds practical context: free, no account, no payment, and precomputed embeddings with one embedding call per query. However, it does not explicitly mention when not to use this tool or how it compares to a sibling alternative like discover_semantic.

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 does add meaningful behavior: it is a paid POST, it caps results at 25, it validates against a curated snapshot, and it describes returned fields including a 0-1 relevance score. Missing auth/permission requirements and rate-limit behavior keeps it short of a 5.

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 packed sentences with no filler; the core purpose and return shape lead. The trailing 'Try GET /discover/sample' is a slightly abrupt tack-on but still earns its place as a low-cost alternative.

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?

It compensates for the absent output schema by enumerating returned fields, which is genuinely useful. But with zero annotation coverage and zero parameter coverage, the definition leaves the caller without auth/cost detail and without parameter semantics, which is more than a minor gap for a paid 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 0% for all three parameters, yet the description explains none of them. 'q' (the query format), 'max_results' (and its interaction with the stated 25-match cap), and especially 'min_similarity' (the 0-1 threshold) are left entirely undocumented, so the description fails to compensate for the coverage gap.

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

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

States a specific verb and resource ('Find MCP servers matching a need') plus the ranking mechanism (semantic similarity over a curated snapshot). Clear on its own, but it never distinguishes itself from the sibling discover_mcp_servers, which sounds like a near-identical capability, so an agent cannot confidently pick between them from this text.

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 cost context ('Paid POST') and a fallback ('Try GET /discover/sample'), which is real usage guidance. However it never says when to use this over discover_mcp_servers or any other search-like sibling, and there are no explicit exclusions.

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

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

With no annotations, the description carries full behavioral burden. It usefully discloses the detection method and the closed set of supported encodings, implicitly ruling out UTF-32 and statistical detection, but says nothing about error handling for non-hex input, ambiguity cases, or the response shape for a detect operation.

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?

A single tight sentence, front-loaded with the action and scope, ending with a high-value clarification. 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?

With no annotations and no output schema, the description should ideally hint at return values (e.g., the detected encoding label) and the guarantees/limits of detection. It covers the core purpose adequately but leaves the result and edge-case behavior unspecified.

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

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

The schema has 0% description coverage and the single parameter is a nested object, but the description does convey the key semantic that the input is hex-encoded bytes. It still omits the nested payload/hex_bytes structure and any format expectations (case, separators, odd-length 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?

Specific verb (Detect) plus resource (hex-encoded bytes) and an explicit scope: ASCII, UTF-8, or UTF-16-with-BOM. It further disambiguates the method ('decode-validity and BOM presence, not statistical language detection'), which cleanly separates it from generic encoding or language-detection 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?

Usage is implied by the 'not statistical language detection' aside, but no explicit when-to-use or when-not guidance is given, and the sibling it pairs with (encoding_transcode) is never named. An agent can infer intent, but nothing routes it toward or away from alternatives.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it adds nothing beyond the formats already encoded in the schema pattern. It is silent on failure modes (invalid base64/hex input, mismatched from_encoding), whether url and ascii differ in escaping behavior, and whether output is lossless.

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?

A single front-loaded sentence with no filler; the core operation and supported formats are stated immediately.

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

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

For a tool whose input is a nested object wrapper with three internal fields and no output schema, the description is too thin. It does not clarify the payload structure, the required directionality, or what happens on invalid input, leaving real gaps for correct invocation.

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

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

Schema description coverage is 0%, but the regex patterns in from_encoding/to_encoding do constrain the allowed values, and the description names those same five formats, partially compensating. It adds no meaning for the 'text' field or the from→to direction semantics, so it merely matches rather than exceeds 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?

States a specific verb ('Convert') and resource ('text') and enumerates the supported encodings, so the operation is unambiguous. However, it never distinguishes itself from the sibling encoding_detect, which an agent could easily confuse with this 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?

There is no explicit when-to-use guidance and no mention of the obvious alternative (encoding_detect for identifying an unknown encoding). Usage is only implicitly inferable from the list of formats.

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 (readOnlyHint, idempotentHint, openWorldHint), yet the description adds genuinely non-obvious behavior: unsupported fields return null rather than invented or approximate values, and an unmatchable schema produces an explicit error. Those guarantees are exactly what an agent needs to trust the output and are not derivable from 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 core behavior and its key guarantees are front-loaded in the first two clauses, and the tool-discovery pointers (sample endpoint, capabilities list) are appended rather than interleaved. It is slightly dense with promotional kit references, but every sentence carries 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 an output schema present and rich annotations, the description need not explain return values, and it still adds the error and null semantics that matter most for a schema-driven extractor. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so url, text, and schema are already fully documented in the structured fields. The description restates the url-or-raw-text choice but adds no syntax, format, or constraint detail beyond the schema. 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 opens with a specific verb+resource ('Extract structured data from a URL or raw text into strict JSON matching a schema you provide'), naming both accepted inputs and the output contract. This clearly separates it from loose-read siblings like read_web_page and read_pdf, which return content rather than schema-conformant JSON. 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?

Usage is implied rather than stated: the tool is positioned inside the 'content kit' alongside pdf, web-read, summarize, and detect-language, but the description never explicitly says when to pick this over read_web_page or summarize. The 'Provide this or text, not both' guidance lives in the schema, not the description. No exclusions or alternative-selection criteria are given.

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

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

With no annotations, the description carries the full behavioral burden but only adds the fact that a decimal value is returned. It says nothing about edge cases critical to this operation, such as a zero denominator, negative signs, or improper fractions, nor about error behavior.

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

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

A single front-loaded sentence with zero filler. Every clause earns its place by naming the operation and the return value.

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

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

For a simple math utility with no output schema, stating the return value (decimal) is helpful, but the nested, undescribed payload plus missing edge-case behavior leave notable gaps for an agent deciding how to call it.

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

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

Schema description coverage is 0% and the input is a nested payload object, so the description should compensate but does not. The field names numerator/denominator are largely self-evident, yet nothing clarifies accepted integer form, sign handling, or the wrapping payload structure.

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

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

States a specific verb+resource ('Simplify a fraction to lowest terms') and even notes the secondary output ('return its decimal value'). It is clearly distinguishable from math-adjacent siblings like number_roman or number_radix, though it never explicitly contrasts with any of them.

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

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

The description offers no when-to-use guidance, no alternatives, and no prerequisites. It simply says what the tool is, leaving the agent to infer applicability.

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, openWorldHint and idempotentHint, so the safety profile is covered. The description adds genuinely new context beyond the annotations: no RPC key or account is required, and the reading is 'live' across five named chains. It does not discuss rate limits, freshness latency, or caching behavior, so it stops short of a 5.

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 core capability front-loaded and no filler. The trailing 'Try GET /gas-price/sample' is a useful invocation hint but is slightly cryptic out of context, keeping this just below a perfect score.

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

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

An output schema exists, so return-value explanation is unnecessary, and the description covers the networks, the absence of auth requirements, and the three data points returned. It is complete enough to invoke correctly, though it omits units/currency conventions for the cost estimate and any note about update frequency.

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 defaults to Base, so the baseline is 3. The description adds meaning the schema lacks: it enumerates the valid network values (Base, Ethereum, Polygon, Arbitrum, Optimism) even though the schema declares no enum for that field, which is real compensating value.

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 ('Read the live gas price, EIP-1559 base fee and estimated native-transfer cost') and enumerates the five supported networks. It is clearly distinguishable from siblings like wallet_balance, can_pay, and crypto, which concern balances or payment decisions rather than fee data.

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

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

Usage is implied by the purpose (call this when you need fee data), and 'No RPC key or account' removes a common prerequisite question. However, there is no explicit when-to-use statement, no exclusions, and no routing to a sibling such as can_pay when the question is really about affordability.

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 states the core deterministic computation and hints at the return concept (min/max lat and lon), but it does not specify the output field names, ordering, or edge-case behavior such as antimeridian crossing.

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 front-loaded sentence with no filler. It conveys the tool's output concept immediately and does not bury the key 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 simple geo utility with one nested required parameter and no output schema, the description gives the minimum viable context: what is computed and from what input. However, it leaves the exact return shape and coordinate ordering unspecified, which matters because no output schema exists to fill that 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 description coverage is 0%, so the description must compensate for undocumented parameters. It mentions a 'list of points' and lat/lon, which aligns with the nested input, but it does not explain the required 'payload' wrapper or clarify the point object structure beyond what the schema already encodes.

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 the resource and operation: compute a bounding box from a list of points, returned as min/max latitude and longitude. It distinguishes itself from the other geo_* siblings by naming the bounding-box operation, though it does not explicitly name an alternative 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?

There is no when-to-use or when-not-to-use guidance, and no sibling alternative is mentioned. An agent can infer the purpose from the name and description, but the description provides no explicit routing information.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the output convention (0-360, clockwise from true north), but says nothing about edge cases such as identical points, antipodal inputs, or error behavior for a pure-computation tool.

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

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

A single tight sentence with the output range and convention front-loaded and zero filler. Every clause 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?

For a deterministic math tool with no annotations and no output schema, the description gives enough to call it correctly: input concept, output range, and reference frame. Only edge-case behavior is left unspecified, which is a minor gap here.

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

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

Schema coverage is 0% and the single parameter is a nested object with four numeric fields. The description implicitly maps 'point 1' and 'point 2' to the lat/lon pairs, and 'compass bearing' clarifies the units, but it does not clarify field-level ordering or coordinate format beyond that.

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

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

States a specific verb (compute bearing) and resource (compass bearing between two points) with an explicit directional convention. It is clearly distinct from geo_distance and geo_midpoint, though it does not name siblings to reinforce the contrast.

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

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

There is no guidance on when to use this tool versus geo_distance, geo_midpoint, or geo_dms, and no mention of prerequisites or exclusions. The agent must infer fitness from the description alone.

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

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

With no annotations, the description must carry the behavioral burden, and it does add the meaningful detail that distance is spherical great-circle (haversine) rather than ellipsoidal, plus the selectable output units. However it says nothing about being a pure/side-effect-free computation or the precision implications of the model, so it is partial at best.

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

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

Two tight sentences, zero waste, with the core operation and return units both front-loaded. Nothing could be trimmed without losing 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 simple pure-computation tool with no annotations and no output schema, the description conveys the operation, the algorithm, and the return units, so essentially everything needed to invoke it is present. The only minor gap is not stating the output shape (scalar number vs object).

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%, but the nested payload's lat/lon fields are self-documenting by name and range. The description does add value by enumerating the available unit outputs (km, mi, nm), matching the schema's unit pattern, but it adds no lat/lon format or ordering guidance beyond that.

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: computing great-circle distance between two lat/lon points, and identifies the algorithm (haversine). This clearly separates it from sibling geo tools like geo_bearing and geo_midpoint, though it never names those alternatives explicitly.

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

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

Usage is only implied by the tool's function — an agent can infer it is for measuring point-to-point distance, but there is no statement of when to prefer it over geo_bearing, geo_midpoint, or geo_bbox, and no prerequisites or exclusions are given.

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

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

With no annotations, the description carries the full burden and falls short. It does not disclose that the payload must contain either a 'dms' object or a 'decimal' value (and that the null side is required to be null), nor what range validation or error behavior applies. It also says nothing about the return format, though that is arguably minor for a pure conversion.

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

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

One sentence, front-loaded with the verb and both conversion directions, with 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?

The input is a required nested payload object with an anyOf union and no schema descriptions, and there is no output schema or annotation to fill the gap. A single sentence is insufficient to make this tool callable with confidence.

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

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

Schema description coverage is 0% and the single parameter is a nested object, so the description must compensate. It usefully implies the two input modes ('decimal degrees' ↔ 'DMS') which map onto the 'decimal' and 'dms' properties, but it omits the direction enum, the range constraints, the required wrapper key, and the mutual exclusivity semantics.

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 operation and both directions of conversion (decimal→DMS and DMS→decimal), which is clearer than the cryptic name 'geo_dms'. It does not distinguish itself from the other geo_* siblings, but those cover entirely different computations, so the risk of confusion is low.

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

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

There is no guidance on when to choose this tool or what preconditions apply. The description only restates the conversion, leaving the agent to infer that it is used whenever DMS formatting is needed.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the operation type and output type (geohash string, precision 1-12), but it omits edge-case behavior, validation expectations, or response details. For a simple deterministic encode, this is adequate but not rich.

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?

A single, front-loaded sentence with no filler. Every element earns its place by naming the operation, inputs, output, and precision bound.

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

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

The tool is simple and the description covers the core encode operation and output format. However, with 0% schema description coverage, no annotations, and no output schema, it could say more about valid input ranges or the exact output format to be fully self-contained.

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 lat/lon and the precision range 1-12, but the precision range is already in the schema constraints, and the nested payload structure plus lat/lon valid ranges are not further explained. Compensation for the coverage gap is only partial.

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: encode a lat/lon point into a geohash string. This is clearly distinguishable from sibling geo tools like geo_distance or geo_bbox, which calculate different geospatial properties.

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 no explicit when-to-use guidance, no conditions for selecting this tool over alternatives, and no exclusions. The purpose is implied by the verb and resource, but usage context is left entirely to inference.

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

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

No annotations are provided, so the description carries the full burden. It states what is computed but omits return format, edge cases, and any behavioral traits. For a pure calculation tool with no annotations, this is a significant gap.

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

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

The description is a single concise sentence, front-loaded with the core operation and free of filler. It is appropriately sized for a simple tool, though it could be slightly more informative without becoming verbose.

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 a nested input object, the description should at least state the return format (e.g., a lat/lon coordinate) and clarify the input structure. It does neither, leaving an agent to infer from parameter names alone. This is insufficient for confident invocation.

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

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

Schema description coverage is 0%, and the nested payload contains four numeric fields (lat1, lon1, lat2, lon2) with no descriptions. The description's phrase 'two lat/lon points' adds some conceptual mapping but does not clarify order, coordinate system, or format beyond the parameter names themselves.

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 computation: 'great-circle midpoint between two lat/lon points.' This distinguishes it from siblings like geo_distance and geo_bearing, which compute distance and bearing respectively. However, it does not explicitly name those alternatives, so sibling differentiation is implicit.

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

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

No guidance on when to use this tool versus other geo_* siblings. No context, prerequisites, or exclusions are provided. The description simply states the operation without any usage cues.

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 usefully states the algorithm (ray-casting) and the approximation model (planar, local-scale), which tells the agent about accuracy limits. It does not mention boundary handling, coordinate order expectations, polygon orientation, or the return value, leaving important behavioral details unspecified.

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 front-loaded sentence with no filler. It efficiently combines the operation and its key accuracy caveat, so every clause 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?

For a nested-input geometric predicate with no annotations and no output schema, the description gives the most important caveat: it is a planar approximation suited to local polygons. However, it does not state the return value or explain input format details, so an agent must infer those from the schema and the predicate's name. It is adequate but has clear gaps.

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

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

Schema description coverage is 0%, so the description should compensate by explaining parameter formats and constraints. The description implicitly references a point and polygon via 'point-in-polygon test', but adds no detail about the payload structure, lat/lon ordering, polygon vertex requirements, or minimum vertex count. The schema provides structural constraints only, and the description adds almost no semantic meaning beyond the operation name.

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 computation: a ray-casting point-in-polygon test. It clearly distinguishes this operation from the other geo siblings by identifying it as a containment predicate rather than a distance, bearing, or geohash tool. It stops short of explicitly naming alternatives, so a 4 is more accurate than 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?

The phrase 'fine for city/region-scale polygons' implies a scale suitability limit, which gives some when-to-use context. However, it does not say when not to use this tool or point to alternatives such as geo_bbox for bounding-box checks or a different algorithm for global-scale polygons. Usage guidance is therefore implied rather than explicit.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states what is returned but does not mention side effects, safety, read-only nature, or any operational constraints. For a 'get' tool with no parameters, this is a notable gap—agents cannot be certain it is side-effect free without additional inference.

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 front-loads the core action ('Return the agent trust kit manifest') and then lists the contents. There is no wasted text, and it is appropriately sized for a tool with no parameters. Every word adds value.

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 low complexity (no parameters) and the presence of an output schema (which likely details the return structure), the description is fully sufficient. It communicates the purpose and content clearly, leaving nothing essential missing for an agent to decide whether to call it.

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 has zero parameters, and the input schema is an empty object with 100% coverage. Since there are no parameters to describe, the baseline for 0 parameters is 4, and the description adds no unnecessary parameter details. It appropriately does not attempt to explain nonexistent parameters.

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

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

The description states a specific verb ('Return'), a clear resource ('agent trust kit manifest v1'), and enumerates its contents (JSON schemas, HTTP validators, MCP tool names, workflows). It clearly distinguishes itself from sibling tools like coordination_thread_schema or validate_* which operate on individual schemas, not a manifest of many.

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 the tool is for discovering or obtaining an overview of the agent trust kit, but it does not explicitly say when to use it versus alternatives, nor does it mention when not to use it. An agent can infer it is the entry point for the kit, but no explicit routing to specific schema tools 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?

With no annotations, the description carries the behavioral burden. It states 'same JSON as GET /accueil,' which communicates a read-only, GET-like behavior, and 'free' indicates no cost. This goes beyond the empty parameter schema and gives the agent safety expectations, though it stops short of explicitly stating side effects or idempotency.

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 two sentences, front-loads the key identifier ('same JSON as GET /accueil'), and every clause delivers value: what it is, what it returns, what content it covers, and when to use it. There is zero fluff.

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

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

For a zero-parameter tool with an output schema present, the description is fully sufficient. It explains the tool's role, content, and usage timing. Nothing an agent needs to correctly call it is missing, and it routes the agent away from paid routes effectively.

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 has zero parameters and the schema coverage is 100% (empty object). The description doesn't reference parameters, which is appropriate. Per the baseline for 0 params, a 4 is warranted; nothing more is needed.

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 tool as the 'Kairos welcome salon' with a specific resource ('same JSON as GET /accueil') and explains its contents: who runs the service, how to talk, costs, and gathering info. It also differentiates from paid routes, so an agent can distinguish this from siblings like contact_kairos.

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 clear when-to-use directive: 'Start here before paid routes.' It also calls itself the 'free front door,' implying it should precede any paid tools. It does not explicitly name alternative tools or provide exclusions, but the context is strong enough for correct selection.

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?

The description adds substantial behavioral context beyond the annotations: it is advisory only, sensitive to prompt injection, requires the caller to retain final judgment, costs $0.001 per call, and needs no external account. This goes well beyond the readOnly, openWorld, and idempotent annotations without contradicting them.

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 core purpose and return values, then adds operational caveats and pricing. Most sentences earn their place, though the provider branding and sample-endpoint suggestion are slightly less essential than the safety and cost details.

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 presence of an output schema and safety annotations, the description supplies the remaining decision-critical context: advisory nature, prompt-injection risk, cost, and the caller's responsibility. An agent has enough information to invoke it correctly without needing more explanation of return values.

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 input schema already documents both parameters thoroughly. The description mentions the user request and tool call only at a high level and adds no syntax, format, or edge-case detail 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 clearly states the specific decision the tool makes: whether a tool call should run automatically, require human confirmation, or be denied, and it names the return values. It is easily distinguishable from most siblings by its tool-call safety focus, though it does not explicitly contrast itself with potentially related siblings like decide or verify.

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 provides a clear usage context: call it with the user's request and the proposed tool call to get an allow/ask/deny judgment. It also tells the calling agent to keep final decision authority. However, it does not state explicit when-not-use conditions or name alternative tools for related checks.

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

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

With no annotations, the description carries the full burden. It discloses the output form ('hex digest') and the algorithm set, which implies a deterministic, side-effect-free computation, but it never explicitly confirms no state is modified and says nothing about input size limits or rate limits.

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?

A single front-loaded sentence with no filler; the verb, the algorithms and the output format are all in the first clause. Every word 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?

For a one-shot pure function with no output schema, the description covers the essential purpose, but it leaves the nested payload object and the required text field undocumented, so an agent still has to open the schema 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 description coverage is 0%, so the description must compensate. It lists the four algorithm names, partially covering the 'algorithm' field, but says nothing about the required 'text' field or the nested payload-wrapper structure, and never maps the algorithm names to the schema's md5|sha1|sha256|sha512 pattern.

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+resource ('Compute ... hex digest of text') and enumerates supported algorithms, so the agent knows exactly what it produces. It does not, however, distinguish itself from the sibling hash_hmac, which is the nearest lookalike in the toolset.

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

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

There is no when-to-use guidance and no mention of the alternative: an agent choosing between plain hashing and hash_hmac gets no help here. Only the algorithm enumeration hints at scope, and even that is left implicit.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the algorithm set but omits the output encoding/format (hex vs base64), the default algorithm behavior, and any statement that this is a deterministic, side-effect-free computation. Adequate but leaves real gaps for an unannotated tool.

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

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

A single, front-loaded sentence with zero filler. The verb, the resource, the algorithm options, and the keyed nature are all packed efficiently.

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

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

For a simple pure-function tool the description is close, but with no output schema and no annotations it should state the return format (e.g. hex digest string), which an agent must know to use the result. The core computation is covered, the output contract is not.

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

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

Schema description coverage is 0%, so the description is the only semantic source. It maps cleanly onto all three fields: 'text' as the message, 'key' as the secret key, and it explicitly enumerates the four algorithm identifiers matching the schema pattern, which a regex alone communicates poorly.

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

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

States a specific verb+resource ('Compute an HMAC ... of text with a given key') and enumerates the supported algorithms. HMAC is a distinct primitive that separates it from the plain-digest sibling hash_hash without needing to open either 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?

No when-to-use guidance and no routing to alternatives. It never says to use this (keyed MAC) instead of hash_hash (unkeyed digest) when message authentication/integrity checking is the goal, nor when a specific algorithm is required.

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 behavioral burden. It indicates the tool returns a JSON Schema at no cost and frames it as a structured failure record, implying a safe read-only retrieval with no side effects. It does not explicitly state auth, rate-limit, or side-effect behavior, but for a parameterless schema getter this is sufficient.

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 two short sentences, front-loads the action and resource, and adds only one clause of definitional context. There is no filler or repetition; even the 'free' note is brief and not damaging to structure.

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

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

For a zero-parameter metadata endpoint with an output schema present, the description is nearly complete: it states the returned artifact, its version, and the situation in which the schema is relevant. It falls short only by not explicitly routing the agent away from sibling schema-related tools, which is a minor gap for such a simple 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?

The tool has zero parameters and the input schema is empty with additionalProperties false, so there are no parameter semantics for the description to clarify. The baseline of 4 applies; the description's reference to v1 and the schema's purpose is extra context rather than a necessity.

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 ('Return') and names the resource ('JSON Schema for honest delivery refusals (v1)'), plus a defining use case: 'Structured failure record when no tool_result can be delivered.' It does not explicitly name or distinguish the sibling tool_delivery_receipt_schema, though the refusal/receipt contrast is largely implied by the wording.

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 provides clear conceptual context for when the schema applies — when no tool_result can be delivered — so an agent can infer relevance. However, it gives no explicit when-not-to-use guidance and does not point to alternatives such as validate_honest_delivery_refusal or tool_delivery_receipt_schema.

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, openWorld, and idempotent. The description adds useful behavioral context: Jev-powered with automatic Groq-hosted LLM fallback and a sub-4.5s guarantee. It does not cover auth, rate limits, or error behavior, but adds meaningful beyond-annotation detail.

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 three tightly structured sentences, front-loading the core classification purpose and categories. Behavioral details follow, and there is no wasted text.

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

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

For a single-parameter classification tool with an output schema and rich annotations, the description is largely complete. It explains outputs, fallback behavior, and latency, but omits when to choose it over semantically similar 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%, and the only parameter (text) is fully described in the schema as up to 4000 characters. The description adds no additional parameter semantics, 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?

The description states a specific verb and resource: classify text into intent categories (question, request, complaint, compliment, other). It also mentions confidence and alternate label outputs. However, it does not explicitly differentiate from siblings like sentiment or classify, which could overlap.

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