Clearvoyance

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

Annotations already declare idempotentHint=true, which the description reinforces. It adds value by explaining that re-running yields the same report and that sandbox campaigns get an illustrative sample report (marked sample: true), which is not in the annotations. This helps set expectations about output in different contexts.

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 at three sentences, front-loads the main purpose and output, and efficiently covers key behavioral nuances without fluff. Every sentence adds unique value, making it well-structured for quick parsing by an agent.

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 complexity (AI analysis) and available structured signals (output schema, annotations for idempotency), the description fully covers what an agent needs to know: main action, output, idempotency, and sandbox behavior. There is no ambiguity about input or output expectations.

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

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

The input schema already has 100% coverage, with descriptions for both apiKey and campaignId. The description does not add additional parameter-level details, so it relies on the schema. Baseline 3 is appropriate because the schema adequately documents the 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 that this tool runs AI analysis over all answers and produces an executive summary with themes, sentiment, and quotes. It also differentiates itself from the related get_campaign_results by noting the report is also included there, helping an agent distinguish between generating the analysis and retrieving existing results.

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 notes when to run it (to generate a fresh analysis) and that re-running with no new answers returns the same report, implying idempotency. It also names get_campaign_results as a related tool where the report is available, guiding the agent on alternatives.

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 adds meaningful behavioral context beyond the annotations: 'Safe to call repeatedly; credits at most once' clarifies the idempotency and the side effect of crediting. This is consistent with idempotentHint=true and readOnlyHint=false, and no contradiction exists.

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 sentences with no filler. The core purpose is front-loaded, and the behavioral note about repeated calls earns its place.

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

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

For a simple two-parameter status check with an output schema, the description plus annotations cover the essential behavior and side effects. It could be slightly richer by explicitly naming create_card_topup as the source of sessionId or distinguishing verify_payment, but nothing critical 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?

Both parameters are fully documented in the schema, including format hints (cv_live_…/cv_test_… and cs_…). The description itself adds no additional parameter-level meaning, so the baseline of 3 applies.

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

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

The description clearly states a specific action ('check') on a specific resource ('card top-up session') and defines the outcome ('paid and credited'). It is distinguishable from create_card_topup by direction, though it does not explicitly differentiate itself from the similarly named verify_payment sibling.

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

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

The description conveys the condition it answers and notes that repeated calls are safe, which implies a polling/status-check use case. However, it never names alternatives such as verify_payment or get_ledger, nor does it state when not to use this tool, leaving the agent to infer routing 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?

Beyond the annotations, the description discloses refund ordering (newest top-up first), Stripe fee bearing, the credit-retention and key-revocation lifecycle, sandbox behavior, and what to do if Stripe does not answer. It does not contradict any annotation and even reinforces idempotency by saying to call again to finish.

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 sentence carries operational or safety-relevant information, and it is logically ordered from refund policy to call procedure to prerequisites to edge cases. The most decision-relevant facts are front-loaded.

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

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

For a destructive, finance-affecting tool with an output schema, the description covers the full lifecycle: prerequisites, preview semantics, finalization, fee handling, refused refunds, credit behavior, key revocation, sandbox behavior, and retry on Stripe failure. Nothing needed for correct invocation is left implicit.

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

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

The schema already documents both parameters at 100% coverage, so the baseline is 3. The description adds useful parameter-level nuance for confirm: it clarifies that omitting it previews per-card refunds, moves nothing, and should precede the final confirm, while also stating the refund order and fees that affect what the confirm call will do.

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 exact operation (close account) and the precise side effect (refund remaining balance), which separates it from sibling close_campaign. It also front-loads the action rather than restating the title, so an agent can immediately identify the tool's role.

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 an explicit two-step protocol: call without confirm to preview per-card refunds, then call with confirm: true only after the account owner agrees. It also states the prerequisite that every campaign must be closed first, effectively routing the agent to close_campaign before using this tool, and adds sandbox and retry 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?

The description adds meaningful behavioral context beyond the annotations: pricing was charged at launch so no refund is issued, and closing twice changes nothing, which aligns with idempotentHint. It also reinforces the destructive nature by stating no more answers will be accepted.

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?

