Agent Control

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

Annotations declare readOnlyHint=true and destructiveHint=false, and the description is consistent with that while adding real context: no API key required, public https sites only, and the important caveat that a pass does not mean a crawler or agent will actually use the site. It stops short of describing rate limits, error behavior, or what a failing check looks like.

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

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

Three tightly packed sentences with the free/no-key qualifier front-loaded, followed by the action and the result caveat. Nothing is padded or redundant.

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

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

With no output schema, the description usefully enumerates what gets checked and warns that a pass is not a guarantee, which covers the main interpretive gap. It still does not indicate the shape of results (pass/fail vs. detail) or failure handling, leaving a small omission for a 1-param 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% for the single 'url' parameter, and the schema already states 'Public https site URL'. The description restates the 'public https site' constraint but adds no format, scheme, or validation 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?

Specific verb and resource: reads a public https site and returns readiness checks for robots.txt, llms.txt, agents.json, descriptions, and skill.md. The scope is unusually concrete, but it never names or contrasts a sibling (e.g. x402_listing_check, meter_scan), so an agent must infer the distinction.

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?

'Free. No API key.' plus the alias 'Same as POST /api/v1/agent-check' give partial context about cost, auth, and the equivalent REST endpoint. There is no explicit when-to-use versus sibling tools and no statement of when not to use it, so usage is only implied from the name and scope.

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 annotations only covering safety hints, the description adds real behavior: it returns 'go, stop, or wait plus approval_id', the timeout policy is 'stop', and it must be followed by polling get_approval. That is substantive context an agent cannot get from readOnlyHint/destructiveHint. It omits what happens on denial or how approval_id is consumed.

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?

Terse and dense with no filler; nearly every clause carries an instruction (return values, timeout, polling, enforcement). The lead sentence 'Same as check_action (Ask)' wastes the highest-value position on a pointer instead of a self-contained statement, which is the main structural weakness.

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 5-parameter, 3-required gate with no output schema, the description compensates well on outputs (go/stop/wait, approval_id, timeout) but leaves the input contract completely unexplained. Because required parameters like action_type and preview are undocumented, the definition is not quite sufficient to invoke the tool correctly.

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

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

Schema coverage is 0% across 5 parameters (3 required), and the description explains none of them — risk, target, preview, summary, and action_type go entirely undefined in structure or format. An agent must guess what values are valid, particularly for action_type and risk. Marginal semantics leak from words like 'action' and 'preview' in the prose, but the required-parameter burden is essentially unmet.

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 action and scope: 'Stop and ask before a consequential non-money action.' This clearly distinguishes it from money-related siblings like check_transfer and create_checkout. The opening 'Same as check_action (Ask)' is a cross-reference rather than a definition, which slightly muddies an otherwise clear purpose.

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 usable trigger ('consequential non-money action') and an explicit exclusion (non-money, and it does not forward email/Slack/CRM). It also names the enforcement alternatives email.send, slack.post, and crm.write. It does not, however, say when to prefer ask_human over sibling check_action or attach_human.

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

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

Annotations only indicate readOnly=false and destructiveHint=false, so the description carries the burden of explaining behavior. It adds meaningful constraints: the operation does not relocate the agent, and agents cannot decide the Approval Inbox. These are non-obvious behavioral details beyond what annotations provide.

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 with no filler. It front-loads the core action, then adds the two most important behavioral caveats. Every sentence 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 simple two-parameter tool with no output schema, the description covers the purpose, the identifier options, and an important limitation. It could be more explicit about requiring one of the two optional parameters and what attaching changes operationally, but these are minor gaps given the tool's simplicity.

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

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

The schema already describes both parameters with 100% coverage, so the baseline is 3. The description adds value by signaling that human_email and principal_id are alternative identifiers ('email or existing principal_id'), implying that one of them should be supplied even though the schema marks both as optional.

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 ('Attach') with a clear resource ('this agent') and target ('a human principal'), and it disambiguates itself from a transfer operation by explicitly stating it does not move the agent to a different human. This distinguishes it from sibling tools such as check_transfer.

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 to use the tool through its purpose and clarifies a key negative case ('Does not move the agent to a different human'), but it never names an alternative tool or states explicit conditions for choosing this tool over a sibling. Usage guidance is mostly inferred rather than directly provided.

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

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

Annotations already establish readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds two genuine behavioral facts beyond the annotations — no API key/auth is required, and results are ordered featured-first then newest — but wraps them in marketing noise rather than operating 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?

