agentcard

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

The description goes well beyond the annotations. It explicitly states that calling this tool moves no money, initiates no transfer, and only prepares a single-use hosted payment page. It also discloses that the user completes the payment in their own browser, that the agent never sees payment credentials, and that the tool may automatically send a verification code. This is rich behavioral context that the annotations (readOnlyHint=false, idempotentHint=false) do not provide.

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

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

The description is a single, dense paragraph that front-loads the core purpose and then explains the verification flow. It is longer than strictly necessary, but every sentence adds meaningful information. The structure is logical: purpose, non-behavior, user experience, verification fallback. It earns a 4 rather than a 5 because it could be slightly more scannable with a break between the main behavior and the verification flow.

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 an agent to invoke this tool correctly. It covers what the tool does, what it does not do, how the user interacts with the result, and the conditional verification flow. The output schema exists, so return values are already documented. The only minor gap is the exact range of the amount, but the description notes the API returns the range when invalid, which is sufficient.

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 covers both parameters with descriptions, including the enum values and the amount range. The description adds context by explaining the purpose of the amount (funds new cards) and the payment method selection guidance ('ask the user which one their device has; apple_pay only when unknown'). This adds value beyond the schema, though the schema already does most of 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?

The description clearly states the tool's function: generating a secure checkout link for adding funds via Apple Pay or Google Pay in USD. It distinguishes itself from related tools by explicitly noting it moves no money and initiates no transfer, and it names the sibling tool verify_phone for the verification flow. The verb 'generate' plus the resource 'checkout link' is specific and unambiguous.

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

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

The description provides explicit when-to-use guidance: it is the equivalent of the user clicking 'Add funds' in the dashboard, and it should be used when the user wants to add cash to their balance. It also gives a clear conditional workflow: if phone verification is needed, call verify_phone with the code, then call add_funds again. This is strong usage guidance that routes 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It explicitly discloses the override effect (allows a charge that would be denied), indicates persistence through 'remember,' and clarifies scope by stating it does not replace the preset. It omits details like how to undo the action or whether the allowance expires, but the core behavior is transparent.

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 consists of two concise sentences that front-load the core purpose and include a useful scope caveat. There is no fluff, and 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 simple 2-parameter tool with an output schema, the description is mostly adequate, but it does not address the notable fact that card_id is not required while the description says 'on a card.' It also leaves merchant matching semantics unspecified. Sibling buy_unlink_merchant suggests an undo path exists, which the description could have noted for completeness.

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 both parameters, so the baseline is 3. The description adds contextual meaning by linking the pattern to merchant matching, but it does not clarify the optionality of card_id or the exact matching semantics (case sensitivity, exact vs. substring). The description adds no significant information beyond the schema.

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

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

The description clearly states the tool's specific action: remembering a merchant on a card so that the next matching charge is allowed even when card category or merchant rules would deny it. This distinguishes it from sibling tools like buy_unlink_merchant (which presumably removes such an exception) and set_card_preset (which manages broader preset rules).

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 (to allow a specific merchant charge that would otherwise be denied) and includes the scope note 'does not replace the rest of the preset.' However, it does not explicitly name alternative tools or state when not to use it, leaving the guidance mostly implied rather than actionable.

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?

Describes the two different outcomes: for card_details/transaction, approval completes the action and returns result; for cross_app, it records consent and the requesting app retries. This goes beyond annotations (readOnlyHint=false, destructiveHint=false) and fully discloses the behavior.

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

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

The description is concise yet comprehensive, using a few well-structured sentences. Front-loaded with purpose, followed by usage contexts, and ends with specific behavior details. Every sentence adds value without redundancy.

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

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

Given the tool's complexity (multiple action types with different outcomes), the description covers all necessary aspects: when to use, how each action type behaves, and parameter hints. The existence of an output schema means return details are covered elsewhere, so the description is 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?

Adds meaning beyond the 100% schema coverage: explains that resource_id is card ID for most actions but approval ID for transaction, and that list_pending_approvals rows carry the action field. This enhances understanding of parameter usage.

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 resolves pending approval requests (approve or deny) and specifies the contexts (202 responses, list_pending_approvals). It distinguishes between card_details/transaction and cross_app actions, which differentiates it from sibling tools like close_card or pause_card.

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

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

Explicitly tells when to use this tool: after get_card_details or create_card returns a 202, or for rows from list_pending_approvals. It also contrasts the behavior for card_details/transaction (auto-complete) vs cross_app (record consent), providing clear usage 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?

Discloses critical behavioral traits beyond annotations: the tool returns a conversation_id that must be reused, checkout 'charges a one-time card' only after explicit user confirmation, replies must be relayed verbatim, and using new_order/timeout 'discards the cart and any pending confirmation.' This is exactly the kind of context an agent needs to avoid dangerous mistakes.

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 long, but every paragraph addresses a distinct critical aspect: conversational flow, checkout confirmation, error recovery, login links, and prerequisite guidance. It is front-loaded with purpose and uses capitalization/emphasis effectively. Dense but justified for a complex, potentially destructive tool.

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

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

Given the tool's high complexity and the presence of an output schema, the description fully covers the flow, prerequisites, alternative tools, safety rules, and error handling. An agent has everything needed to select and invoke this tool correctly.

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

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

Schema coverage is 100%, but the description adds significant semantics: request can be a follow-up or full ask with concrete examples, conversation_id must be 'the SAME conversation_id' for continuity, and new_order 'ignores any conversation_id' and is only for unrelated orders. The prose meaningfully clarifies all three parameters beyond the schema.

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

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

The description explicitly states the tool 'Shops and checks out, in natural language, across the merchants the user has linked' and 'runs the shopping flow for you.' This clearly distinguishes it from siblings like buy_connect or buy_list_merchants, which handle narrower aspects of the shopping lifecycle.

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

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

Usage guidance is explicit and actionable: 'Call get_instructions FIRST for the current usage guide before your first buy.' It also explains when buy_connect/buy_connect_status do not apply ('Logins started here have no pending_id') and details when new_order is appropriate versus when it must never be used for error recovery.

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?

Describes that it opens a hosted browser session for some merchants, returns a URL, and requires calling buy_connect_status for confirmation. Mentions that non-login merchants are ready immediately. Also notes that it only tracks logins it started itself. Adds significant context beyond annotations (readOnlyHint=false, destructiveHint=false). No contradictions.

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 sentences, each adding value. Could be slightly more concise but still effectively communicates key points without redundancy.

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

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

Given one parameter, existing annotations, and presence of output schema (implied), the description covers purpose, usage flow, alternatives, pairing, and specific behavioral notes. Complete for the tool's complexity.

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?

Single parameter 'merchant' has schema description 'merchant slug (e.g. doordash)'. Description adds behavioral context: behavior varies by merchant type. Since schema coverage is 100%, description adds meaning beyond 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?

Description clearly states it connects a merchant for shopping, distinguishes between merchants needing login and those that don't, and explicitly contrasts with buy_link_merchant. This provides a specific verb+resource with sibling differentiation.

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

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

