Agent Control — Agent Meter

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?

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?

The description goes beyond the annotations by explaining the concrete behavior: it opens a pay request, the human pays on-chain via USDC, and it is not automatic. This gives a clear picture of side effects and constraints, which the annotations (readOnlyHint, destructiveHint) only hint at.

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 and well-structured: three sentences covering the action, the wrapped endpoint, and key constraints. No redundant or irrelevant details are included.

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 simple parameter set (three optional-ish fields) and absence of an output schema, the description is sufficiently complete. It explains the purpose, payment method, and approval constraints. It could have mentioned the expected return (e.g., a checkout URL), but that is not essential for correct usage.

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

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

The input schema already provides descriptions for all three parameters (plan, asset, chain) with 100% coverage. The tool description does not add any additional parameter-specific meaning, so it remains at 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 open a pay request on the human principal who owns the agent. It also clarifies that the payment is on-chain USDC, not automatic, and that agents cannot control the approval inbox, which distinguishes it from other tools.

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

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

The description implies when to use this tool (when a human-approved payment is needed) and explicitly warns about limitations ('Not automatic payment', 'Agents cannot decide Approval Inbox'), helping avoid misuse. However, it does not explicitly compare with sibling tools like start_trial or get_approval, leaving some inference to the agent.

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?

Beyond the readOnlyHint/destructiveHint annotations, the description discloses polling semantics and the terminal decision values ('allow' or 'block'). It does not describe the response envelope or field names, but the essential repeat-until behavior is explicit.

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

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

Two short sentences: first states the action and object, second gives the parameter source and termination condition. Every sentence carries necessary information with no filler.

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

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

For a one-parameter read-only polling tool with complete schema coverage, the description provides the call source, polling loop, and stopping condition. It is slightly light on the exact response shape or decision field, but no output schema is provided and the decision values are named.

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

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

Schema coverage is 100%, so the schema already defines approval_id as the ID from check_transfer hold decisions. The description's 'Pass approval_id from check_transfer' restates this rather than adding new meaning.

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 the specific action 'Poll a held pre-sign check', naming a precise resource and tying it to check_transfer. This clearly differentiates get_approval from siblings like get_status 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?

It says to 'Pass approval_id from check_transfer' and to repeat until allow/block, which establishes the exact triggering condition and loop behavior. It does not explicitly list exclusions or alternatives, but the held-check context is enough to route the agent correctly.

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 indicate read-only and non-destructive behavior. The description adds context about the content (plans, pricing, trial details) and mentions payment and ownership, giving the agent a clear picture of what information is available without contradicting 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 very concise—just two sentences—and front-loads the core purpose (listing plans) before providing details. It omits unnecessary text and is easy to scan.

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

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

For a simple read-only pricing list with no parameters and no output schema, the description is complete: it states what is returned (plan names, prices, trial info). Minor jargon like 'trial truth' and 'Agent Control' could be clearer but do not hinder understanding.

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?

With zero parameters, there is nothing to document. The baseline for 0 params is 4, and the description correctly contains no parameter explanations since none exist.

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 list Agent Control plans and trial truth, with a clear verb ('List') and resource. It distinguishes itself from sibling tools like start_trial or create_checkout by focusing on plan display, not trial initiation or checkout.

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: if you need to show available plans and pricing, this is the tool. It does not explicitly mention when to use it over siblings, but the purpose is self-evident.

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?

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?

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.