Palmyr

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

No annotations provided, so description carries full burden. It reveals the two-call payment protocol via 402 challenge and that pricing is per server type. This adds significant behavioral context beyond the schema. However, it does not mention potential irreversible costs or failure scenarios.

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 front-load the core action and then add pricing/payment context. No redundant or unclear phrasing. Every sentence contributes valuable 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?

The description covers the overall flow (deploy, optional install, payment pattern) but lacks details on post-deployment output (e.g., IP address, SSH access) and error handling. No output schema exists, so description should have covered return behavior more. Missing explanation for 'location' and 'sshPublicKey' parameters.

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 71%, so baseline is 3. The description adds value by explaining the payment flow (402 challenge) and clarifying the optional auto-install of recipes like 'openclaw'. This goes beyond the schema's parameter descriptions for 'install' and 'payment'. Two parameters ('location', 'sshPublicKey') remain unaddressed.

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 deploys a cloud VPS keyed to the user's wallet, optionally auto-installing software. The verb 'deploy' and resource 'cloud VPS' are specific. Sibling tools are all unrelated (email, phone, domain, social), so no 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?

Description implies usage for deploying VPS instances but provides no explicit when-to-use or when-not-to-use guidance. Prerequisites like having a wallet are mentioned indirectly but not clarified. No comparison to alternatives, though siblings 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?

No annotations provided, so description bears full burden. Reveals that the tool is free and requires no payment, but does not disclose rate limits, authentication needs, or response format (e.g., whether it returns availability as boolean or includes pricing details). Adequate but incomplete.

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?

Exceptionally concise: two sentences without filler. Front-loads the core action and important details (free) immediately. Every sentence adds unique 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 simple tool with one parameter and no output schema, the description covers the key usage contexts (input types and cost). Lacks mention of output structure, but the tool is straightforward and the sibling tool 'domain_register' implies a typical check-before-register workflow.

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 a clear description of the 'domain' parameter. The description adds valuable context: that bare domain names trigger scanning across popular TLDs, which is not evident from the schema alone. Enhances understanding of parameter behavior.

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?

Specifically states 'Check domain availability and per-TLD pricing', includes input variations (full domain or bare name), and implicitly distinguishes from sibling tool 'domain_register' which is for registration. No 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 instructs to pass a full domain or bare name and notes that bare names trigger scanning of popular TLDs. Context suggests use before registration, but does not explicitly state when not to use or mention alternatives (though sibling names imply distinction).

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 burden. It transparently describes the x402 payment protocol, including that the first call returns a 402 challenge with a quote. It could further mention error behaviors (e.g., domain already taken), but the fundamental two-step mechanism is well disclosed.

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 sentence states the primary purpose, second explains the payment flow. No redundant words, information is front-loaded. Perfectly concise for the content.

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 output schema, the description hints at the return (402 challenge) but does not formally describe the response format. It is complete enough for an agent to understand the workflow but could mention expected response details for the first call.

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 critical context beyond the schema: it explains that 'payment' is optional and should be omitted on the first call to receive payment instructions, and that it is a base64 x402 payload. This turns the schema into a usable workflow.

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 'Register' and resource 'domain to your wallet', distinguishing it from domain_check. The payment flow is also explained, making the tool's purpose 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 the two-step payment process (first call without payment, then with payment) and mentions pricing per TLD. However, it does not explicitly advise using domain_check first to check availability, which is a sibling tool. This minor omission prevents a perfect 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?

Discloses cost of 2.00 USDC and payment method (x402), key behavioral traits for a creation tool. No annotations exist, so description carries full burden. Could mention that custom domains auto-set MX/SPF/DKIM (hinted in schema but not description).

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 covering purpose and cost, front-loaded with the primary action. No extraneous text.

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 creation and cost, but does not specify return behavior (e.g., what is returned after provisioning) or prerequisites (e.g., wallet requirement). For a tool with no output schema, more detail on response would be helpful.

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

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

Schema coverage is 80%, so parameters are mostly documented. Description adds 'keyed to your wallet' context and clarifies name/domain usage, but does not significantly augment schema information beyond that.

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 provisions an email inbox with a specific domain, and distinguishes from sibling tools (email_read_messages, email_send) by focusing on creation. The verb 'provision' and resource 'email inbox' are specific.

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 (creating an inbox) but does not explicitly exclude scenarios or mention alternatives. It provides cost context, which aids decision-making, but lacks direct usage boundaries.

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 provided, so description carries full burden. It discloses per-action cost, decrypted nature of messages, and requirement that payment wallet matches inbox. This goes beyond a simple 'read messages' statement.

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. Purpose is front-loaded, and payment guidance is efficiently integrated.

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

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

No output schema, but description covers key behavioral aspects. Lacks details about return format (e.g., list of messages with fields), but for a simple read tool with well-documented parameters, it is mostly 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%, but description adds value by explaining the payment parameter's behavior on first call. This contextualizes how to initiate the payment flow, which schema alone does not convey.

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 ('Read decrypted messages') and the resource ('inbox you own'). It distinguishes from sibling tools like email_create_inbox and email_send, which have different purposes.

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

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