Explicitly says 'Use this instead of buy_link_merchant for hosted-login merchants.' Explains pairing with buy_connect_status and contrasts with conversational `buy` tool. Clear when to use and when not.

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 safe, idempotent read. Description adds polling behavior and return states, no contradictions.

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 sentences, front-loaded with purpose, efficient and clear.

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 output schema exists and tool is simple, description covers all necessary context 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?

Schema description covers parameters fully (100%). Description restates that pending_id comes from buy_connect, providing marginal extra context beyond 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?

Clearly states the tool checks the status of a hosted merchant login started with buy_connect, lists return values, and distinguishes from sibling tool 'buy'.

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

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

Explicitly says when to use (after buy_connect) and when not to use (for logins from 'buy' tool), and provides alternative action.

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, idempotentHint, and destructiveHint safety, so the description mainly adds contextual behavior: it reports merchant availability and per-user linkage status. This is useful but not rich behavioral disclosure beyond what annotations and the presence of an output schema already communicate.

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

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

The description is two short, purposeful sentences. It front-loads the core action, gives concrete merchant examples, and ends with the key workflow instruction—no wasted words.

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

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

Given zero parameters, a read-only annotation profile, and an output schema, the description provides everything an agent needs to select and call this tool correctly. It covers scope, available merchants, user linkage status, and the prerequisite for shopping.

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

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

The tool has zero parameters, so the baseline is 4. The description appropriately focuses on what the tool returns rather than parameter details, and the empty input schema leaves no ambiguity.

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 ('List'), identifies the resource ('merchants available for agent commerce'), and clarifies the unique value: showing whether the user has linked each merchant. This distinguishes it from sibling tools like buy and buy_unlink_merchant.

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 clearly situates when to use the tool: before shopping, to see available merchants and whether they are linked. It also gives a practical instruction ('Link a merchant before shopping it') without explicitly naming alternative tools or exclusions, so it stops just short of a full usage guide.

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?

Description adds behavioral context beyond annotations: explains that the session and link are dropped and that re-linking is required. Aligns with destructiveHint=true without 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?

Extremely concise—one sentence that conveys purpose, effect, and required follow-up. No wasted words.

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

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

For a simple disconnect tool with one parameter and an output schema, the description fully covers purpose, behavior, and post-conditions. No gaps.

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

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

Single parameter 'merchant' has schema description. Description adds a concrete example ('e.g. doordash'), providing clarity beyond the schema.

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

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

Clearly states the action (disconnect a merchant) and the resource (merchant). Explains what happens: drops saved session and link, distinguishing it from other merchant-related 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?

Explicitly states the consequence and the need to re-link, guiding the agent on when to use. Lacks explicit when-not-to-use or comparative alternatives, but the 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?

Annotations already declare readOnlyHint and idempotentHint, indicating safe read operation. The description adds value by stating it returns the current step and missing fields, and confirms the tool is non-destructive. No contradictions.

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 concise sentences with no filler. The first sentence states the action and usage context, the second describes the return value. 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?

Given the tool's simplicity (zero parameters, clear annotations, and an output schema that presumably defines the return format), the description sufficiently covers purpose, usage, and behavioral context without missing critical details.

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 and 100% schema coverage, the tool's schema already conveys all parameter info. The description does not need to add parameter details, meeting the baseline for no-param tools.

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 checks conversational verification state, specifies when to use it (after ID upload or for re-orientation), and distinguishes from siblings like 'get_kyc_status' and 'submit_kyc_document' by focusing on the verification state and missing fields.

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 explicitly advises use after ID upload and for re-orientation, providing clear context. It does not mention exclusions or alternatives, but the guidance is sufficient for a simple read-only check 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 richly discloses irreversibility, idempotency, and rewards-card protection. However, it directly contradicts the annotation 'idempotentHint: false' by stating 'Safe to call on an already-closed card (idempotent)'. Per rule, any contradiction with annotations warrants a score of 1.

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 well-structured and front-loaded. The core purpose is stated first, followed by essential caveats, and every sentence delivers distinct, actionable information without redundancy.

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

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

Given an output schema exists, the description comprehensively covers the completion flow: irreversibility, idempotent call behavior, rewards-card additional confirmation, and the approval workflow. All three parameters are addressed in sufficient 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 schema already covers all parameters (100% coverage), providing the baseline of 3. The description adds significant value by explaining the two-phase approval_id workflow and the strict condition for setting confirm_rewards_card, both of which are not inferable from the schema alone.

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?

Starts with a specific verb and resource, 'Permanently close a virtual card', and makes the irreversible nature explicit. This clearly differentiates the tool from siblings like pause_card and resume_card, and the rewards-card caveat adds additional specificity without ambiguity.

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?

Clearly conveys this is the permanent closure tool, and gives detailed usage context for approval_id and confirm_rewards_card. However, it does not explicitly name alternative siblings (e.g., pause_card) for non-permanent actions, leaving that connection to inference.

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

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

Beyond the annotations, the description discloses that cards are live and charged for real, that vaulted cards never become a typed card number, that KYC is required only for issued cards, that users approve purchases with passkey/master password, and that OAuth-connected accounts have no card/amount limits. No statement contradicts 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 dense but front-loaded with the core purpose, and every sentence carries decision-relevant information. It is long because the tool has multiple complex paths, but there is no filler or repetition.

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

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

For an 11-parameter tool with two major funding paths, the description covers vault setup, issued cards, defaults, per-call overrides, KYC, balance shortfalls, plan limits, and sibling-tool routing. With an output schema present, return values do not need to be restated.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter and workflow meaning: per-call overrides (connected_card_id, source 'issued', restart_setup), the requirement that amount_cents is still needed on restart_setup, and how source interacts with defaults. These integrations go beyond the individual schema entries.

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 crisp statement of the tool's core job: 'get the user a virtual debit card for a purchase,' and then distinguishes the vault path, issued path, and the buy tool. It names the one-card role explicitly and separates it from siblings like buy and add_funds.

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 explicit when-to-use guidance: first-time users get the vault link; after vault_started or vault_ready, use buy instead; use source 'issued' only after the user agrees; restart_setup only for lost/expired links; top up with add_funds; call get_plan for limits. Alternatives and exclusions are spelled out.

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

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

With no annotations, the description carries the full behavioral burden, and it delivers: it states that built-in templates are refused, that existing cards keep their rules, that only the name is retired for future use, and that deletion is blocked while the name is a standing default. The only minor omission is explicit irreversibility or permission requirements, but 'delete' plus the stated constraints already disclose the essential side effects.

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

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

Three short sentences deliver the main action, the built-in-name refusal, and two important behavioral caveats without wasted words. The primary action is front-loaded, and each subsequent sentence earns its place by preventing a likely misuse.

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

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

For a single-parameter delete operation with an output schema available, the description covers the required input, refusal conditions, and side-effect scope. An agent has everything needed to decide whether to call this tool and what to expect regarding existing cards and standing defaults.

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

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