Four short, information-dense sentences cover the action, refund implications, automatic closing behavior, and idempotency. The main effect is front-loaded and no sentence is 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 is complete for an agent deciding whether and how to call the tool: it knows the effect, refund behavior, idempotency, and automatic alternatives. The schema covers parameters, and the output schema covers return expectations, so nothing necessary 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 schema already documents apiKey and campaignId fully. The description does not add parameter-level nuance beyond reference to the campaign lifecycle, so the baseline of 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 opening phrase 'Ends the campaign now: no more answers are accepted' is a specific verb plus resource with a clear behavioral outcome. It is immediately distinguishable from sibling tools like launch_campaign or get_campaign.

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 establishes when to use the tool: to end a campaign immediately and stop accepting answers. It also explains that campaigns close automatically at the cap or expiry, which gives the agent context for when manual closing is unnecessary. It does not explicitly name an alternative tool, but the usage context is clear enough.

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 are all false, so the description carries the full burden. It discloses critical behaviors: the API key is shown only once and cannot be retrieved again, sandbox mode avoids real money/email, live mode starts at $0 and requires top-up, and there's a rate limit (10 per hour per address). This is far more than typical and directly informs agent decisions about storage and expectations.

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 informative and well-structured: it leads with the most critical fact (key-once), then clarifies the account nature, then details modes and limitations. While slightly long, every sentence carries weight. It is front-loaded with essential warnings and uses clear formatting (quotes around modes). 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 (two modes, balance, rate limit, key handling), the description is remarkably complete. It covers the return value (API key once), mode-specific behavior, balance expectations, and rate limiting. The output schema is provided separately, so no need to detail the response. Nothing an agent needs to call 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?

Schema coverage is 100%, so both parameters are described in the schema. The description adds significant meaning beyond that: it explains the practical difference between 'sandbox' and 'live' modes (notional balance, key prefix, behavior on email) and the default. For 'label', it doesn't add much beyond the schema, but the schema already covers it. This exceeds the baseline for full 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 states the core action explicitly: 'Creates an agent account and returns its API key ONCE'. This is a specific verb ('creates') and resource ('agent account'), clearly distinguishing it from sibling tools like get_account (which reads) or create_campaign (which targets campaigns). It also adds clarity on what an account is ('a key and a balance'), removing 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?

The description gives clear context on when to use the tool: when you need a new agent account. It explains the two modes ('sandbox' for trying with notional balance, 'live' for real use) and the rate limit. However, it does not explicitly compare to sibling tools or state 'use this instead of X', though the purpose is unambiguous. The sandbox vs live guidance is strong practical usage direction.

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 burden — and it delivers. It discloses that accessToken is 'single-use and consumed on success,' that unclaimed rewards revert to the signer's wallet after 30 days, that INCENTIVIZED requires funding an escrow, and that NO_REWARD requires a Stripe activation fee. This exceeds what annotations would typically 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 dense but information-packed; the legacy warning is front-loaded before the core statement, and mode-specific details follow logically. There is minor redundancy — 'launch_campaign is its equivalent for the key flow' partially restates the opening routing note — but no sentence is wasted given the two-mode complexity.

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 complex 11-parameter, 6-required tool with two financially distinct modes and no annotations or output schema, this description is remarkably complete: it covers mode workflows, follow-up verification calls, single-use token behavior, claim-window refunds, privacy gating, expiry bounds, and even names the key response fields (escrow address, activationRequired).

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 genuine meaning beyond the schema: it explains the consequence of choosing each rewardMode, clarifies that minPercent gates result unlocking at a 50% floor, and warns that accessToken is consumed on success. It doesn't enrich every parameter (digitalGiftText, rewardMint, cohortEmails are left to the schema), which keeps it from a 5.

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

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

States a specific verb and resource: 'Creates a new anonymous audio feedback campaign.' It also differentiates from siblings by naming launch_campaign as 'its equivalent for the key flow' and routing new integrations to create_account — an agent can tell this tool apart without opening 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?

Gives explicit when-to-use routing: 'LEGACY wallet flow — new integrations should use create_account and launch_campaign (API key + prepaid balance, no wallet).' It further explains the required conditional follow-up workflow — call verify_campaign_funding for INCENTIVIZED or verify_campaign_activation for NO_REWARD — which tells the agent exactly what to do after invoking 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?

The description discloses critical behavioral traits beyond annotations: nothing is credited until payment, the balance is credited exactly once by whichever component sees the payment first, and the operation is not idempotent (idempotentHint=false) without saying so directly. It also notes the live-only restriction. This adds valuable context beyond the annotations and schema.

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, front-loaded with the primary purpose, then constraints, then the follow-up action. Every sentence carries meaningful information without fluff. It is dense but efficient, leaving no unnecessary 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?