Provides explicit guidance on payment: costs 0.02 USDC per-action via x402, and instructs to omit payment parameter on first call to get payment instructions. Does not explicitly state when not to use this tool, but 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?

No annotations are provided, so the description carries full burden. It discloses the cost and payment method but does not describe return values, side effects, or the two-step payment process. It's adequate but not thorough.

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 (two sentences) and front-loaded with the core action. Every word adds value with no wasted space.

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 6 parameters, a payment flow, and no output schema, the description is too sparse. It omits critical context like the two-step x402 payment process (first call without payment, then with payment) and required permissions. This hinders 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?

With only 50% schema description coverage, the description should add meaning. It mentions cost related to the payment parameter but does not explain other parameters beyond what the schema already provides. The payment flow is hinted but not clarified.

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 (Send) and the resource (an email from an inbox you own). It distinguishes from sibling tools like email_create_inbox and email_read_messages by specifying ownership and action.

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 implicit context: you must own an inbox, and the action incurs a cost via x402. However, it does not explicitly state when to use vs. alternatives or mention prerequisites like creating an inbox first.

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 burden. It discloses that the tool costs 0.10 USDC per plan, paid per-action via x402, and that it returns an ordered list of x402 calls. It does not contradict any annotations (none provided), and adds useful context beyond schema 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 extremely concise: two sentences that immediately convey the tool's function and key behavior. Every sentence earns its place; there is no 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?

Given the tool's complexity (8 parameters, 2 required, nested objects) and lack of output schema, the description is brief but covers the high-level purpose and payment model. It does not explain what happens on failure, response formats, or error handling, which for a planning tool might be insufficient for an agent to use correctly without additional 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?

The schema description coverage is 75% (6 of 8 parameters have descriptions). The description does not add parameter-specific details beyond what the schema provides, so it meets the baseline. No additional semantic guidance is given for parameters like 'params' or 'constraints'.

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 purpose: 'State an intent, get a priced execution plan.' It explains that the i402 orchestrator converts natural language into a list of x402 calls, distinguishing it from sibling tools that perform individual actions like domain registration or email creation.

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 indicates when to use the tool ('state an intent, get a priced execution plan') and mentions the cost. However, it does not explicitly state when not to use this tool or compare it with alternatives. For example, it does not say to use this for multi-step goals and individual tools for single 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?

No annotations exist, so description carries burden. It indicates a read-only listing and is free, but does not disclose potential side effects, rate limits, or output format. Adequate for a simple catalog tool.

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, extremely concise with no wasted words. Front-loaded with key action and resource.

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 tool with no output schema, the description is functional but could clarify what 'capabilities' means and the output format. Given sibling tools, more context on the intent-resolver catalog would help.

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 has no parameters and coverage is 100%. Description adds no parameter info, which is acceptable as none are needed. Baseline 4 applies.

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

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

Clearly states it lists the i402 capabilities, with verb 'list' and resource 'i402 capabilities'. Distinguishes from sibling tools which are action-oriented (deploy, check, register, etc.).

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?

Mentions it's free, implying low cost, but does not explicitly state when to use this vs alternatives. No exclusions or prerequisites provided.

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

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

With no annotations, the description effectively communicates a read-only, free listing operation. It mentions 'live' pricing, indicating real-time data. No destructive or costly behavior is suggested. It could mention rate limits or data freshness, but for a simple listing, it's adequate.

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. Essential information is front-loaded: what the tool does, the currency, and that it's 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?

Given the tool's simplicity (no parameters, no output schema), the description is largely complete. It lacks explicit detail about the output structure (e.g., fields, format), but the implied list of capability names and prices is sufficient for most uses.

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 no parameters, so the description must provide all meaning. It clearly explains what the tool returns: a list of paid capabilities with prices in USDC on Solana/Base. This fully compensates for the empty 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 every paid Palmyr capability with its live x402 price, distinguishing it from the sibling 'palmyr_capabilities' which likely lists capabilities without pricing. The verb 'list' is specific and the resource 'paid Palmyr capability and its price' is well-defined.

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 use when pricing information is needed and notes it's free. However, it does not explicitly mention when not to use it or point to alternatives like 'palmyr_capabilities' for non-paid capabilities.

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 burden. It discloses the cost and payment method, but does not mention permissions, rate limits, destructive behavior, or failure cases. Adequate but not rich.

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 with essential information (provision, capabilities, cost, payment). No fluff, front-loaded, efficient.

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

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

Given no output schema and 3 parameters, the description is fairly complete: covers action, cost, payment. Missing return value information (e.g., what is returned after purchase) but siblings provide 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?

Schema coverage is 67% (country and payment described, areaCode not). The description adds minimal param info beyond repeating 'base64 x402 payment payload' context; no extra guidance on usage flow for payment parameter.

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

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

The description clearly states the verb 'provision/buy', the resource 'real phone number', and its capabilities 'SMS + voice'. It distinguishes from sibling tools like phone_read_messages and phone_send_sms by indicating this is the acquisition 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?