Roughly half the text is monetization copy ('Posting costs nothing', 'Featured is $19 for 7 days', 'Hire paths pay us directly') that is irrelevant to invoking a browse tool. The actual behavior is stated last, so the definition is neither front-loaded nor free of 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 and no parameters, the description should carry the return-shape burden; it partially does (featured-first ordering, equivalence to the /agents/listings endpoint) but omits pagination, result limits, and what fields each listing contains.

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 zero parameters at 100% coverage, so the baseline is 4. The description adds no parameter semantics, and there are none to add.

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 operative sentence — 'Lists agents on the free directory, featured first, then newest' — does state a clear verb+resource and even anchors it to 'GET /api/v1/agents/listings'. But it is buried under promotional copy about pricing and 'hire paths', and nothing distinguishes it from siblings like list_your_agent or list_open_jobs.

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 comparison against alternatives such as list_your_agent. The 'No API key' line hints at accessibility but never tells the agent which browse/list tool to pick in a given situation.

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

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

Annotations only say readOnlyHint=false and destructiveHint=false, which is consistent but thin. The description adds the return domain (go/stop/wait), the timeout behavior ('No decision in 10 minutes = stop'), the must_abort guard, and the polling loop via get_approval — real operational context beyond the annotations.

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

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

Front-loaded headline, then dense imperative rules in short sentences; the negative scope (does not send/post/write) is placed after the core contract. No sentence is 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 gate tool with no output schema and fully documented params, the description covers trigger, return values, timeout, abort signal, polling recovery, and explicit exclusions. Nothing needed to call it correctly is missing, though must_abort is referenced without being defined as a response field.

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 action_type, preview, summary, risk, and target are already documented, and the description only echoes the action_type value list. No additional formatting, size, or validation semantics are supplied, so the baseline 3 applies 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?

States a specific verb and gating resource ('Action Gate Ask', called before a consequential non-money action) and draws the boundary against money actions (check_transfer) and enforcement tools (email.send, slack.post, crm.write). An agent can distinguish it from every sibling without opening 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?

Explicit trigger ('MUST be called before a consequential non-money action when the agent still executes after go'), explicit alternatives for the adjacent cases ('To enforce those, call email.send, slack.post, or crm.write'), and the follow-up path for a wait decision (poll get_approval).

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 discloses the tool's decision logic and output values, plus a follow-up action. While it does not explicitly state side effects, the annotations (readOnlyHint false, destructiveHint false) do not contradict the described behavior, and the decision-oriented nature is well conveyed.

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 concise—two sentences total—and packs essential information: mandatory call timing, return values, and conditional handling. Every sentence adds value with no redundancy or 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?

The description explains the core decision flow and references the sibling tool get_approval for polling, which provides essential context. It does not elaborate on every possible output (e.g., what 'alert' implies), but the instructions are sufficient for an agent to act 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?

The schema provides full coverage for both parameters (to and value_usd) with clear descriptions. The tool description does not add any additional semantic information beyond what is already in the schema, so it meets the baseline for high schema coverage.

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's purpose: to check a transfer before signing or sending, and it lists the possible decision outcomes (allow, alert, hold, block). It is unambiguous about when it should be used, making it distinct from 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 gives explicit usage instructions: it MUST be called before signing/sending, and it provides conditional actions (do not sign if must_abort is true; poll get_approval on hold). This leaves no doubt about when and how to use the 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 only say readOnly=false and destructive=false, so the description adds real context: this initiates a request rather than completing payment, the human pays on-chain, it is not automatic, and agents cannot resolve the Approval Inbox. What is missing is whether the request expires, what auth the calling agent needs, and what the caller receives back.

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?

Short and front-loaded with the core action, but it is a run of sentence fragments whose meaning is uneven. 'Agents cannot decide Approval Inbox' is cryptic and the plan-outcome sentences read as telegraphic rather than structured.

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

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

For a mutation tool with no output schema and only readOnly/destructive annotations, the description covers the human-payment flow but omits the calling agent's auth requirements, request lifecycle/expiry, and what the response contains, leaving gaps an agent would need before invoking 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 coverage is 100%, so baseline is 3, but the description adds outcome semantics beyond the terse schema text: choosing 'action' opens the $49 Action Gate paid in Solana USDC, while starter/pro/team open the wallet console. It does not clarify the asset/chain interactions (e.g., can action pay in eth).

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: opening a pay request on the owning human principal, and even names the wrapped endpoint POST /api/v1/billing/checkout. It is clear what the tool does, though it does not explicitly contrast itself with siblings like start_trial or get_pricing.

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 context (a human must pay on-chain, it is not automatic) and explains what each plan value selects, but it never states when to choose this tool over start_trial or get_pricing, nor any exclusions or prerequisites beyond 'the human pays'.

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

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

Annotations only declare readOnlyHint=false and destructiveHint=false, but the description adds substantial behavior: non-posting conditions (unpaid, missing DATABASE_URL, stop, timeout), the stop-on-missing-webhook case, the approval-gated write flow, and the $49 Action Gate seat requirement. This is exactly the extra context annotations cannot convey.

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

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