With an output schema available, the description does not need to detail return values. It covers the essential flow: creation, handoff, follow-up with check_topup, and the single-credit guarantee. For a tool of this complexity, 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 schema already provides detailed descriptions for both apiKey (including prefix examples and source) and amountCents (including minimum and format). The description adds the dollar range $4.99–$1,000.00 and reiterates the live-account restriction, which is helpful but partially redundant. Given 100% schema coverage, the description adds a modest amount of extra context, so a 4 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 verb ('Creates a Stripe Checkout link') and the resource ('for a PERSON to pay with a card'), and distinguishes it from siblings by focusing on link creation rather than status checking (e.g., check_topup). It also mentions the key output 'checkoutUrl' to hand to the user.

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 specifies when to use it ('Live accounts only'), the allowed amount range, and the immediate next step ('Then call check_topup with the sessionId until credited is true'). It also explains the race condition for crediting, which guides correct usage. No alternatives are mentioned, but the workflow is 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?

There are no annotations, so the description carries the full burden, and it delivers: it discloses data deletion 30 days after first export, refers to agentDataExpiresAt for checking, excludes AI insight reports, requires sessionToken from verify_login_signature, and describes the output format. This is unusually transparent for a tool with no structured 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?

Every sentence earns its place: legacy status and alternatives are front-loaded, the core behavior is stated clearly, output format is summarized, availability and deletion policies are noted, and the auth requirement is explicit. It is information-dense but not padded.

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 having no output schema, the description explains the CSV structure, the availability window, the deletion policy, the auth requirement, and how this tool relates to alternatives. There is no essential operational detail missing 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?

Schema description coverage is 100%, with both campaignId and sessionToken already described. The description adds no significant new parameter-level detail beyond what the schema already provides, though it does reinforce the sessionToken provenance. This meets the baseline for high schema coverage 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 states a specific verb and resource: 'Exports raw response data for a completed campaign as CSV text.' It also explicitly distinguishes itself from the sibling get_campaign_results by noting that tool is the key-flow equivalent returning JSON with the AI report. This leaves no ambiguity about what the tool does.

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

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

The description gives clear when-to-use guidance: it is the LEGACY wallet flow, new integrations should use create_account and launch_campaign, and get_campaign_results is the equivalent for the key flow. It also states the availability condition ('Only available after campaign expiry') and the required sessionToken, making it easy for an agent to decide whether to call 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only nature is covered. The description adds useful context about the returned account fields, but does not describe potential error behavior or what happens with invalid keys. This is acceptable given 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 compact sentence that front-loads the resource and enumerates the key return fields without waste. Every phrase contributes 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 simple read-only, single-parameter tool with an output schema, the description is sufficiently complete: it names the resource, the lookup key, and the categories of returned data. Minor missing details like error cases are not critical given the annotations and output schema.

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

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