Schema coverage is 100%, so the baseline is 3, but the description enriches the 'name' parameter beyond the schema's 'The saved preset name to delete.' It clarifies that valid names come from save_preset, that built-in names are invalid inputs, and that names still used as standing defaults will be refused. This gives an agent practical validation criteria the schema alone does not provide.

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

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

The description opens with a specific verb and resource: 'Delete a preset you saved (from save_preset)', which clearly identifies this as the inverse operation to save_preset and distinct from list_presets or set_card_preset. It further distinguishes saved presets from built-in template names, so an agent can select this tool unambiguously.

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 conditions for use and refusal: it only applies to presets you saved, refuses built-in template names, and is refused while a card still inherits the name as a standing default. It does not explicitly name sibling alternatives or say 'use list_presets to find valid names', but the exclusion conditions effectively guide when this tool should and should not be called.

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?

Discloses that the tool provisions the balance account on first use, a behavioral trait beyond annotations. Explains fund flow (Apple Pay/Google Pay to USDC). Annotations are consistent.

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, front-loaded with primary purpose, efficient and waste-free.

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?

Complete description for a simple read tool with no params and an output schema. Explains balance nature, provisioning, and sibling differentiation.

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?

No parameters, so baseline 4. Description adds value by explaining what the returned balance represents and its source, compensating for lack of params.

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?

Clearly states the tool returns the user's cash balance for funding cards. Differentiates from list_cards by specifying that cards themselves are listed elsewhere, providing clear sibling 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?

Provides context that balance account is provisioned on first use and describes funding sources. However, lacks explicit when-to-use vs alternatives like get_card_balance, though differentiation is implied.

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

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

Aligns with annotations (readOnlyHint, idempotentHint, destructiveHint) and adds useful behavioral context: live balance, faster, no credential exposure. No contradictions.

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, each purposeful: first states purpose with resource specificity, second provides usage guidance. No wasted words, 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?

Complete for its purpose: explains what it does, when to use, and key benefits. Output schema exists but not shown; description covers all needed context 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?

Single parameter card_id with basic schema description 'The card ID'. Description adds 'of ONE virtual card' but doesn't elaborate on format or constraints. Schema coverage is 100%, so baseline 3 is appropriate.

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

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

The description clearly states the tool returns the live balance of a single virtual card, distinguishing it from get_balance (overall cash balance) and get_card_details (which exposes sensitive credentials).

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

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

Explicitly advises preferring this tool over get_card_details when only verifying available funds, citing speed and credential safety. Also contrasts with get_balance.

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

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

Annotations already mark readOnlyHint=true and idempotentHint=true, but the description adds critical behavioral context: it may require human approval, it returns sensitive decrypted credentials, and the data is encrypted at rest with AES-256-GCM. It also explains the two-step approval flow with approval_id. No annotation contradiction exists; the description enriches the safety profile.

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 (four sentences) and front-loaded with the core purpose. Each sentence earns its place: purpose, use-case restriction, approval workflow, and security note. No filler or redundancy.

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

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

Given the presence of an output schema (which defines the return structure) and comprehensive annotations, the description fully covers the necessary context: when to use, the approval exception flow, and the security implication of returning decrypted PAN/CVV. An agent can correctly invoke this tool with no missing information.

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% — both parameters (card_id and approval_id) are thoroughly described in the schema, including the special case for cards created through another app. The description does not add any information about parameters beyond what the schema already provides. Baseline 3 is appropriate since the schema carries the full weight.

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 exact resource and action: 'Get decrypted PAN, CVV, expiry, and current balance for a specific card.' It explicitly distinguishes itself from the sibling tool 'get_card_balance' by naming the condition for preferring it. There is no ambiguity about what the tool does or how it differs from alternatives.

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 provides explicit when-to-use guidance: 'Use this only when you need to fill in a payment form' and names the preferred alternative for balance-only queries. It also outlines the conditional approval workflow, instructing to prompt the user and call 'approve_request' if approval is required. This leaves nothing to inference.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It conveys that the operation is read-only via 'Read', discloses the output format ('plain-English summary'), and adds a valuable edge case: a card without a preset is unrestricted. It does not discuss errors or auth, but this is not a major gap for a read operation.

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

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

The description is two tight sentences with no filler. The core purpose is front-loaded, and the important 'unrestricted edge case is delivered in a single clause.

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

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

The tool is simple: one required parameter, an output schema present, and a description that clarifies behavior, return type, and the no-preset case. Nothing needed for correct invocation is missing.

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

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

Schema coverage is 100%, with card_id fully described as 'The card id (from list_cards)', so the schema already does the heavy lifting. The description adds no card_id-specific meaning beyond tying it to the preset concept, which is sufficient; baseline 3 is appropriate.

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

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