Front-loads the gate identity and keeps every sentence informational, with no filler. The clipped, telegraphic phrasing ('Unpaid, missing DATABASE_URL, stop, and timeout do not post') is dense but readable and purposeful.

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

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

For a mutation tool with no output schema and no required parameters, the description covers the failure modes, approval loop, and prerequisites an agent needs. It names the decision states (go/wait/stop) but does not describe the response shape on success, a minor gap given there is no 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 100%, so every parameter is already documented in the schema, including approval_id's provenance and payload/preview meaning. The description reinforces the approval_id re-call flow but adds no syntax or format 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 action (validate preview, run check_action gate, POST approved preview to the CRM webhook) on a specific resource. It also names the sibling tools it interacts with (check_action, get_approval), so an agent can distinguish it from email.send/slack.post. It does not explicitly contrast itself with those other write-delivery siblings, keeping it just 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?

Gives clear operative conditions: it posts only when decision is go, and if decision is wait it must poll get_approval and call crm.write again with approval_id. It does not state when to prefer crm.write over sibling channels like email.send or slack.post, so it falls short of explicit alternatives 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 only declare readOnlyHint=false and destructiveHint=false. The description goes far beyond that: it discloses an internal validation step, an external gate dependency, the failure modes that block sending, the re-invocation flow after wait, the requirement of a connected Agentmail inbox, and seat/pricing applicability. Rich behavioral coverage the annotations do not provide.

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 'Write Gate' and the core purpose, and each sentence carries required workflow detail. It is dense with gate jargon and slightly run-on, and the 'does not send' conditions repeat across two sentences, but nothing is gratuitous.

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

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

