Agent Control

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?

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.