The description uses a specific verb ('Read') and resource ('a card's preset'), enumerates exactly what the preset covers (spend limits, rate limits, allowed categories/merchants, time windows, surfaces), and clarifies the output form ('plain-English summary'). This clearly distinguishes it from sibling tools like list_presets or set_card_preset.

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 makes the usage context clear: use this to read a specific card's preset and understand whether it is restricted or unrestricted. It does not explicitly list when not to use it or name alternatives like list_presets, but the singular 'a card's preset' makes the intended selection unambiguous.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by saying the guide is the 'latest' usage guide and by specifying which domains it covers, clarifying that the tool returns guidance rather than performing an operation.

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

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

One sentence, front-loaded instruction, and no wasted words. It communicates timing, content domains, and tool purpose economically. The emphasis on 'Call this FIRST' gives the most important practical information immediately.

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

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

For a parameterless, read-only, idempotent tool with an output schema and broad sibling coverage, the description is fully sufficient. It explains what the guide contains, which tool family it applies to, and when to call it. No additional setup or return-format details are necessary given the structured context.

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

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

There are zero parameters and schema description coverage is 100%, so no parameter documentation is owed. The description appropriately avoids inventing parameter details. The baseline of 4 applies for parameterless tools.

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

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

The description names a clear action ('returns the latest usage guide') and specifies its scope: shopping via `buy` and Agentcard account tools. It also positions itself as a bootstrap step, which distinguishes it from the long list of operation-specific 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 phrase 'Call this FIRST' provides explicit timing guidance for when to use the tool. It does not enumerate when-not-to-use conditions or name alternatives, but for an instruction/help tool whose alternatives are the operational tools themselves, the first-step instruction is sufficient context.

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 idempotentHint. Description adds useful behavioral info (returns state and next step), but is not essential beyond 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?

Two sentences, no wasted words. Front-loaded with purpose, followed by usage. Highly 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 zero parameters and the presence of an output schema, the description fully covers the tool's purpose, usage, and behavior. Complete for this context.

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?

Input schema has zero parameters, so schema coverage is 100% automatically. Description adds no parameter info, but none is needed. Baseline 4 for 0 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 explicitly states the tool checks KYC status, returns verification state and next step. It clearly distinguishes from sibling tools like start_kyc or submit_kyc_document.

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?

Provides explicit guidance: poll after face scan or when create_card reports kyc_required. Offers clear context for when to use.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral context beyond that: multi-use cards are a paid-plan feature, maxActiveMultiUseCards is 0 on Free, and the mint is refused. This helps the agent interpret plan data and anticipate downstream behavior when using the result with create_card.

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

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

The description is front-loaded with the core purpose and then provides targeted usage triggers. All three sentences contribute information, though the final sentence about cancel_plan is somewhat tangential to get_plan itself and could have been shorter without losing meaning.

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 tool with an output schema and strong annotations, the description is complete. It identifies what data is returned, when to call the tool, why it is needed before multi-use card creation, and how to route cancellation to a different tool. Nothing an agent needs to invoke it correctly is missing.

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

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

The tool has zero parameters and the schema is an empty object, so there is no parameter detail that needs clarification. The description still adds value by naming the returned data categories (plan, card limits, monthly usage), which is sufficient given the no-parameter 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 description states a specific verb and resource: it 'Show[s] the user's current subscription plan, card limits, and this month's usage.' This clearly distinguishes get_plan from siblings like get_balance, get_settings, list_transactions, and upgrade_plan, so an agent can select it correctly without inspecting schemas.

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

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

The description gives explicit when-to-use guidance: call before create_card when the per-card amount cap or remaining monthly quota is needed, ALWAYS before creating a multi-use card, and whenever the user asks about plan, limits, billing, or upgrading. It also names cancel_plan as the alternative for cancellation, including the note to call it by name even though it is not listed.

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, idempotentHint, destructiveHint. Description adds valuable context: what data is shown (balance, lifetime, recent activity) and explains tokenback mechanics (rate, AI card boost). No contradictions with 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?

Extremely concise (3 sentences, ~55 words). Every sentence serves a purpose: describes output, explains tokenback value, and provides cross-reference to redeem_rewards. No redundancy.

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

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

Given zero parameters, existing output schema, and annotations, the description fully covers what the tool does, what it returns, and how it fits with sibling tools. Complete for a simple read-only tool.

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

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

No parameters; baseline 4 is appropriate. Schema is empty, so description adds no parameter info, but none 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?

Clearly states 'Show the user's tokenback' with specific components (balance, lifetime earned, recent activity). Distinguishes from sibling tools like redeem_rewards, so agents know this is the read-only view.

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

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

Explicitly tells when to use this tool vs. alternatives: 'Redeem with redeem_rewards' for redemption. Also implies use for viewing reward details, not for other actions.

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 the tool read-only, idempotent, and non-destructive. The description adds valuable behavioral detail by specifying which settings are read-only (authorization settings) and that the rest can be changed via update_settings. It does not contradict annotations, and the practical guidance on using the returned data goes beyond what annotations provide, though it stops short of disclosing rate limits or pagination behavior.

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

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

The description is a single long sentence with multiple clauses, but every clause adds substantive value: it enumerates the data returned, explains the practical importance of each, and points to the update tool. It is dense but not bloated, and the front-loaded 'View the user's notification preferences' immediately orients the reader.

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 that an output schema exists, the description need not enumerate return fields. It provides rich context about the meaning and use of each data category, states that authorization settings are read-only, and references the update tool. For a zero-parameter, read-only tool, this description is fully 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 tool has zero parameters, so the schema is empty. According to the rubric, a baseline of 4 applies. The description appropriately does not attempt to document nonexistent parameters; it focuses on the content of the read operation 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 uses the specific verb 'View' and precisely enumerates the four categories of information returned: notification preferences, default payment source, default delivery address, and authorization settings. This clearly distinguishes it from sibling tools like get_balance or get_plan, and the additional context on how to use each piece of data reinforces the tool's 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 explicitly instructs when to consult the tool ('check it before picking a funding source for them', 'check it before asking them to dictate an address') and names the alternative update_settings for modifying settings. This provides both concrete triggering conditions and an explicit alternative, fully satisfying the when-to-use vs. alternatives criterion.

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 all-false annotations, the description discloses substantial behavior: the link opens in a browser, identity verification runs in the page, add_card data is never seen by Agentcard, the link is multi-use but short-lived (~15 minutes with exact time in expiresAt), and it requires OAuth. This gives the agent a full safety and lifecycle picture.

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 but every sentence carries necessary information: core purpose, when to use, parameter-specific behaviors, expiry, and the OAuth constraint. The most important information is front-loaded, and the length is justified by the tool's multiple modes.

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

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

With an output schema present, return values need no explanation. The description covers all three invocation modes, the exact use cases, the short-lived nature and expiry handling, and the OAuth limitation. Nothing an agent needs to decide when and how to call it is missing.

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

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

Schema coverage is 100%, but the description adds meaning beyond the schema: it explains that 'wallet' is the default, 'add_card' opens the vault form and works on personal logins, and merchant + amount_cents together open the payment-approval sheet. This is exactly the semantic enrichment needed for correct invocation.

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 deliverable ('the user's hosted wallet, as one shareable URL') and a clear verb ('Mint it'). It distinguishes three distinct modes (wallet, add_card, payment approval), so an agent can tell it apart from sibling card/wallet 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?

It explicitly says when to use the tool ('whenever the user needs a browser step (seeing cards, finishing verification when in-chat photos fail)') and gives specific conditions for each parameter combination. It also states a hard constraint ('only works for app connections (OAuth)'), effectively telling the agent when not to use it.

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 include destructiveHint: true, and the description goes beyond by explaining that accounts are merged (the identity-verified account survives) or the identifier is simply added if no account exists. It also details the two-step process and code verification, adding significant 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?

The description is detailed but front-loaded with the core purpose, then structured into two steps. It is slightly lengthy but every sentence adds value; no redundancy.

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

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

Given the tool's complexity (two-step process, conditional outcomes), the description covers all necessary context: when to use, steps, possible results (merge vs. add). Output schema exists but return values are not explained; however, that is acceptable per rules.

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%, but the description adds substantial meaning beyond schema by grouping parameters into steps (Step 1: type, identifier; Step 2: ticket, code) and explaining their purpose in the flow, aiding correct invocation.

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 links or merges accounts belonging to the same person, with specific verb ('link or merge') and resource ('Agentcard account'). It distinguishes from sibling tools by describing a unique operation (merging accounts) not available in 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 explicitly tells when to use the tool: 'when the user says they already have an account under a DIFFERENT email or phone number — most often after identity verification (KYC) is rejected as a duplicate'. It provides step-by-step guidance but does not mention when not to use or alternatives, slightly reducing score.

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 it as read-only, idempotent, and non-destructive. The description adds genuinely useful behavior beyond that: what makes a card 'added', how isDefault is chosen, and how create_card uses the default card when no connected_card_id is supplied.

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 sentences, each earning its place: one defines the resource, one clarifies default behavior, and one disambiguates from a sibling tool. No wasted or filler wording.

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 tool with an output schema and safekeeping annotations, the description covers all the necessary context: what the cards are, what fields are returned, how defaults behave, and how this differs from list_cards. Nothing meaningful is missing.

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

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

The input schema has zero parameters and full schema coverage, so there is nothing for the description to clarify in that scope. It still adds meaningful context about the output, especially the isDefault flag's semantic meaning, which goes beyond the bare 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?

Uses specific verb 'List' plus resource 'user's ADDED cards' and defines them as own Visa/Mastercard cards enrolled via create_card's add-card flow. Explicitly distinguishes from list_cards, so an agent can recognize the intended scope right away.

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 when this tool is relevant by tying the listed data to create_card behavior and update_settings, and explicitly names list_cards as a different tool for issued virtual cards. This gives the agent a clear decision point between the two.

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 annotations (readOnlyHint=true, idempotentHint=true), the description adds meaningful behavioral context: vault cards never expose a number and pay via device approval, while cards from other apps/companies are read-only in this session. No contradiction with 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 information-dense and front-loaded with the core purpose, followed by usage guidance and edge-case behavior. It is longer than ideal but every clause carries useful information, so it earns a 4 rather than a 5.

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?

Despite the tool having zero parameters, the output has complex semantics (wallet vs vaultCards, shared wallet behavior, source tags, read-only restrictions) that the description thoroughly covers. The empty-state action (call create_card) is also addressed, making it complete 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?

The input schema has zero parameters, so schema coverage is trivially 100%. With no parameters to explain, the description correctly focuses on output semantics rather than parameters, deserving the baseline 4 for a no-parameter tool.

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

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

The description clearly states the tool lists the user's wallet and vault cards, with specific fields (IDs, last four, expiry, balance, status). It distinguishes itself from siblings by noting how vault cards differ and which cards are read-only for get_card_details and close_card.

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 explicitly says 'Start here to find available cards' and provides a conditional alternative: 'if none are returned, call create_card.' It also explains when cards cannot be modified (shared wallet cards from other apps/companies), giving clear when-to-use and when-not 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?

Description adds details beyond readOnlyHint: includes 'when each was connected and whether it is still active'. Also explicitly states 'Read-only', consistent with 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?

Two sentences, front-loaded purpose, no waste. Every sentence adds value.

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

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

Complete description for a parameterless tool with output schema. Covers purpose, data returned, and alternative tool for revocation.

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?

No parameters exist; baseline 4 per guidelines. Schema coverage is 100% trivially, no additional param info needed.

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

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

The description clearly states the tool lists third-party apps connected via OAuth, with specific example (Kilo). It distinguishes from revoke_connection by directing to that sibling for revocation.

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

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

Explicitly says when to use (to list connected apps) and when not to (to revoke, use revoke_connection). Provides clear alternative.

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, destructiveHint=false, idempotentHint=true. The description adds context that this is for flight bookings only and that the default method is marked. No contradictions. Could add more on behavior like order or pagination, but currently sufficient.

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

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

Two sentences: first explains purpose and return structure, second provides usage alternatives. Front-loaded with key information, no redundant phrases, highly 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 the complexity (0 params, output schema exists), the description covers the tool's purpose, what it returns, and related tools. No gaps in required information for agent 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?

No parameters exist, so schema coverage is 100%. The description does not need to explain parameters, and it does not repeat schema info. The context that it returns specific fields is helpful and goes beyond the schema.

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

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

The description clearly states the tool lists saved payment methods used only for flight bookings, lists the returned fields (id, brand, last 4 digits, expiry, default), and explicitly excludes cards and adding funds, distinguishing it 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?

Provides explicit guidance on when to use this tool (listing payment methods) and when to use alternatives: setup_payment_method for adding, and set_default_payment_method/remove_payment_method for modifying. Also mentions that gated tools can be called by name despite not being in the tool list.

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?

Goes beyond annotations by emphasizing that approvals require user consent and the agent must not act on its own. Also discloses session scope. The readOnlyHint/idempotentHint align with 'list pending approvals', with no 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?

Three sentences with no filler. Each sentence adds either scope, usage rule, or session constraint; the most critical consent rule is 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?

With zero params and an output schema present, the description fully covers what the tool does, when to use it, and important guardrails. No gaps remain for an agent to select and 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?

Tool has zero parameters, so the schema is empty and there is nothing to document. Baseline for 0 params is 4; description correctly omits parameter details.

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

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

Description clearly states the tool lists the user's PENDING approval requests from connected apps with specific examples (create a card, view full card details, close/pause/resume a card, change a limit). It distinguishes from sibling approve_request by framing this as the listing step.

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?

Provides explicit guidance: surface each request and let the user decide, resolve with approve_request afterward. Also states session limitation ('Personal sessions only; company-connected sessions have no personal inbox') and the rule 'NEVER approve or deny on your own'.

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

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

With no annotations, the description carries the behavioral transparency burden. It clearly reveals what the tool returns: preset names and a plain-English summary of rules, and it discloses coverage including built-in and user-saved presets. Although it doesn't explicitly say 'read-only', the verb 'List' strongly implies a non-mutating operation.

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

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

The description is a single, efficient sentence that front-loads the core action and resource. It includes useful examples in parentheses and adds the summary detail without unnecessary 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 no-parameter listing tool with an output schema, the description is complete for invocation purposes. It tells the agent exactly what to expect in the response, and there are no required arguments or edge-case parameters left unexplained.

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

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

The tool takes zero parameters, so the baseline is 4. The description adds no parameter-specific meaning because there are no parameters to document. The input schema is empty and the description accurately reflects that, so no information is missing.

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 ('List') with a clear resource ('presets') and even enumerates the built-in templates, distinguishing this from related tools like get_card_preset or save_preset. It clearly communicates the scope: all usable presets, built-in plus user-saved, with a plain-English summary.

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 its use case: when you need an overview of available presets by name and summary. However, it does not explicitly state when not to use it or point to alternatives such as get_card_preset, save_preset, or delete_preset, leaving the choice of tool partly to inference.

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

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

Annotations already convey read-only, idempotent, non-destructive behavior, lowering the bar. The description adds useful behavioral details: 'newest first, each row tagged with its card' and the existence of gated views. It does not discuss permissions or rate limits, but the annotation set covers the safety profile.

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 sentences, each pulling weight: return content, parameter scoping/filtering, and alternative tool routing. The most important information is front-loaded, and there is no filler.

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

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

With a full output schema, read-only/idempotent annotations, and a description that covers scoping, filtering, ordering, and gated alternatives, an agent has everything needed to invoke this tool correctly. Pagination and default details are already covered by the 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 the baseline is 3. The description reinforces card_id's omit-for-all-cards semantics and the use of limit/status for filtering, but these are already present in the schema descriptions; no substantially new parameter-level meaning is added.

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

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

The description names the resource and fields ('Transactions with amount, merchant, status, and timestamps') and clarifies the two scopes (with/without card_id), so an agent can tell what the tool returns. It also distinguishes itself by naming gated sibling views, though the opening is a noun fragment rather than an explicit verb-phrase.

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 explicitly states when to pass card_id (single card) vs omit it (all cards), instructs the agent to use limit and status for filtering, and directly names the alternatives list_all_transactions and list_transactions_by_payment_method, including that they are gated and callable by name. This gives clear, actionable routing guidance.

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

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

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description adds key behavioral details: no payment taken, auto-billing, actions like skip/unskip affecting deliveries, and the need to link the merchant first. This fully compensates for minimal annotation info.

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 fairly concise given the complexity, with front-loaded purpose. Every sentence earns its place, though it could be slightly more structured (e.g., bullet lists). Still effective.

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

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

Given the tool's complexity (8 parameters, various actions), and existence of an output schema, the description covers all necessary context: actions, settings, prerequisite linking. It is complete enough for an agent to use 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?

With 100% schema coverage, baseline is 3. The description adds significant value by explaining the action enum values and providing a detailed list of settings for 'update_setting', which goes beyond the schema's brief descriptions.

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 it manages recurring meal/grocery subscriptions (e.g., Locale), explicitly distinguishes from one-time purchases, and lists specific actions. This differentiates it from sibling tools like 'buy', which are likely for purchases.

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 provides clear context: it's for subscription management, not one-time purchases, and no payment is taken. It also mentions linking the merchant first. However, it lacks explicit when-not-to-use guidance relative to siblings, though many are unrelated.

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 idempotentHint=true and readOnlyHint=false. Description adds that the closest match is saved and echoed back, and that smart_excluded does not remove the card. It also mentions user confirmation for uncertain matches, adding behavioral context beyond 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?

Three sentences, no filler. Purpose is front-loaded, id source mentioned, and flag behaviors succinctly covered. Every sentence adds value.

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

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

For a 4-parameter tool with output schema, description covers all parameters, mentions confirmation behavior, and clarifies the smart_excluded semantics. Minor gaps like exact output structure are likely covered by the 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 covers all parameters (100%), so baseline is 3. Description enhances meaning by explaining the purpose of product, clear_product, and smart_excluded in context, and clarifies that clear_product and product should not be combined. Adds value beyond 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?

Description states a clear verb ('tell the vault') and specific resource (card product for a stored card), with explicit purpose for smart purchases. It also references list_cards as the id source, distinguishing it from other card 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?

Provides guidance on when to use the flags (clear_product, smart_excluded) and mentions user confirmation. Does not explicitly compare to sibling tools like recommend_card or get_card_details, but implies usage via the id source from list_cards.

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 non-destructive and idempotent. Description adds reversibility and mentions resume_card. Also specifies that it blocks all new charges, though missing details on pending transactions.

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, front-loaded with main purpose, then constraints and parameter usage. No redundant words.

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

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

Covers action, when to use, card type constraints, and a key parameter detail. With only 2 simple params and output schema present, description is fully sufficient.

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%. Description adds critical context for approval_id, explaining the flow for cards from another app, which goes beyond schema descriptions.

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?

Clearly states 'Pause a multi-use card: temporarily blocks ALL new charges', with specific verb (pause) and resource (multi-use card). Distinguishes from siblings like close_card (permanent) and resume_card (reverse).

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

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

Explicitly states when to use: 'Right for stop this subscription for now or a card the user suspects is compromised' and when not to: 'Only multi-use cards can be paused; single-use cards... cannot be paused.'

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 annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which sufficiently convey the tool's safety and behavior. The description adds the detail about reading 'message history' but does not provide additional behavioral traits 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 a single, front-loaded sentence that conveys the essential purpose with zero waste. 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?

With a single parameter, high schema coverage, and an output schema present, the description is largely sufficient. It does not cover potential limitations like pagination or message ordering, but for a simple read operation with strong annotations, this is acceptable.

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% with a single required parameter conversation_id. The description confirms the tool reads a support conversation but adds no new meaning beyond the schema field description 'The conversation ID'.

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 the specific verb 'Read' and states the resource 'message history of a support conversation'. It clearly identifies the tool's action and distinguishes it from siblings like start_support_chat or send_support_message.

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

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

No guidance is provided on when to use this tool versus alternatives such as start_support_chat or send_support_message. There is no mention of prerequisites or context for choosing this 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 indicate read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral context: null conditions for smart purchases being off, no named card, or nothing to say; the guarantee that a card number is never returned; and the plain-words reason in the output. No contradiction with 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-loaded with the core purpose, then gives invocation hints, output shape, null semantics, and the safety note. Every sentence carries useful information without 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?

With an output schema present, the description does not need to restate return types. It covers selection context, required inputs, null behavior, fallback behavior, and a critical privacy guarantee. This is complete for an agent to decide when to call it and what to expect.

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 documents all four parameters. The description adds slight practical guidance ('when you know it' for the website, 'amount' for the total), but does not materially expand parameter meaning beyond the schema.

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

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

The description states a specific verb and resource: asking the vault which of the user's own stored cards earns the most for a purchase. It clearly scopes the tool to smart-purchase recommendation and distinguishes it from related tools like list_cards and name_card. The return value (card id, reason, runners-up) is also explicitly stated.

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 tells the agent what to pass (merchant name, website when known, amount) and how to interpret null results, including paying as usual. It points to name_card when no stored card has been named. It does not broadly compare against other sibling tools, but the usage context is clear enough for selection.

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

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

Beyond annotations (readOnlyHint=false, idempotentHint=true), the description discloses critical behaviors: credit lands within 1-2 minutes, some codes are gated on KYC approval, the claim locks instantly, and list_codes is a gated tool accessible by name. This adds significant context not present in structured fields.

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

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

The description is front-loaded with the core purpose and uses three sentences, each earning its place. The second sentence explains timing and KYC exceptions, the third offers a useful pointer to list_codes. No wasted words.

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

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

The description fully covers what an agent needs to know: purpose, idempotency, delay, KYC dependencies, and a hidden tool reference. An output schema exists to explain return values, so no additional return-format information is required.

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 covers the only parameter (code) with a clear description that case and dashes are forgiven. The tool description adds no additional parameter syntax, but it does provide behavioral context such as idempotency and KYC gating. This 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 opens with a specific verb and resource: 'Redeem a promo code that adds money to the user's cash balance.' This clearly states what the tool does and distinguishes it from similar siblings like redeem_rewards or add_funds by focusing on promo codes and cash balance.

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

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

The description implies when to use (when a user provides a promo code) and adds contextual guidance (each code works once per user, delay, KYC conditions). It also mentions list_codes as an alternative for viewing history, but does not explicitly exclude other tools or name alternatives for redeeming.

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 details beyond annotations: tokens convert at a fixed rate, the rewards card is permanent, locked to specific merchants, created on first redemption, and topped up afterward. Since annotations only indicate non-read-only but don't specify effects, these details add significant transparency. It could further mention irreversibility but is not required for basic use.

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

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

The description is three sentences, front-loaded with the core action and effect, then a key restriction, then brief usage guidance. Every sentence adds essential information with no redundancy or fluff, making it highly concise and well-structured.

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

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

For a one-parameter tool with an output schema, the description covers all essential aspects: what happens, conversion rate, card behavior, merchant restriction, prerequisite check, and user consent. It doesn't explain every edge case but points to get_rewards for balance/minimum, which is sufficient for correct invocation. This is complete for 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 input schema for the single parameter 'tokens' already provides a full description including the conversion rate and an example, giving 100% coverage. The tool description repeats the rate but adds no new parameter-level constraints or format details. Therefore, it meets the baseline for schema-covered 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 clearly states the tool's purpose: 'Redeem tokenback' with a specific conversion rate and effect on the rewards card. It distinguishes itself from sibling tools like redeem_code and withdraw by describing the unique reward card mechanism and AI-lab merchant restrictions. The verb 'redeem' plus the specific resource 'tokenback' makes the purpose unambiguous.

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

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

The description provides clear usage context: 'Check get_rewards first for the balance and the minimum' and 'Ask the user before redeeming.' This gives a prerequisite and consent requirement, but it does not explicitly name alternatives or when-not-to-use conditions, so it stops short of a 5. The guidance is still effective for 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?

The description discloses critical behavioral consequences beyond what annotations indicate: virtual cards are closed first, the card is unenrolled at the network, and removal is irreversible for that enrollment. This aligns with destructiveHint and adds valuable context for the agent.

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 tight and information-dense: core action, irreversibility, side effects, user confirmation requirement, id source, and re-enrollment path all fit into a few sentences without unnecessary 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?

The description fully covers the tool's purpose, prerequisites, side effects, user-confirmation requirement, and recovery path. With the output schema present, no critical context is missing for an agent to safely use this destructive 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 already fully describes attached_card_id with 100% coverage, so the description does not need to carry much parameter burden. It does reiterate the source of the id (list_added_cards), which is helpful but not significantly beyond the schema.

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

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

The description clearly identifies the action as removing/unenrolling one of the user's added cards, which is a specific verb-resource combination. It sets this apart from sibling tools like close_card or pause_card by focusing on removal of an added card enrollment.

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

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

Explicitly says to always confirm with the user before calling, tells the agent to obtain ids from list_added_cards, and explains that the card can be re-added later using create_card with restart_setup: true. This is practical, actionable guidance for correct invocation.

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 non-read-only, non-destructive, and idempotent behavior. The description adds that the card will 'accept charges again,' but does not cover the two-step approval flow hinted by the 'approval_id' parameter, leaving a behavioral gap.

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

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

The description is extremely concise, with two sentences that front-load the main action and efficiently link to the sibling tool. Every sentence serves a purpose.

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

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

Given the tool's moderate complexity (2 parameters, one with conditional usage), the description plus schema covers the essential behavior. However, omitting a summary of the two-step approval pattern (for cards from another app) is a minor completeness 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 schema covers both parameters with descriptive comments (100% coverage). The description adds no additional meaning beyond what the schema already provides, so it meets the baseline but does not exceed it.

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 ('Resume a paused multi-use card'), the resource ('paused multi-use card'), and distinguishes from the sibling 'pause_card' by calling itself the inverse.

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 provides clear context by referring to 'pause_card' as the inverse, implying it is used after pausing. However, it does not explicitly state when not to use it or mention alternatives like 'close_card'.

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 that the action is destructive (aligning with destructiveHint=true) and adds details beyond annotations: it invalidates tokens and requires reconnection via OAuth. No contradiction with 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?

Two sentences, front-loaded with the primary action, no redundant information. 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?

Given the tool's simplicity (1 param, full schema coverage, output schema present), the description covers purpose, behavior, and parameter source completely. No gaps.

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

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

Schema coverage is 100% for the single parameter, so baseline is 3. The description adds value by specifying the source of the client ID ('from list_connections'), which helps the agent determine the correct value.

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

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

The description clearly states the action ('Revoke a third-party app's access'), the resource (user's Agentcard account), and the mechanism ('Disconnects the app and invalidates its OAuth tokens'). It distinguishes itself from sibling tools like list_connections by specifying the required input source.

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 explicitly tells the agent to 'Pass the clientId shown by list_connections', providing clear usage guidance. While it doesn't list when not to use it, the context of revoking access versus other actions 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?

No annotations are provided, so the description carries the full transparency burden. It discloses a non-obvious versioning behavior: re-saving a name adds a new version, existing cards keep the old one, and new cards get the update. It also warns against built-in names and clarifies that either rule fields or a privileges array can be passed, going beyond what the schema states.

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

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

The description is three short sentences with no redundant wording. It front-loads the primary purpose, then covers versioning semantics, naming constraints, and input options in a clear, efficient order.

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 15-parameter creation tool with an output schema, the description covers all essential invocation decisions: what to pass, which names to avoid, how re-saving behaves, and the alternative input path. Return-value details are delegated to the output schema, so nothing critical for a correct call is missing.

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

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

Schema description coverage is 100%, so the baseline is already met. The description adds the crucial either/or relationship between the rule fields and the raw privileges array, which is not obvious from the schema alone. It also provides a high-level grouping of the rule fields (spend caps, restrictions) and a name constraint for the required parameter, adding meaningful semantic guidance.

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

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

The description opens with 'Save your own preset' and immediately explains that it creates a named, reusable set of rules for use in set_card_preset or create_card. It clearly distinguishes this tool from sibling tools by framing it as an authoring action rather than an assignment action, and explicitly contrasts with built-in presets.

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 explicitly states that the saved preset is reused by name in set_card_preset or create_card, signaling when this creation step is needed. It also gives a concrete constraint ('Pick a name other than the built-ins') and clarifies the two input modes. It doesn't contrast with list_presets or delete_preset, but that omission is minor for invoking this tool 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 indicate readOnlyHint=false, destructiveHint=false, etc. Description adds no behavioral context beyond annotations. No disclosure of permissions, rate limits, or side effects.

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

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

Single sentence that efficiently conveys purpose. No extraneous information.

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

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

Adequate for a simple tool with output schema and fully described params. Lacks usage guidance and behavioral details, leaving gaps for an AI 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?

Schema coverage is 100% with descriptions for both parameters. However, descriptions are minimal ('Your message', 'The conversation ID'). Description adds no extra meaning beyond schema, so baseline is appropriate.

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

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

Description clearly states verb 'Send' and resource 'message' in context of 'existing support conversation'. It is specific but does not differentiate from sibling tools like 'read_support_chat' or 'start_support_chat'.

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

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

No when-to-use or when-not-to-use guidance. No mention of alternatives despite having similar sibling tools. Agent must infer usage from name alone.

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

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

The description discloses several important behaviors beyond the schema: clearing a preset stops Agentcard-side checks but leaves any existing card network limit intact, edits create a new version, and the response reports what was applied on Agentcard vs the card's spend limit and whether a new card is needed. With no annotations provided, this behavioral context is valuable. It could be slightly richer (e.g., whether the operation is reversible or requires special permissions), but it covers the key side effects.

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 but well-organized: it opens with the core action, then enumerates input forms, then explains clearing behavior, then notes versioning and response contents. Every sentence adds information. It is slightly long but justified given the complexity of the preset parameter's polymorphic nature.

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 a tool with two parameters, full schema coverage, and an output schema. It explains the input forms, the clearing semantics, the versioning side effect, and what the response reports. The only minor gap is that it doesn't explicitly state the return type or error conditions, but the output schema presumably covers the response structure, and the description covers the behavioral nuances.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds meaning by explaining the semantics of the preset parameter in more depth: the accepted forms (template name, saved preset name, comma-separated list, inline JSON) and the clearing behavior with null or empty string. This goes beyond the schema's oneOf definition, though the schema already covers the structure.

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

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

The description clearly states the tool's purpose: 'Update a card's preset.' It then enumerates the accepted input forms (template name, saved preset name, comma-separated list, inline JSON) and the clearing behavior, which distinguishes it from sibling tools like get_card_preset, list_presets, save_preset, and delete_preset. The verb 'update' plus the resource 'card's preset' is specific and unambiguous.

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

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

The description explains what inputs can be passed and how to clear a preset, which implies when to use it. It references list_presets as the source for saved preset names, giving a clear prerequisite. However, it does not explicitly state when NOT to use this tool versus alternatives like save_preset or delete_preset, so it falls just short of a 5.

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 key behavioral traits beyond the minimal annotations: the fare is charged via a hold at booking, no virtual card is created for flights, and it returns a secure checkout URL. It also clarifies what the tool does NOT do, which is important given the annotations provide no safety or side-effect information.

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 composed of three concise, information-dense sentences. It front-loads the primary purpose, then provides exclusions and an alternative, and ends with the return value. Every sentence earns its place with no redundant 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?

Given the tool has no parameters but does have an output schema, the description is complete: it states the action, the specific use case, what it does not do, and the return value. It also references a sibling tool for alternative behavior, making it fully self-sufficient for an agent to select and invoke.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter syntax, but it adds contextual meaning about the tool's purpose and return value, which helps the agent understand the invocation context.

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 ('Save') and resource ('payment method') plus a clear scope: used ONLY to pay for flight bookings. It distinguishes itself from sibling tools by explicitly stating it does not fund cards or cash balance, which sets it apart from tools like add_card and add_funds.

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 guidance: this tool is for saving a payment method for flight bookings only. It provides an explicit exclusion ('does NOT fund cards or the cash balance') and names the alternative tool ('see add_funds'), making it clear when not to use this tool and what to use instead.

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?

Adds detailed behavioral context beyond annotations: explains the interactive process, which fields are automatically read vs. asked, that occupation/income are never asked, and the return value structure (next step, upload options, hosted URL). No contradiction with 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?

Packs much information but includes instructions to the agent ('Relay each step as one short message') that could be considered extraneous. Front-loaded purpose, but could be more concise.

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 identity verification, the description covers the process, input constraints, and expected outputs. Output schema exists to define return values, so description need not detail them.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by clarifying that 'terms_accepted' is deprecated and 'agreements_accepted' expects specific keys (e_sign, etc.), and explains the acceptance process.

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?

Clearly states 'Begin (or resume) identity verification.' Describes the conversational flow and differentiates from siblings like check_kyc_document or submit_kyc_fields by specifying this is the initial step.

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?

Describes when to use (starting/resuming KYC) and provides conversational guidance, but does not explicitly state when not to use or mention alternatives among 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 show readOnlyHint=false and destructiveHint=false; description adds that tool is rate-limited, returns masked destination and whether code was sent, and explains behavior when phone is already verified. No contradictions.

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

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

Single well-written paragraph that front-loads the main action and includes all necessary details without fluff. Could be slightly more structured, but efficiently conveys all key information.

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

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

Given no parameters and presence of output schema (inferred), description covers return values, next step (verify_phone), and contrasts with sibling tools. Completely sufficient for correct invocation.

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

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

Input schema is empty (0 params), baseline 4 per instructions. Description does not need to add parameter info, but does not provide extra semantics beyond 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?

Description clearly states the tool sends a one-time verification code, distinguishes it from add_funds (which auto-sends) and verify_phone (next step). Specific verb 'send/re-send' and resource 'verification code' are explicit.

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

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

Explicitly says to use only to re-send when code never arrived, mentions rate limits, that unexpired codes still work, and when phone is already verified to go straight to add_funds. Provides clear when-to-use and when-not-to-use.

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 provide idempotentHint=true, but the description says 'start a new conversation', which may imply non-idempotent behavior. No additional context on side effects, authentication, or conversation limits is given, so transparency is moderate.

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, efficient sentence with no wasted words. It is front-loaded and gets to the point, though it could be slightly more 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 simple tool with one parameter and output schema, the description is sufficiently complete for an AI agent to use. Missing behavioral clarifications are minor given the annotations.

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

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

The single parameter 'message' is fully described in the schema with clear meaning. The description adds no extra detail, so the baseline of 3 applies due to high schema coverage (100%).

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 'start' and resource 'support conversation', and specifies the action of sending the first message. It distinguishes itself from sibling tools like 'send_support_message' (for existing conversations) and 'read_support_chat'.

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 (initiate a new chat), but lacks explicit guidance on prerequisites or alternatives. However, the context from sibling tools provides enough distinction for an AI 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?

Goes well beyond annotations: discloses automatic detection, the need to show extracted fields to the user, the failure meaning, supported formats and size limit, and HEIC/HEIF conversion requirement. Annotations are only boolean hints; this text supplies the real behavior.

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

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

Dense but structured with (a)/(b)/(c), and every clause carries operational value. The most important constraints (don't ask type/country, show extracted fields, failure handling) come after the input-method breakdown; no filler or repetition.

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

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

Given the tool's complexity (8 params, multiple input modes, user-interaction constraints) and an available output schema, the description covers all deciding factors: when each input form applies, file requirements, and how to interpret/respond to results. No critical gap 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 100%, and the description still adds meaning: front_base64 must be programmatically obtained and never reconstructed; document_type/issuing_country should only be passed when the user volunteered them; back barcode accuracy; local-only paths. This materially improves parameter selection beyond the schema.

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

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

Description states a specific action—submit the user's ID photo for identity verification—and distinguishes among three input modes (base64, local file path, upload link). The wording clearly separates this from similar KYC siblings like submit_kyc_fields/check_kyc_document by emphasizing automatic detection and submission of the photo itself.

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?

Provides explicit when-to-use routing by source of image data: (a) programmatic bytes, (b) local stdio paths, (c) otherwise upload link. Also gives when-not-to instructions: never ask document type/country, only ask if result says type undetermined, and never insist an unreadable image was an ID.

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