With no output schema, the description carries the return-behavior burden and does so: it explains what each decision (go/wait/stop) means for the caller and the follow-up needed. For a gated write tool with five params, an agent has everything required 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 100%, so each parameter is already documented in the schema (including approval_id's origin from a previous wait). The description adds contextual flow for approval_id but no new syntax or format beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb+resource (send email) with a clear qualifier (only after human approval via Action Gate). It names the sibling tools it orchestrates (check_action, get_approval) so an agent can distinguish it from those. No ambiguity about what the tool does.

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

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

Explicit when-to-use and when-not: it sends only when decision is go; on wait it directs the agent to poll get_approval then re-call with approval_id; it enumerates the failure conditions (unpaid, missing DATABASE_URL, stop, timeout, inbox not connected) that suppress sending. Alternatives and sequencing are fully spelled out.

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 provide readOnlyHint=true and destructiveHint=false. The description adds no further behavioral details (e.g., side effects or error conditions), so it meets the baseline without exceeding it.

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 that directly conveys the tool's purpose without any redundant information. It is well-structured and efficient.

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

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

Given no parameters, no output schema, and a simple read-only getter, the description fully suffices. It explains exactly what the tool returns, leaving no ambiguity for an agent.

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 no parameters, so the schema fully covers the input contract. The description appropriately omits any parameter details since none exist, making it 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?

The description clearly states the verb 'Returns' and specifies the resource (agent status) with distinct outcomes (paused, expired, healthy), making it instantly clear what the tool does and differentiating it from the sibling get_status.

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 does not explicitly state when to use this tool versus alternatives like get_status. It is implied by the specific wording, but there is no direct guidance on choosing this over other status-related tools, especially given the similar sibling get_status.

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 declare read-only and non-destructive behavior, while the description adds significant state-machine context: polling until final, timeout semantics ('Action Gate timeout is stop'), and the write-gate forwarding condition. It does not specify polling cadence or return shape, but relative to annotation coverage this is rich behavioral disclosure.

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 compact, front-loaded sentences: the core action comes first, followed by source tools, continuation rules, and gate-specific forwarding behavior. Every sentence carries operational information 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?

Covers the critical cross-tool workflow: where approval_id comes from, polling until final, timeout behavior, and write-gate re-invocation. Missing return-value shape or polling cadence, but with no output schema and annotations covering safety, it is nearly complete 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 coverage is 100%, so the baseline is 3. The description adds provenance beyond the schema's check_transfer-only note by listing check_action and Write Gate as additional sources, and it explains the re-call-with-approval_id requirement, though it still does not describe format or validation details.

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 'Poll a held check' as a specific verb+resource and identifies the producing tools (check_transfer, check_action, Write Gate). It distinguishes itself from siblings by naming where approval_id comes from, though 'held check' remains jargon and the return decisions are only implied by parentheticals and the title.

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

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

Explicitly tells when to call (after a held check), what to pass (approval_id from named tools), and to repeat until the decision is final. It adds conditional routing rules: Action Gate timeout is stop, and Write Gate forwards only after re-calling email.send, slack.post, or crm.write with the approval_id when the decision is go.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: 1-day trial, no card, no KYC, on-chain USDC payment on Solana, and that a human principal owns billing — all of which shape how the agent should describe terms to a user.

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?

It is front-loaded with the purpose, but the body is a dense block of hard-coded price points and plan names that reads more like marketing copy than tool guidance. Some of that detail is defensible given there is no output schema, but the sentence 'A human principal owns billing and Approval Inbox' is loosely connected to the tool's function.

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 parameters and no output schema, the description usefully conveys the substance of what the tool returns (plan tiers, prices, trial terms). It is largely complete for a simple read tool, though it omits any note on return format or currency handling beyond the USDC mention.

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

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

The tool takes zero parameters, so there is nothing to document and the baseline is 4. The description does not need to compensate for any schema 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: 'List Agent Control plans and trial truth,' which tells the agent this is a read tool returning plan/trial information. However, it never distinguishes itself from near-neighbor siblings like meter_pricing or start_trial, so the agent must infer the boundary.

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 description lists prices but never says to call this before start_trial, before create_checkout, or instead of meter_pricing, even though several siblings occupy adjacent territory.

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 mark the tool as read-only, and the description adds meaningful behavioral context beyond that: it scopes the result to the human principal and explicitly states it cannot approve holds or return approval inbox items. This prevents the agent from expecting approval-related behavior from a status 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?

Two sentences, no filler, with the core purpose first and the critical exclusions immediately after. 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 parameterless read-only status lookup, the description covers who the status belongs to and what it does not include. It lacks an explicit note about the shape of the returned status value, but no output schema exists and the purpose is simple enough that this is a minor gap.

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

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

The tool has zero parameters, so the baseline is 4. There is no parameter meaning to clarify, and the description appropriately focuses on scope and return behavior instead.

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

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

The description clearly identifies the resource as the subscription or trial status of the human principal who owns the agent, which is more specific than the tool name alone. It also distinguishes itself from approval-related tools by explicitly stating it does not return Approval Inbox items or approve holds.

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

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

The description gives clear context for when this tool is appropriate: checking the human principal's subscription or trial status. It provides useful exclusions (no approval inbox, no approving holds) that prevent misuse, though it does not explicitly name sibling alternatives like get_approval or get_agent_status.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description usefully adds that no API key or gate seat is required, that results are ordered newest first, and that the output matches the REST endpoint. It omits pagination, result limits, and whether the list is ever truncated.

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?

Most of the description is advertising copy about posting costs, featured pricing, hire paths, and directory links, none of which helps an agent decide to call this tool. The one sentence that defines the behavior is placed last instead of being front-loaded.

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

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

For a zero-param, read-only listing tool it covers the essential return shape (open jobs, newest first) but stops there, with no pagination or cardinality guidance and no output schema to fall back on. The heavy promotional content occupies space that could have carried this missing operational detail.

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

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

The tool takes zero parameters, so the schema-driven baseline of 4 applies. The description adds nothing parameter-related because nothing needs to be supplied, and it correctly presents this as a no-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 functional purpose is stated, but only in the second-to-last sentence: "Returns open jobs on the free job board, newest first." That is a clear verb+resource, yet it is buried behind pricing, links, and infrastructure claims. No differentiation from the sibling post_job, which is the obvious counterpart to a job-listing read.

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. The only directional cues are implicit constraints ("No API key. No Meter look. No Action Gate seat.") and the parity note with GET /api/v1/exchange/jobs, which hints this is the free-tier read path but never says when to prefer it over post_job or another list 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 declare readOnlyHint=false / destructiveHint=false, and the description is consistent with a non-destructive write. It adds genuinely useful behavior detail beyond the annotations: listing is free, no auth/API key is required, and the contact you supply is publicly displayed. It says nothing about moderation, latency, or what happens after submission.

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 text is cluttered with promotional filler ('Free job board', 'Posting costs nothing', 'Featured is $19 for 7 days', 'Hire paths pay us directly') and literally repeats 'Listing your agent is free.' The actionable purpose and prerequisites are not front-loaded; the reader must sift through ad copy to find them.

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?

This is a write tool with no output schema and four required fields, so the description should be explaining submission outcome, moderation, and visibility rules. Instead it spends its length on pricing/ads and one external link, leaving the post-submission behavior and any listing lifecycle entirely unstated.

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 80%, so the schema already carries most parameter meaning and the baseline is 3. The description adds only one real parameter insight — the contact field is exposed publicly on the listing — and one vague pointer, 'Same fields as POST /api/v1/agents/listings', which is external indirection rather than in-place 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?

Buried inside marketing copy is a workable purpose statement — 'Add your agent to the free directory' — with a concrete resource (an agent listing in a public directory). However, the description also talks about a job board, featured pins, and 'hire paths', so an agent cannot cleanly separate what THIS tool does from the surrounding service landscape.

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 tool versus alternatives; the sibling browse_agents (reading the directory) is never referenced, nor is post_job. 'No API key. No Meter look. No Action Gate seat' is context about prerequisites rather than selection 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?

Despite minimal annotations (readOnlyHint=false, destructiveHint=false), the description fully discloses the tool's behavior: it returns a payable invoice with a detailed field list, states 'No inbox' and 'We never take keys,' and explains the security posture. It also covers the payment rails and response statuses, far exceeding the annotation baseline.

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

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

The description is dense and information-rich, but it is logically structured with an opening that clarifies the core purpose and price points, followed by payment rails, response fields, and security notes. Every sentence contributes value, though the long list of invoice fields could be visually streamlined. It remains readable and well-organized.

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 complexity of a payment tool with multiple rails, response fields, and next-step instructions, the description is remarkably complete. It covers the return format, how to use the returned fields, integration with meter_watch, security considerations, and edge cases like the 402 pay_page fallback. Without an output schema, it compensates fully.

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

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

Schema coverage is 100%, but the description adds substantial meaning beyond the schema. For instance, it explains the sku options, when proof is allowed (only with METER_DEV_GRANT=1), the nature of the payment payload, and the pass_token usage for extension. This enriches each parameter with practical context the schema alone lacks.

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 action (buy) and the resource (Agent Meter pass), with specific pack names and prices. It distinguishes itself from siblings like meter_pricing by focusing on the purchase and mint/extend action, and it names the exact SKUs and their purposes.

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 explicit usage instructions: 'Prefer Base EIP-3009 exact to base_pay_to (CDP/AgentKit; no Solana key) then meter_watch with payment,' and explains when to fetch adapter_url, how to finish in-process, and when to use pay_page as a last resort. This clearly routes the agent to the correct alternative tools and payment flow.

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 declare readOnlyHint=false and destructiveHint=false, which is ambiguous (not read-only, not destructive). The description adds some behavioral hints: 'Never hold' suggests the tool doesn't persist state, and 'allow or stop vs cap_usd' suggests it returns a decision. However, it doesn't explain what happens on a 402, what 'X-Agent-Pass' is, or what the actual side effects are. The cryptic pricing and 'No free looks' statements are not clearly tied to the tool's behavior. No contradiction with annotations, but the description fails to provide meaningful behavioral transparency beyond vague hints.

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 extremely short but not concise in a useful way. It reads like a stream of disconnected fragments: 'Can I pay this address? Buy looks_20 pack ($0.20) or look $0.10. Stamp ticket $0.05. No inbox. One look = one address. No free looks.' These sentences don't form a coherent explanation. The most important information ('allow or stop vs cap_usd') is buried at the end. There is no front-loading of the tool's core purpose. This is under-specification disguised as brevity.

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?

This is a tool with 6 parameters, no output schema, and no useful annotations. The description fails to explain the tool's core function, the meaning of the pricing references, the role of pass_token, or what the output looks like. An agent would not be able to reliably invoke this tool correctly. The cryptic references to 'looks_20 pack', 'Stamp ticket', and 'X-Agent-Pass' are unexplained domain jargon. Compared to the sibling tools, this lacks the clarity needed for correct selection and invocation.

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

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

Schema description coverage is 0%, so the description must compensate for the bare parameter names. It does mention 'Body: chain, wallet, to, value_usd, cap_usd' and 'allow or stop vs cap_usd', which gives some meaning to cap_usd and value_usd. However, it doesn't explain what 'chain' values are valid, what format 'wallet' should be, what 'to' represents, or what 'pass_token' is for. The cryptic pricing statements don't clarify parameter semantics. With 6 parameters and 0% schema coverage, this is insufficient.

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 is a jumble of pricing fragments ('Buy looks_20 pack ($0.20) or look $0.10. Stamp ticket $0.05.') and cryptic rules ('One look = one address. No free looks.') without a clear statement that this tool performs a preflight check against a cap. The title says 'Preflight against a self cap', but the description never explicitly says 'checks whether a payment is allowed' or 'returns allow/stop'. It mentions 'allow or stop vs cap_usd' at the end, which hints at the purpose, but the overall message is confused and fails to clearly distinguish this from sibling tools like meter_scan or check_transfer.

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 alternatives. The description mentions 'No inbox' and 'Without a paid X-Agent-Pass, 402 looks_20 pack $0.20' which seems to describe error conditions, but it doesn't say 'Use this before sending a payment' or 'Use meter_buy_pass if you need a pass'. The sibling list includes meter_buy_pass, meter_pricing, and check_transfer, but the description never references them or provides selection criteria.

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 and destructiveHint false. The description adds meaningful context: this endpoint requires no Authorization/Bearer, no API key, no inbox/email, supports Base and Solana USDC, and excludes Human App $29 plans. The 'Buy' wording reads as pricing guidance rather than a side-effect claim, so it does not rise to an annotation contradiction.

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

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

The text is a run-on of fragments with no clear lead: 'Can I pay this address?' and 'Buy...' appear before the purpose-revealing 'Public catalog' clause. Important facts are packed together without hierarchical structure, making it hard to scan.

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

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

For a zero-parameter, read-only, annotation-backed tool, the description gives enough raw data (SKUs, prices, payment rails, auth constraints) to be minimally usable. However, it never explicitly states what the tool returns on invocation and does not distinguish itself from get_pricing, leaving the agent to infer the call's purpose.

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 schema coverage is 100%, so parameter-level documentation cannot add value. Baseline 4 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 hints at a read-only pricing catalog ('Public catalog from this tool: look, looks_20, addresses_100, stamp_tx') and gives concrete prices, so it is more than tautology. But it opens with 'Can I pay this address?' and 'Buy...' rather than a clear verb + resource, leaving ambiguity about whether the tool answers an eligibility question, returns a catalog, or executes a purchase.

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 sentence tells an agent when to call meter_pricing instead of siblings like get_pricing or meter_buy_pass. The constraints (no auth, no API key, no email, separate Human App plans) are context, not decision criteria or 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?

The description does disclose some behavioral traits beyond the annotations: it mentions that a 402 error occurs without a paid X-Agent-Pass, that 'No free looks' (a charge applies), and that risk levels are 'ok|new|warn|sink'. However, these disclosures are cryptic and not clearly tied to the tool's execution flow. Annotations already cover read-only and non-destructive, so the description adds partial context but in a confusing way.

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 dense, run-on set of clauses mixing pricing, payment options, error codes, and risk levels. It lacks clear organization and front-loads a question rather than a declarative purpose. It is not concise or structured in a way that aids comprehension.

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

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

For a tool with 3 parameters and no output schema, the description is severely incomplete. It does not explain what the tool returns, what the risk levels mean, how the payment flow works, or what the user should expect. References to invoices and pay pages are unexplained, leaving an agent without enough information to invoke the tool 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?

The schema describes only 'chain' (33% coverage), and the description does not clarify the purpose or format of 'address' or 'pass_token'. It references 'X-Agent-Pass' indirectly but does not explicitly connect it to the pass_token parameter. With low schema coverage, the description fails to compensate by explaining parameter 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 opens with 'Can I pay this address?' implying a payability check, but then dives into pricing, payment methods, and error codes without clearly stating that this tool scans an address to determine risk or payability. It does not name a specific verb+resource and offers no differentiation from siblings like meter_preflight or meter_scan_batch.

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 meter_scan versus its sibling tools. The description mentions payment preferences (e.g., 'Prefer Base USDC... to base_pay_to') but that is about payment rails, not tool selection. No conditions, exclusions, or alternatives 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context: no inbox delivery, risk scores for up to 100 addresses, and a 'Never hold' instruction. However, the fragmented phrasing leaves the operational meaning of 'Never hold' and the billing flow unclear.

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 short but disorganized, mixing pricing, scanning behavior, and ambiguous imperatives like 'Never hold' in a staccato format. Important information is present, but it is not front-loaded into a clear, structured statement of purpose and usage.

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 the key outcome (risk scores) and acceptable output categories, but it lacks a clear explanation of pass_token, the SKU/pricing flow, and how this batch tool relates to billing. With no output schema, more explicit return-format detail would be needed for full 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 coverage is only 50%, and the description partially compensates by explaining the addresses limit and that sku addresses_100 covers scan_batch. However, the pass_token parameter is not explained, and phrases like 'looks_20 pack' and 'Stamp ticket' are not clearly mapped to any parameter.

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 title 'Scan a batch of destinations' plus the description's 'Risk scores for up to 100 addresses' and 'ok|new|warn|sink' clearly identify a batch risk-scanning tool. It is specific about the resource and the output categories, though it does not explicitly distinguish itself from the singular meter_scan sibling.

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 or alternatives. It mentions a SKU that 'covers scan_batch' but does not explain when this tool should be chosen over meter_scan, meter_preflight, or other siblings.

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

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

Annotations give only broad non-read-only, non-destructive hints, so the description carries most of the behavioral burden. It adds useful context: the receipt is signed with HMAC-SHA256, stamping costs $0.05, there is no inbox step, and merchants verify via meter_verify_stamp. It does not disclose whether a chain write occurs, whether fees are deducted from the wallet, or whether the receipt is reversible.

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?

At roughly 55 words it is short, but it is a jumble of sentence fragments and pricing phrases rather than a structured explanation. The useful information (signed receipt, verification sibling) is buried behind 'Buy looks_20 pack...' and 'No inbox.' The title front-loads the purpose, but the description does not.

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 financial tool with 7 optional-looking parameters, no output schema, and low schema coverage, the description omits essential calling details: required relationships among parameters, what the signed receipt contains, and what triggers a fee or transaction. It names the verification sibling, but an agent would not be able to construct a correct call solely from this text.

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 only 14%—only decision has a description—so the description needed to explain to, chain, wallet, cap_usd, value_usd, and pass_token. It does not: the text mentions an address, USDC, and allow/stop, but the mapping to parameters is speculative. It especially fails to clarify the optionality rule stated in the schema: decision is optional if value_usd and cap_usd are set.

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 title and phrases like 'Signed allow|stop receipt' and 'Stamp ticket' indicate the tool issues a signed allow/stop receipt. However, the description is dominated by opaque pricing language ('Buy looks_20 pack ($0.20)', 'Stamp ticket $0.05', 'stamp_tx $0.05') and never states cleanly what the tool does. It names meter_verify_stamp as a downstream verifier, which provides some sibling differentiation, but the core purpose remains hard to extract.

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 a workflow: stamp a receipt before merchants accept agent USDC, then verify with meter_verify_stamp. It does not explicitly state when an agent should call meter_stamp rather than alternatives such as meter_buy_pass, meter_preflight, or check_transfer. No exclusions or when-not conditions are provided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to repeat safety. It does add some behavioral context: the tool returns a signed receipt containing 'verified' and 'decision', and the access notes (public, no email, no API key) hint at authentication requirements. However, this context is disorganized and not fully fleshed out, so a 3 is appropriate.

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 long run-on string mixing unrelated pricing details ('Buy looks_20 pack ($0.20) or look $0.10. Stamp ticket $0.05.') with operational instructions. The core purpose is not front-loaded, and each sentence is not earning its place. It is verbose without being informative.

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

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

For a tool with two parameters and no output schema, the description leaves critical gaps: it does not explain what 'id' is for, does not describe the full return structure, and does not distinguish this tool from siblings like meter_scan or meter_stamp. The provided decision logic is helpful but the overall context is inadequate 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%, so the description must compensate for both parameters. It explicitly mentions 'by stamp_id', giving some meaning to that parameter, but it never mentions the 'id' parameter at all. The description is not structured as a parameter reference and leaves half the inputs unexplained.

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

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

The title says 'Verify a Meter stamp', but the description never plainly states that the tool verifies a stamp. The closest action phrases are 'GET a signed allow|stop receipt by stamp_id' and the opening question 'Can I pay this address?', both buried among pricing and policy statements. It does not clearly differentiate this from siblings like meter_scan or meter_stamp.

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 some usage context ('before you accept agent USDC') and a decision rule for interpreting output, but it provides no guidance on when to use this tool versus alternatives, nor does it name any sibling tools or exclusions. The 'No inbox', 'No email', and 'No API key' notes are access constraints, not usage 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?

Annotations only say readOnlyHint=false and destructiveHint=false, so the description carries the burden. It discloses that the tool is a payment/wait loop ('Repeat until the result includes token'), that it never takes keys, and that no human account is involved. It also clarifies the exact shape of the payment object and warns against sending raw signatures or secret keys.

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

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

The description is dense and front-loaded with the user question, but it is a long run-on paragraph with many clauses and parentheticals. It contains valuable information but would benefit from clearer sentence breaks and structure. Every sentence earns its place, but readability suffers.

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 payment-watch tool with no output schema, the description covers the payment object shape, the retry loop, the follow-up tool (meter_scan), and security constraints. It does not describe the return value format or error cases, but the workflow is sufficiently specified for an agent to invoke it correctly.

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

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

Schema coverage is 75%, and the description adds meaning beyond the schema: it explains that payment must be the Base x402 v2 object (not a raw signature), that signature is optional and only a tx sig, and that invoice_id comes from meter_buy_pass / 402 invoice. The sku parameter is not explained in the description, but the schema covers most 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 opens with a concrete user question ('Can I pay this address?') and names the resource (a Meter invoice) and the action (watch/pay it). It distinguishes itself from siblings by referencing meter_scan and meter_buy_pass, though it doesn't explicitly name a direct alternative for 'watch' vs 'pay'.

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

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

The description gives explicit preconditions: use Base EIP-3009 exact via CDP/AgentKit or optional Solana USDC, pass the Base payment object from payMeterPassBase / sign_exact.payment_template, repeat until token appears, then use meter_scan with pass_token. It does not explicitly say when NOT to use this tool versus a sibling, but the workflow context is clear.

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 annotations only declaring readOnlyHint=false and destructiveHint=false, the description adds genuine value: no API key required, and 'hidden true stores the job and leaves it off the public list' while the create result still returns the job. This discloses a non-obvious behavioral option, though it omits any auth or rate-limit 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 text repeats 'Posting costs nothing' twice, embeds bare URLs, and mixes pricing/marketing with the actual calling guidance. It is not front-loaded and several sentences do not earn their place in a tool 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?

For a mutation tool with six required parameters, no output schema, and only safety annotations, the definition covers the essential fields via the schema and adds the hidden behavior. But it spends its limited space on promotional content instead of filling gaps like validation consequences for the required deadline or budget fields.

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

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

Schema description coverage is 100%, so all seven parameters are already documented in the schema, including the hidden flag. The description adds only a restatement of hidden's behavior, which the schema itself already explains, so this sits at the baseline.

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 verb+resource is clear (post a job to a free job board) and the tool is distinguishable from siblings like list_open_jobs or browse_agents. However, the statement of purpose is buried in promotional copy about pricing, featured listings, and directory URLs rather than front-loaded.

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

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

It gives some context ('Post one job', no API key needed, no Action Gate) but never states when to use this instead of alternatives such as list_open_jobs or browse_agents. Usage is implied rather than specified.

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

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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description adds the full behavioral picture: validation, the Action Gate check, non-posting conditions (unpaid, missing DATABASE_URL, stop, timeout), the webhook dependency, and the resulting stop when the webhook is absent. This is far beyond what the annotations convey.

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

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

The 'Write Gate' label is front-loaded and each sentence carries workflow information. It is dense and slightly long-winded (the $49 seat/pricing line is marginal), but no sentence is pure 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 gated write tool with no output schema, the description covers the decision states and side effects thoroughly. Minor gap: it does not describe the returned payload shape for a successful post, though the decision vocabulary (go/wait/stop) is explained.

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 all five parameters are already documented, including approval_id's provenance ('From a previous wait'). The description reinforces approval_id's reuse pattern but adds no syntax or format 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?

The description states a specific verb and resource ('posts' to Slack) plus the gating condition ('only when the decision is go'), and names the sibling tools it depends on (check_action, get_approval). An agent can distinguish it from check_action or get_approval at a glance.

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

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

It states explicitly when to call (after a go decision), what to do on a wait decision (poll get_approval, then re-call slack.post with approval_id), and the failure conditions that should not result in a post. Alternatives and sequencing are named, not inferred.

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 discloses important behavioral aspects: it sends an invitation, that only humans can be invited, and that the human owns billing and Approval Inbox. It also states a limitation for agents. This goes beyond the basic annotations, though it does not describe the full side-effect sequence (e.g., whether a principal is created).

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 long, focused, and without unnecessary detail. It front-loads the core action and then adds relevant constraints, making it easy to parse.

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 is complete for the action's scope: it specifies the required input pattern, a key restriction, and an outcome ownership detail. It does not explain error handling or alternative flows, but given the simplicity, it is sufficiently 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?

The schema descriptions for human_email and principal_id are simple. The tool description adds crucial semantics by indicating that either one should be provided, and that principal_id is an existing human user id. This clarifies the 'or' relationship not explicit in 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 tool's action: 'Invite a human to start the 1-day trial.' The resource is a trial, and the verb is explicit. It also notes the constraint that agents cannot open a root account, distinguishing this from potential related actions.

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

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

The description explains input requirements ('Provide human_email or an existing principal_id') and a constraint, but it does not explicitly compare with sibling tools or specify when this tool is preferred over alternatives like create_checkout or attach_human. Usage guidance is implied rather than fully 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?

Far exceeds the annotations (readOnlyHint/destructiveHint). Discloses cost and auth ('Free. No API key.'), that it makes an external POST to Coinbase's validator, enumerates the checks performed, and adds a candid disclaimer ('A pass does not mean Coinbase will list you. We do not speak for Coinbase.'). This is unusually rich behavioral context.

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

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

Front-loaded well with 'Free. No API key.' and the core action, but the middle is a dense run-on enumerating a dozen checks that would read better as a list. Information earns its place, yet the packaging is heavy.

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

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

No output schema exists, so the description should carry return-value meaning, but it only implies pass/fail via the 'A pass does not mean...' caveat and never describes the report structure. Inputs and behavior are covered; the response shape is a real remaining gap.

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

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

Schema coverage is 100% and both parameters (url, pay_to) are fully described in the schema. The description echoes 'public https x402 endpoint, or a payTo wallet' but adds no format, syntax, or precedence detail beyond what the schema already states, 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?

States a specific action (read/check) against a specific resource (public https x402 endpoint or payTo wallet) for the purpose of Coinbase listing readiness. Distinguishable from generic siblings like check_action or agent_readiness_check by the x402/Coinbase framing, though it never explicitly names a sibling to contrast against.

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 clear operating conditions and explicit exclusions: 'A wallet alone could not be checked' and 'A URL that is not an HTTP 402 endpoint could not be checked,' plus the conditional use of pay_to 'when you do not have the URL.' It does not, however, route the agent between this and other check-family siblings.

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