Schema coverage is 100% and the sole parameter apiKey is well described with an example format and provenance ('from create_account'). The description does not need to add parameter-level detail, so the baseline of 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 identifies the resource ('the account behind a key') and the key information returned: mode, balance, launch availability, and declared deposit wallet. It is clear enough to distinguish from sibling tools like get_ledger or create_account, though the verb 'get' is only implied rather than 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 implies when to use the tool: when you have an API key and need account-level details such as balance or launch availability. It does not explicitly mention alternatives or exclusion cases, so the usage guidance is present but not fully developed.

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 for behavioral disclosure. It mentions it's a read-only retrieval operation (returns config), but doesn't disclose whether any side effects occur, whether it requires authentication, or whether the returned fee is static or variable. The legacy flow is mentioned but not elaborated. Lacks detail on what happens if no config exists or if it changes.

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 moderately sized, about 3 sentences. It starts with an explicit warning (LEGACY) and the alternative. The key output details are front-loaded. A bit verbose in the middle, but efficient overall.

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 zero parameters and no output schema, the description needs to explain what the tool returns and how to use it, which it does. It covers returns, usage, and context. However, it lacks details on return format (e.g., object shape), error cases, or authentication requirements, which are relevant for a call-first 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 tool has zero parameters, so the schema provides no parameter details. The description explains what data the tool returns (treasury address, token mint, session fee), which is valuable context beyond the empty schema. It could mention the units (USDC, cents) which it does partially, and explains where to pay, but no parameters to document.

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: it returns payment configuration (treasury address, token mint, session fee) needed before starting an agent session. It uses a specific verb ('Returns') and resource ('payment configuration'), and differentiates itself from the modern flow by naming sibling alternatives (create_account and launch_campaign). However, it could be more explicit about the full scope (e.g., it's the legacy flow) in the first sentence.

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 marks this as the LEGACY flow and says new integrations should use create_account and launch_campaign instead, giving clear when-to-use guidance. It also states to call this first to learn payment details, which is a usage directive. It doesn't explicitly state when not to use it beyond legacy vs new, but the guidance is strong.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context about the exact payload (answers, invitation cap, share link, privacy threshold, price) but does not disclose additional behavioral traits such as auth requirements, rate limits, or edge cases. 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 a single, front-loaded sentence that names the resource and lists key return fields without extraneous words. The enumeration is slightly dense, but it remains an efficient and readable summary.

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 and strong annotations, the high-level summary is largely sufficient for understanding the return content. The main gap is the absence of guidance for distinguishing this tool from the many campaign-related siblings, making the contextual picture incomplete 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?

Schema description coverage is 100%; both apiKey and campaignId have clear descriptions with sources (create_account, launch_campaign/list_my_campaigns). The tool description adds no parameter-level detail, so the schema carries the full burden and 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 identifies the resource (one campaign) and enumerates the specific status information returned: status, answers, invitations/cap, share link, privacy threshold, and price. It does not explicitly name sibling tools for differentiation, so the distinction from get_campaign_details or get_campaign_results is implicit rather than 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 phrase 'One campaign' implies this is for a single-campaign overview, but there is no explicit guidance on when to use this tool over get_campaign_details, get_campaign_results, or list_campaigns. With many similar siblings, the lack of alternatives or exclusions leaves selection 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, the description carries the full burden. It discloses the legacy status, the wallet-ownership access restriction, the authentication requirement, and the read-oriented nature ('Returns'). It does not explicitly state 'does not modify anything' or describe error behavior, but the return-focused phrasing implies a read-only operation and the core behavioral constraints are well covered.

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 wasted words. The critical legacy warning and alternative are front-loaded, followed by the purpose and constraints. Every sentence earns its place.

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

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

For a simple 2-parameter read tool with no output schema, the description is complete: it tells the agent what the tool does, when to use it (and when not), what auth is needed, which resources are accessible, and what data will be returned. No critical gaps for correct invocation and selection.

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 adds value by clarifying that campaignId must reference a wallet-owned campaign ('Only campaigns owned by your wallet are accessible'), and it reinforces the origin and necessity of sessionToken. This goes slightly beyond the schema's bare 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?

States a specific verb ('Returns detailed stats'), a specific resource ('a specific campaign'), and enumerates the exact data fields (invite count, response count, completion rate, question definitions, campaign status). It also distinguishes itself from the sibling get_campaign ('its equivalent for the key flow') and from the newer create_account/launch_campaign flow.

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 this is the LEGACY wallet flow and that new integrations should use create_account and launch_campaign instead. It names the alternative for the equivalent key flow (get_campaign), states the precondition (requires sessionToken from verify_login_signature), and imposes an access constraint (only campaigns owned by your wallet).

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 adds valuable behavioral context beyond annotations: privacy thresholds (5 answers for open link, minPercent for targeted), the inclusion of a count and remaining need, anonymity by construction, conditional AI report inclusion, and a 30-day data deletion policy. This significantly helps the agent understand the tool's behavior without contradicting the readOnlyHint and idempotentHint 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, information-dense sentence that efficiently conveys all key points. It is front-loaded with the primary output ('The answers') and then adds essential details without redundancy. Though it is a long sentence, it remains readable 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?

Given the tool's complexity and the presence of an output schema, the description covers the critical contextual aspects: availability conditions, content of the response, anonymity, conditional AI report, and data retention. It does not detail error cases or exact output field names, but these are not required given the output schema exists.

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 detailed descriptions for both apiKey and campaignId. The tool description does not add any additional meaning to these parameters, focusing entirely on the output. With the schema already providing clear semantics, the description's lack of parameter info is acceptable.

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 indicates the tool returns 'the answers' for a campaign, and the title 'Campaign results' reinforces this. However, it lacks an explicit action verb like 'gets' or 'returns', making the purpose slightly inferential. It does distinguish itself from siblings by focusing on answer data, unlike other campaign retrieval 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 does not explicitly state when to use this tool versus alternatives like get_campaign_details or analyze_campaign. It mentions that the AI report is included if analyze_campaign has run, but this implies a dependency rather than a usage guideline. There is no mention of when not to use it or which sibling to choose 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description correctly aligns with a non-destructive, read-only operation. It adds behavioral detail beyond annotations by specifying the exact content (top-ups, campaign prices with set-aside and launch-charge semantics, refunds) and the ordering (newest first) plus the running balance after each row. This enriches the agent's understanding of what to expect without contradicting 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 two concise sentences that front-load the core purpose ('Every movement of money on the account') and then enumerate the transaction types and the balance-after-each-row detail. Every word earns its place; there is no fluff 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 presence of an output schema (as indicated), the description does not need to detail the return structure. It covers the essential domain semantics (transaction types and ordering) and aligns with the read-only safety profile. However, it omits any mention of pagination or behavior with large result sets, though the limit parameter partially addresses that. Overall, it is complete enough for an agent to call the tool correctly.

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

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

The input schema provides complete descriptions for both parameters: apiKey explains the key format and source, and limit includes default and range. With 100% schema description coverage, the description adds no additional parameter meaning. Baseline of 3 is appropriate since the schema carries the semantic load.

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 a ledger of all money movements (top-ups, campaign prices, refunds) with balance after each row, sorted newest first. It uses a specific verb-like framing ('Every movement of money') and distinguishes from siblings like get_account or check_topup by focusing on transactional history rather than balances or single operations.

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. It does not mention that it is the go-to for viewing transaction history, nor does it exclude cases like checking a specific top-up (check_topup) or account details (get_account). The agent must infer usage from context, and there are no explicit conditions or alternatives cited.

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 burden and does so well. It discloses that the tool returns a nonce and message string, requires signing with a Solana wallet, must be followed by verify_login_signature, and that nonces expire after 5 minutes. This is meaningful behavioral context beyond the schema.

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: it opens with the legacy warning, then states the workflow and expiry. Every sentence earns its place, with no repetition or 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 single-parameter tool with no output schema, the description is complete. It explains what is returned, what the agent must do next, how long the nonce is valid, and how this tool relates to the modern alternative flow.

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 adds only a minor behavioral tie-in by noting the wallet must sign the message, but it does not add new parameter-level meaning beyond the schema's own description of walletAddress.

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 tool as the first step of dashboard authentication, returning a nonce and message to sign with a Solana wallet. It also positions it as the LEGACY wallet flow, distinguishing it from create_account and launch_campaign for new integrations. This is specific and actionable.

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 that new integrations should use create_account and launch_campaign instead, and describes the exact workflow: call this tool, sign the message, then pass it to verify_login_signature for a session token. The 5-minute expiry also gives temporal guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that it is public (no key needed) and outlines the scope of information returned. It also explains the charging model (full charge at launch), which is domain context, not tool behavior. No contradictions, and it adds value 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 bit dense but every sentence earns its place: it covers the price structure, charging model, fee details, top-up rules, sandbox behavior, public access, and a usage directive. The core purpose is front-loaded ('The price list as data'), and it remains readable despite the breadth.

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 0-parameter tool with an output schema, this description is complete. It tells the agent what the tool returns, that it's public (no auth needed), and that it should be called first. The output schema handles the exact return structure, so 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?

The tool has zero parameters, and the schema description coverage is 100% vacuously. Per the rubric, 0 parameters earns a baseline of 4. The description does not need to explain parameters, and it doesn't.

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 price list as data' and enumerates its contents (pricing by size, fees, top-up rules, sandbox). It identifies a specific resource (price list) and a specific action (get), and the 'call this first' instruction helps distinguish it from related tools like quote_campaign.

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 'Call this first' and notes it's 'Public — no key needed', giving clear contextual guidance for when to invoke it. It does not name alternatives like quote_campaign, but the instruction to call it first serves as a de facto usage rule, making this a strong 4.

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 burden of behavioral disclosure. It discloses nonce expiration (5 minutes), compatibility constraints (dashboard-signed messages won't work), and the signing requirement (Solana wallet). This is rich, non-obvious behavioral context that an agent needs to call the tool correctly.

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 compact four-sentence block where every sentence earns its place: legacy warning, tool purpose, next step, and two critical caveats (expiry and dashboard incompatibility). It is front-loaded with the most decision-relevant information and contains no filler.

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

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

For a one-parameter tool with no output schema, the description tells the agent everything needed to execute the flow: what the tool returns, how to use the result (sign and pass to initialize_session), and the operational constraints. It is complete enough to avoid surprises.

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

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

The input schema already fully documents walletAddress as a base58 Solana public key (100% coverage), so the description adds no new parameter-level semantics. It provides surrounding context about the wallet's role in the flow, but doesn't enhance the parameter definition itself, warranting the baseline of 3.

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 this is the first step of creating a campaign session in the LEGACY wallet flow and that it returns the exact message to sign with a Solana wallet plus the nonce inside it. It differentiates from siblings by explicitly naming create_account and launch_campaign as the modern alternative, making the tool's role 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?

It provides explicit when-to-use guidance: 'LEGACY wallet flow — new integrations should use create_account and launch_campaign' and warns that a message signed for the dashboard will not work here. It also names the next step, initialize_session, so the agent knows exactly how to chain the call.

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 burden of behavioral disclosure. It reveals the legacy status, the on-chain payment requirement, the need to call verify_payment afterward, and the significant side effect that the proven wallet becomes the campaign creator and the only wallet able to read dashboard results.

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 longer than a simple one-liner, but every sentence earns its place: legacy warning, tool purpose, return value, required follow-up steps, and side effects. It is front-loaded with the most important routing information and contains 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?

For a tool with no output schema and no annotations, the description is remarkably complete. It explains what the tool returns, what the caller must do next, what the wallet binding means, and how this flow differs from the modern alternative. An agent has enough context 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 description coverage is 100%, so the baseline is 3. The description adds some contextual meaning by tying the message and signature to get_session_nonce and noting the wallet becomes the creator, but it does not substantially extend the parameter documentation already present in the schema.

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

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

The description clearly states the tool creates a new agent session via a legacy wallet flow, using a signature from get_session_nonce. It also distinguishes itself from siblings by explicitly directing new integrations to create_account and launch_campaign, so an agent can tell it apart without opening 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?

It explicitly says new integrations should use create_account and launch_campaign instead, and it outlines the full workflow: call this, send USDC on-chain, then call verify_payment. This gives clear when-to-use and when-not-to-use guidance, plus the necessary follow-up steps.

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

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

The description goes well beyond the annotations: it discloses immediate live activation, full non-refundable balance charge, sandbox behavior (inviteLinks instead of emails), and the specific error payloads INSUFFICIENT_BALANCE (shortfallCents) and INVALID_CAMPAIGN (problems[]). These are exactly the side effects an agent must know.

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: the core launch-and-charge action is in the first sentence. Subsequent sentences each add a distinct piece of behavior (modes, payment, errors) without 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-param, output-schema-backed tool, the description covers the essential behavioral contract: payment, non-refundability, sandbox mode, and error conditions. Combined with the full schema and output schema, an agent has everything needed to call and interpret the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining how kind maps to different behaviors (shareUrl vs emailed invitations), that responseCap closes the link, and that cohortEmails are used per-address – meaning beyond the bare schema definitions.

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 'Creates the campaign and makes it live at once, charging its flat price from your balance', naming the specific verb, resource, and immediate effect. It further distinguishes open_link vs targeted behavior and references quote_campaign for pricing, which separates it from sibling create_campaign and quote_campaign 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 points to quote_campaign as the price source, implying a prerequisite call, and clarifies the two modes (open_link vs targeted). However, it does not explicitly name alternatives like create_campaign for draft creation or validate_campaign for pre-flight checks, leaving the when-not-to-use guidance implicit.

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 and discloses legacy status, authentication requirement, wallet scoping, and the returned fields. It could add pagination or error behavior, but for a simple listing tool this is strong disclosure.

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

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

Every sentence earns its place: legacy routing, sibling alternative, scope, auth requirement, and return fields. The parenthetical is slightly dense but remains compact and information-rich.

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 list operation with no output schema, the description fully equips an agent: it names the auth token, scopes results to the wallet, identifies the sibling equivalent, and enumerates the returned fields. Nothing critical 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% and the only parameter, sessionToken, is already described as 'Session token from verify_login_signature'. The description repeats this meaning without adding format, expiration, or usage details 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?

States a specific verb ('Lists') and resource ('all campaigns created by your wallet'), and explicitly distinguishes this from list_my_campaigns by labeling it the legacy wallet flow. The resource and scope are 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?

Opens with explicit routing guidance: legacy wallet flow, new integrations should use create_account and launch_campaign, and list_my_campaigns is the equivalent for the key flow. It also names the prerequisite sessionToken from verify_login_signature.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about what data is returned (status, answers, share link, cost), which is beyond the annotations. However, it does not disclose any edge cases or potential caveats (e.g., whether archived campaigns are included, if there is pagination, or if the cost figure is live). With annotations covering the safety dimension, a score of 3 is appropriate.

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

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

The description is a single, efficient sentence that front-loads the core purpose ('Every campaign on this account') and packs the return details into a compact list. There is zero redundancy; 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?

The tool is simple (one required parameter), has an output schema (not shown but present), and annotations cover safety. The description provides a high-level summary of the return content. It does not specify ordering, filtering, or archival status, but for a straightforward list tool with an output schema, this is largely sufficient. The only notable gap is the lack of distinction from list_campaigns, but that falls under usage guidelines rather than 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?

The schema description for apiKey is 100% covered (it explains the format and origin). The description adds no additional parameter semantics, so it does not go beyond what the schema already provides. Per the rubric, with high schema coverage the baseline is 3, and the description does not elevate 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 states a clear verb ('list'), a specific resource ('campaigns on this account'), and enumerates the returned fields (status, answers so far, share link, cost). This precisely distinguishes it from sibling tools like list_campaigns (which might have a different scope) and get_campaign/get_campaign_details (which target a single campaign).

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

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

The description does not provide any guidance on when to use this tool versus alternatives. There is no mention of 'use this to get an overview of your own campaigns' or any comparison to list_campaigns, which likely has a similar purpose but potentially different scope. Given the many sibling tools, the lack of explicit usage exclusions leaves the routing decision to the agent's 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 declare readOnlyHint=true and idempotentHint=true. The description adds value by disclosing that the tool is free, reports all problems at once rather than just the first, and lists the specific outputs (adjustments, flat price, balance shortfall). This explains behavioral traits beyond the annotations without contradicting them.

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, front-loaded with the key purpose ('Checks a campaign BEFORE launching it'), and every phrase earns its place. The parameter caution and usage directive are concise and actionable, with no fluff 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?

This is a complex tool with 11 parameters, but the schema provides full coverage. The description covers the tool's purpose, when to use it, and a critical parameter misuse caution. Combined with the annotations (read-only, idempotent) and the output schema (present), the description is complete enough for an agent to call it correctly without additional clarification.

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 all parameters have descriptions. The description's note about passing cohortSize instead of addresses merely repeats the schema's existing 'The number, not the addresses' for that parameter. No new semantic meaning is added beyond the schema, so the baseline of 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 checks a campaign before launch, enumerating the specific outputs (problems, adjustments, price, balance coverage). It distinguishes itself from launch_campaign by saying 'Always quote before launch_campaign,' but it does not explicitly differentiate from the sibling validate_campaign. Overall, the purpose is clear and specific, though sibling differentiation is implicit rather than 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?

The description gives explicit usage guidance: 'Always quote before launch_campaign' provides a clear when-to-use directive. It also includes a specific parameter caution ('For targeted campaigns pass cohortSize (the number of people), never the addresses'), which prevents misuse. This is strong, actionable guidance that goes beyond the schema.

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 bears the full behavioral burden and meets it: it discloses that the call is free, requires no session or access token, returns all problems at once rather than just the first, explains adjustment behavior, gives the cost formula for both reward modes, and states that the endpoint never receives contact details.

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 clause earns its place: it front-loads the legacy/new integration warning, then covers behavior, return values, cost, call order, and a data-privacy guardrail. Despite its length, the information is ordered logically and contains 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?

There is no output schema, so the description must communicate what the caller gets back, and it does: validity, all problems, suggested adjustments, and cost. It also covers prerequisites, workflow ordering, and a critical data-handling constraint, making it complete enough for an agent to invoke 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%, so the baseline is 3. The description adds real semantic value beyond the schema by clarifying that cohortSize is the number of participants and not addresses, that rewardMode determines the cost formula, and that certain fields will be automatically adjusted such as expiry clamped and privacy threshold raised.

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 precise action: 'Checks a campaign BEFORE you pay for anything,' with the resource being a campaign. It also differentiates itself from siblings by calling out the legacy wallet flow and naming create_account, launch_campaign, and quote_campaign as 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?

It explicitly tells new integrations to use create_account and launch_campaign instead, names quote_campaign as the key-flow equivalent, and prescribes the exact sequence: call this first, fix reported problems, then call get_session_nonce and pay. This leaves no ambiguity about when to use 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?

With no annotations, the description carries the full behavioral burden and does well: it discloses that the call launches the campaign LIVE, sends invite emails automatically, and is idempotent/safe to retry. It does not detail failure modes or reversal options, but the key side effects are covered.

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?

Four compact sentences front-load the legacy constraint and alternative flow, then state precondition, action, side effects, and retry safety. Every sentence adds operational value and there is no padding.

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 mutating tool with no annotations and no output schema, it covers prerequisites, campaign-type restriction, required arguments, side effects, and idempotency. It could additionally state what response or callback signals success, but an agent knows how 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 description coverage is 100%, so the schema already fully documents campaignId, txSignature, and walletAddress. The description reinforces that txSignature is from the activation fee payment and mentions activationRequired from create_campaign, adding modest context without needing to repeat 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?

States a specific action: after paying the USDC activation fee, pass the transaction signature to launch a NO_REWARD campaign live. It explicitly frames itself as the LEGACY wallet flow and contrasts it with the create_account/launch_campaign path, making its role distinct from siblings.

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

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

Gives explicit when-to-use: legacy wallet users, NO_REWARD campaigns, only after activationRequired fee is paid. It also tells new integrations to use create_account and launch_campaign instead, satisfying the when-not/alternative 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?

No annotations are provided, so the description carries the full burden. It discloses that the call launches the campaign LIVE, automatically sends invite emails, and is idempotent/safe to retry. It also surfaces the legacy-vs-modern constraint, giving the agent useful 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 compact and front-loaded: it opens with the critical legacy warning, then gives the necessary sequence, side effects, and retry safety. 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 low parameter count, no output schema, and no annotations, the description is complete enough for correct invocation. It explains the prerequisite, the trigger condition, the effect, and the retry policy, leaving no critical gap.

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

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

Schema description coverage is 100%, so the input schema already documents all three parameters. The description adds sequencing context around the funding transaction, but the schema already supplies the necessary per-parameter meaning, so the baseline of 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 identifies a specific action and resource: verifying/committing funding for a campaign's escrow wallet to launch it LIVE. It also distinguishes itself from the modern onboarding path by explicitly naming create_account and launch_campaign as the alternatives for new integrations.

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: after the escrow wallet returned by create_campaign has been funded, for incentivized campaigns only. It also states when not to use it: new integrations should use create_account and launch_campaign instead, and it notes idempotency makes retries safe.

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 and discloses valuable behavior: it is a legacy auth step, returns a 24-hour sessionToken and campaign list, and requires a prior nonce. It does not detail side effects or error behavior, but the described lifecycle is unusually transparent for an unannotated 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?

Three tight sentences front-load the most important routing decision (legacy vs new), then state purpose, return value, and downstream usage. 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?

There is no output schema, so the description correctly explains the return contract (sessionToken, 24h validity, campaign list) and how to pass it forward. Combined with full schema coverage for parameters, an agent has what it needs to call and continue the flow.

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 all three parameters well. The description reinforces that message/signature come from get_login_nonce, but adds little parameter-level 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?

States a specific action ('Verifies your wallet signature against the nonce message from get_login_nonce') and positions it as the second step of dashboard authentication. The legacy-vs-new distinction further separates it from create_account/launch_campaign and from the nonce-fetching sibling get_login_nonce.

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 new integrations should use create_account/launch_campaign instead, and tells agents to invoke this after get_login_nonce. It also names the downstream tools that consume the returned sessionToken, so an agent knows both prerequisites and next steps.

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 burden and does an above-average job. It discloses the token's expiry (1 hour), single-use nature, and that it is consumed when create_campaign is called. However, it does not explicitly state whether the verification itself has side effects beyond returning a token, or failure behavior (e.g., invalid signature). It is still far more transparent than typical descriptions.

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 four sentences, each serving a distinct purpose: legacy warning, core function, token requirement, and token consumption. It is front-loaded with the most important warning. It could be slightly more compact, but there is 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?

The tool has only 2 simple parameters, no output schema, and no annotations. The description covers the return value (access token) and its critical properties (expiry, single-use), which is the key contextual information an agent needs. It does not cover error cases or prerequisites beyond the schema, but for this complexity level it is sufficiently complete.

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

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

Schema description coverage is 100%, so both parameters are already well-documented. The description adds only a slight reframing ('USDC payment') but no additional procedural context for how to obtain the parameters beyond what the schema states. 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 states a specific verb ('Verifies') and resource ('on-chain USDC payment to the treasury'), and clearly distinguishes itself from siblings by labeling the flow as LEGACY and naming alternatives (create_account and launch_campaign). The purpose is unambiguous and immediately actionable.

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 NOT to use the tool ('new integrations should use create_account and launch_campaign') and provides the context of when it IS needed (access token required for create_campaign). This gives the agent clear decision criteria without needing to inspect other tool schemas.

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