Agent Control — Action Gate

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 indicating readOnly=false and destructive=false, the description adds substantial behavioral context: the tool returns go/stop/wait plus approval_id, the agent must poll get_approval, timeouts are treated as stop, and Slack/CRM forwarding is not handled. This is exactly the kind of operational detail an agent needs beyond the annotations.

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

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

The description is compact and front-loads the core stop-and-ask behavior, return values, and timeout rule. Some fragments are terse to the point of ambiguity, such as 'Same as check_action (Ask)' and 'Use slack.post or crm.write to enforce,' but overall it avoids waste.

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 covers return values and polling behavior despite there being no output schema, which is helpful. However, with 5 parameters at 0% schema coverage, the description leaves parameter meaning entirely unexplained, which is a significant completeness gap for an approval 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 schema has 5 parameters and 0% description coverage, and the tool description does not explain action_type, summary, preview, risk, or target at all. Since the schema provides no parameter semantics and the description does not compensate, required inputs remain undefined.

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

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

The description states a specific action: stop and ask a human before a consequential non-money action. It also clarifies the return values (go, stop, wait, approval_id) and distinguishes scope from Slack/CRM enforcement and unsupported email, giving the agent a 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?

The description gives clear when-to-use guidance: before consequential non-money actions, with timeout treated as stop. It also names affected alternatives (slack.post, crm.write) and an unsupported case (email), though it does not fully contrast ask_human against check_action beyond saying it is the same as check_action (Ask).

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 already state readOnlyHint=false and destructiveHint=false, so safety framing is partly covered. The description still adds real behavior beyond them: three-valued outcome, the 10-minute timeout collapsing to stop, the must_abort escalation, and the boundary that this tool does not itself deliver the post or CRM write. Those are substantive, so it clears the lower bar annotations set.

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 obligation, then the return contract, then the wait path, then scope limits; nearly every sentence carries a distinct instruction. The phrase 'when the agent still executes after go' is slightly tangled and costs a little readability. No padding or repetition beyond that.

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

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

With no output schema, the description correctly supplies the return vocabulary (go, stop, wait), the timeout rule, and the must_abort field that governs whether to act. It also bounds scope against slack.post, crm.write, and email. Sufficient to call and interpret correctly, though the shape of the response object itself is left implicit.

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 action_type's example values and the optional risk and target fields. The description adds only the framing that preview is what executes after go, which largely restates the schema. Baseline 3 is correct when the schema does the work.

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

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

Names the resource (Action Gate) and states precisely what it returns: go, stop, or wait for a pre-action approval decision. It distinguishes itself from get_approval (the polling sibling) and clarifies it does not perform slack.post or crm.write. The opening label 'Action Gate Ask' is jargon, but the following sentence resolves it.

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

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

Explicit trigger ('MUST be called before a consequential non-money action... including deploy'), explicit follow-up path ('If decision is wait, poll get_approval until go or stop'), explicit timeout behavior, and explicit exclusions with the correct alternatives ('To enforce those, call slack.post or crm.write. Email isn't supported yet'). It also names ask_human as an alias, removing ambiguity with a sibling of that 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?

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 declare readOnlyHint=false and destructiveHint=false; the description adds substantive context: the charge lands on the human principal, payment happens out-of-band at pay_url in USDC across three chains, and the tool does not auto-charge. Idempotency of repeat calls and checkout expiry are not disclosed, which keeps it from 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?

Front-loaded with the core action, then plan effects and the payment mechanism; every sentence carries information. The telegraphic sentence fragments ('Not automatic payment. Agents cannot decide Approval Inbox.') are efficient but slightly clipped for a first read.

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 tells the agent that a pay_url is returned and must be handed to a human, and it covers all three plan paths. Missing are failure modes (already-subscribed, expired checkout) and any notion of how the agent should follow up after the human pays.

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 earns above that by explaining the consequence of the plan choice ('opens Action Gate' vs. 'open the wallet console'), which the schema only lists. The asset and chain parameters are left entirely to the schema.

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

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

States a specific verb and resource ('Open a pay request on the human principal that owns this agent') and names the endpoint it wraps. It also clarifies the per-plan effects (Action Gate vs. wallet console), which distinguishes it from siblings like get_pricing or start_trial, though those siblings are never named explicitly.

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

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

Explains which plan value triggers which outcome (action = $49 Action Gate; starter/pro/team = wallet console) and that payment is completed by the human, not automatically. It stops short of naming alternatives or explicit when-not-to-use conditions, relying on 'Agents cannot decide Approval Inbox' as an implicit pointer to approval/human tools.

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 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 already declare this a safe read (readOnlyHint=true, destructiveHint=false), and the description adds genuinely new behavior: it is a polling tool, decisions may be non-final, and the timeout semantics differ by gate type. It does not say whether polling should be backed off/rate-limited, and the return shape is only hinted at, so it stops short of full 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?

Front-loaded with the core action in the first four words, and every subsequent clause carries operational information rather than filler. The telegraphic phrasing ('Action Gate timeout is stop') is dense but slightly ambiguous, costing a little readability.

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

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

With one parameter, no output schema, and no annotations gap, the description covers the invocation side well. However, because no output schema exists, it should enumerate what the poll actually returns (the go/stop/wait decision shape and any pending state) instead of leaving it to inference from scattered phrases.

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 schema already explains approval_id, but the description meaningfully widens the source of that ID beyond the schema's 'returned when check_transfer decision is hold' to also include check_action and Write Gate tools. That is real added semantics rather than restatement.

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 ('Poll a held check') and immediately names the producing tools (check_transfer, check_action, Write Gate tools), which distinguishes it from those siblings. An agent can tell this is the read-side companion to the check/hold tools 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?

Explicit about the loop ('Repeat until the decision is final'), the failure mode for each gate type ('Action Gate timeout is stop'), the required follow-up for Write Gate ('call slack.post or crm.write again with that approval_id after the decision is go'), and an exclusion ('Email isn't supported yet'). This is close to a complete operating procedure for 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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered upstream. The description adds genuinely useful context—no card, no KYC, accepted chains (USDC on Base/Solana/Ethereum), and that a human principal owns billing—but says nothing about the shape of the response or whether prices are static.

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 purpose is stated first, which is good, but most of the body is enumerating dollar amounts and trial terms that are almost certainly the tool's output rather than invocation guidance. Those sentences are informative but belong to return values, not to the selection decision.

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 must convey what comes back, and it does so by listing the tiers, the Action Gate plan, and the trial conditions. An agent can call it confidently, though the mismatch with sibling 'meter_pricing' is never resolved.

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, establishing a baseline of 4. The stray '(plan=action)' notation hints at a filter argument that does not exist in the schema, which is mildly confusing but does not offset the fact that no parameter documentation 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 opening clause 'List Agent Control plans and trial truth' gives a specific verb and resource, so an agent knows this returns plan/pricing catalog data. However, it never distinguishes itself from the sibling 'meter_pricing', leaving ambiguity about which pricing tool answers which question.

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 call this versus 'meter_pricing' or 'start_trial', both of which appear adjacent in the sibling list. Usage is only inferable from the content itself, which is pricing facts rather than invocation 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 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.