The description implies usage when a new phone number is needed, but lacks explicit guidance on when to use versus alternatives or prerequisites. The cost and payment mechanism are mentioned, which helps 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?

Discloses cost (0.02 USDC) and the x402 two-step payment process (omit payment on first call to receive instructions). However, it does not reveal what happens after reading (e.g., message retention, idempotency, error handling), and no annotations are provided to compensate.

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

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

Two short sentences, each adding essential information. First sentence states purpose, second gives cost and payment protocol. 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?

Covers core usage (read messages, cost, payment flow) but lacks details about output format, message ordering, or limits. No output schema exists, so the description should provide more context about what is returned.

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 meaning: 'base64 x402 payment payload (X-PAYMENT); omit on first call to receive payment instructions' and 'Phone number id returned by phone_buy_number'. This clarifies the workflow beyond the schema's generic 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 the verb 'Read' and resource 'SMS messages on a phone number you own'. It distinguishes from sibling tools like phone_send_sms and phone_buy_number by focusing on reading already received messages.

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 explicit guidance on when to use this tool versus alternatives like email_read_messages or phone_send_sms. The only usage hint is the cost and payment flow, but no conditions or prerequisites are mentioned.

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 description must carry burden. It reveals cost and payment mechanism, but does not mention other behaviors such as rate limits, success/failure indications, or the payment flow (e.g., first call returns instructions). The payment parameter hint in schema covers the flow, but description itself lacks this detail.

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

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

Description is a single concise sentence that includes purpose and cost. It is front-loaded with key info, though no additional structure is needed.

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 straightforward SMS sending tool, the description covers main points. However, it could explicitly state the requirement for a phone number ID from phone_buy_number and mention the payment flow. The absence of output schema means return values are not described, but that 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 75% (3 of 4 params described). The description adds context about cost and ownership but does not directly explain parameter meaning beyond what the schema provides. Baseline 3 is appropriate given high 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?

Description clearly states the action (send SMS), the resource (from a phone number you own), and includes cost information. It distinguishes from sibling tools like phone_buy_number and phone_read_messages by specifying the action and ownership.

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 cost and payment method but does not explicitly state when to use vs alternatives. The context of sending vs buying or reading is implied by tool names, but no explicit guidance on prerequisites or exclusions.

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

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

With no annotations provided, the description carries full burden. It discloses that the tool is async (returns an operation to poll), costs 0.01 USDC, and requires per-action payment via x402. This covers key behavioral aspects. However, it does not mention error handling, rate limits, or potential failures.

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 key information: action, input methods, async nature, polling, and cost. No wasted words. Each 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?

With 9 parameters, no output schema, and no annotations, the description covers core aspects: action, async behavior, payment, and video source constraints. It is nearly complete for a posting tool, though details on privacy settings, country, proxy_session_id, and error handling are missing. Sibling differentiation is implicitly clear via platform specificity.

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 56%, so description must compensate. The description adds value for video parameters by explaining the 1MB limitation of video_base64 and preferring video_url. However, it does not elaborate on other parameters like privacy, country, proxy_session_id, which remain unexplained. The description partially compensates for the coverage gap.

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

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

The description clearly states the action ('post a video') and the resource ('to a TikTok account'). It specifies the two input methods (video_base64 or video_url) and notes the async nature and payment. This effectively distinguishes it from sibling tools like twitter_post.

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

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

The description implies usage for posting videos to TikTok but does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use guidance or mention sibling tools like twitter_post. The context of control and payment is implied but not expanded.

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 burden of behavioral disclosure. It discloses the cost, payment model, and that session cookies are required. However, it does not mention rate limits, error behavior, tweet length limits, or what happens on failure. The payment flow is partly described ('omit on first call'), but overall transparency is adequate but not rich.

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

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

The description is two sentences with no waste. It is front-loaded with the action and follow-up with cost context. 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 complexity (payment integration, session cookies) and the absence of an output schema, the description is incomplete. It does not explain what the tool returns (e.g., tweet ID, success status, payment instructions format). The payment flow is partially described but missing details like error handling for payment failures. For a 6-parameter tool with no output schema, more context is needed.

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 description does not add parameter-specific meaning beyond what the input schema already provides. The schema has 67% coverage (4 of 6 parameters described), and the description only reiterates the 'cookies' and 'payment' context. It does not explain 'account_id', 'community_id', or 'proxy_session_id'—especially the latter two, which lack schema descriptions. Thus, no added 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 name 'twitter_post' and title 'Post to X (Twitter)' clearly indicate posting a tweet. The description states 'Post a tweet from an X account you control', which is a specific verb+resource. It is also distinguished from sibling tools like tiktok_post.

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 mentions the cost and payment mechanism, which are important usage context. However, it does not explicitly state when to use this tool versus alternatives (e.g., when not to use it), nor does it provide guidance on prerequisites beyond session cookies. The usage is implied by the tool's purpose but lacks explicit direction.

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