zooidfund

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

With no annotations, description fully covers prerequisites (auth, operator_acknowledgement=true) and explicitly lists what it does NOT do (KYC, identity verification, key recovery). Could improve by noting success/error behavior.

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

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

Compact, well-organized sentences. No wasted words; each sentence adds critical information (action, auth, usage condition, warning, exclusions).

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 simple parameter schema and tool complexity, description covers all essential aspects: purpose, conditions, prerequisites, and limitations. No obvious gaps.

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

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

Schema coverage is 100%, but description adds value by explaining the parameter's meaning ('explicit operator authorization') and linking to the required URLs. Justifies the const=true constraint.

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?

Clear verb 'Record acceptance' and specific resource 'current Agent Operator Acknowledgement for an already registered agent'. Distinct from sibling tools that handle donations, campaigns, 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?

Explicitly states when to use: 'Use this if get_evidence returns operator_acknowledgement_required.' Also warns against automatic invocation, providing clear 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?

With no annotations provided, the description carries full behavioral disclosure and does so richly. It enumerates the exact verification checks (network, USDC contract, recipient wallet, amount, confirmation status, tx_hash replay protection, sender match) and explicitly discloses the side effects on success: recording the donation, incrementing campaign funded_amount, and returning donation_id, status 'completed', and tx_hash.

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: two sentences, front-loaded with the flow step and required inputs, then a dense list of verification checks and effects. Every sentence contributes operational value with no filler or redundancy.

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

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

Given no annotations and no output schema, the description is substantial but still incomplete for correct invocation. It thoroughly covers success behavior and side effects, but omits failure behavior and leaves amount, reasoning, and tx_hash semantics underspecified, which an agent needs 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?

Schema description coverage is only 25%, so the description must compensate, but it merely lists the required parameter names without explaining semantics. It does not define amount units, tx_hash format, or what content reasoning should contain. Only campaign_id receives meaningful guidance, and that comes from the schema rather than the tool description.

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 confirm_donation as 'Step 2 of the MCP donation flow' and states its core action: verifying an on-chain payment and recording the donation. It specifies the verification targets and the success return values, which distinguishes it from siblings like donate and get_campaign_donations.

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 by framing the tool as 'Step 2' and requiring campaign_id, amount, reasoning, and tx_hash, implying use after an on-chain payment is made. The campaign_id schema note adds a specific when-not guidance about not sending a second donation after a transfer, but there is no explicit comparison to the donate sibling or fuller exclusions for failure cases.

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 transparently states that no donation is recorded yet, only validation occurs, and lists the exact return fields (wallet_address, amount, network, currency). This gives the agent a clear picture of side-effects and output without prior annotation.

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—three sentences—and front-loaded with the position in the flow ('Step 1'). It wastes no words, each sentence adds necessary context, and it is structured to flow from purpose to requirements to next steps.

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 flow, required inputs, validation behavior, return fields, and the next step. It does not mention error handling (e.g., what happens if the campaign is not eligible) or additional constraints, but given no output schema exists and the flow is clearly outlined, it is largely complete. Minor gap: lack of failure behavior.

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 only 33% (only campaign_id has a description). The tool description does not add semantics for amount or reasoning beyond restating their names; it only notes they are required and passed through to confirm_donation. It fails to compensate for the low schema coverage, leaving those parameters underspecified.

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

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

The description clearly states the tool's function: validating campaign eligibility and returning payment instructions as step 1 of a donation flow. It explicitly says it does not record a donation, and contrasts with the sibling confirm_donation, making the purpose and scope 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 explicitly identifies itself as 'Step 1 of the MCP donation flow' and instructs the agent to call confirm_donation after the on-chain payment with the same parameters and the tx_hash. This provides clear when-to-use and next-step guidance, effectively differentiating from the sibling tools.

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 responsibility. It extensively discloses return structure, the read-time snapshot nature of evidence_document_count, deprecated legacy field, unverified campaign_updates, absence of creator_email, and explicit disclaimer about platform verification. This goes beyond typical descriptions and sets clear 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 long but each sentence adds value, explaining output fields and caveats. It front-loads the purpose, then details. While not terse, it earns its length.

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 tool with no output schema, the description covers the returned objects, field semantics, deprecations, and verification caveats. It's sufficiently complete for an agent to understand what to expect without relying on external documentation.

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

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

The schema already fully describes campaign_id with 'Full campaign_id UUID returned by search_campaigns. Do not abbreviate it.' The description only repeats 'Required input: campaign_id' without adding new semantics, so it adds no value beyond the schema's 100% 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?

States the verb 'Fetch' and the resource 'complete campaign detail for one campaign', and the 'one campaign' contrast with search_campaigns which returns multiple. It's clear what this tool does and how it differs from siblings like get_campaign_donations and get_evidence.

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 clearly says 'for one campaign' and requires campaign_id, implying use when you need a single campaign's full details. However, it does not explicitly contrast with alternatives or state exclusions, so the agent has to infer from sibling names. It does mention that creator_email is not included, a useful constraint.

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. It transparently discloses pagination behavior, including has_more and next_offset, and warns that the response may not include all donations. It also specifies the data included (agent identity and reasoning). This is good behavioral disclosure, though it doesn't mention any potential side effects (none expected for a read operation).

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

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

The description is concise and front-loaded: it states the purpose and use case first, then explains pagination in a clear sequence. Every sentence contributes useful information without redundancy. It's well-structured for agent consumption.

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 lack of an output schema, the description explains the key response fields (has_more, next_offset) and the nature of the donation entries. It also instructs how to iterate through pages to get the full set. For a read tool with pagination, this is reasonably complete, though it could detail the exact structure of a donation object.

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

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

Schema coverage is only 33% – only campaign_id is described. The description adds context for offset by explaining its role in pagination ('Continue calling... with offset set to next_offset'). However, it doesn't explain the 'limit' parameter's default or behavior, so some parameters remain under-documented. It partially compensates for the schema gap but not fully.

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 donation history for a campaign, including donor identity and reasoning. This distinguishes it from siblings like donate (creating a donation) and get_campaign (campaign details). The verb 'returns' and specific resource make it 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 offers a clear use case: 'Use this to understand how other agents have evaluated this campaign.' It also provides pagination instructions that tell when to call again, but it doesn't explicitly say when not to use this tool versus alternatives. Nonetheless, the context is sufficient for an agent to decide when this is appropriate.

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 excels: it discloses eligibility checks, pricing-dependent return shapes (evidence_documents vs. x402 handoff), tombstone behavior for deleted evidence, signed_url expiration, and the recommendation to use signed_url over file_reference. This is exceptionally transparent.

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

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

The description is lengthy but logically structured: it starts with the core action, then prerequisites, then conditional return shapes, then tombstone details. The front-loading is good, but the verbosity and repetition of some details (e.g., listing available fields) prevent a perfect score.

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?

Without an output schema, the description must fully explain return values, and it does: it details the eligibility response, the evidence document structure, the x402 handoff shape, tombstones, signed_url expiration, and even agent responsibilities for retained copies. Nothing critical is missing for correct invocation.

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

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

Schema description coverage is 100%, and the schema already provides a descriptive note about campaign_id (full UUID from search_campaigns, do not abbreviate). The description adds no new parameter-specific meaning beyond what the schema supplies, 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 opens with a clear verb and resource: 'Fetch evidence documents for one campaign.' It unambiguously identifies the tool's purpose and distinguishes it from siblings like get_campaign or get_campaign_donations by focusing on evidence documents specifically for 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 provides clear context and prerequisites: it explicitly states the requirement to have accepted the Agent Operator Acknowledgement and the eligibility based on donation volume. However, it does not explicitly mention when to prefer this over alternative tools or provide exclusions for other campaign-related tools, so it stops short of a 5.

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

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

No annotations provided, so the description bears full responsibility. It discloses the tool's read-only nature (returns statistics) and lists the specific outputs (campaign count, categories, donations, funding needs). No mention of side effects or performance, but for a simple aggregate tool this is sufficient.

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

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

Two sentences: first states the purpose, second provides usage guidance and enumerates outputs. Every word adds value; no redundancy.

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

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

Given no output schema, the description adequately explains the return values. It mentions sibling tool search_campaigns for context. For a simple parameter-free tool, this is complete enough.

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 no parameters and 100% schema description coverage, the baseline is 4. The description adds 'No parameters required,' which confirms the schema and provides clarity for the agent.

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 aggregate platform statistics and specifies the exact data (campaigns count, categories, donations, funding needs). It distinguishes itself from search_campaigns by advising use before that tool.

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

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

Explicitly advises using this tool before search_campaigns to understand the platform landscape, providing clear contextual guidance. Also notes no parameters are required, simplifying invocation.

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

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

No annotations provided, so description carries full burden. It discloses that registration requires explicit authorization, proxies to external function, validates wallet_address format, and returns agent_id and api_key. Also outlines operator responsibilities.

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 detailed but each sentence contributes value. It front-loads purpose, then lists inputs with context. Could be slightly shorter, but overall well-structured and informative.

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

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

Given no output schema, description includes return fields (agent_id, api_key). Covers purpose, inputs, constraints, and authorization. Missing error handling or rate limits, but complete for registration 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 low (13%), but description compensates by listing all parameters, specifying required vs optional, and adding constraints (wallet_address format, operator_acknowledgement must be true). Adds meaning beyond schema for most parameters.

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

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

The description clearly states 'Register a new agent' with specific verb and resource. It distinguishes from siblings by mentioning required operator_acknowledgement and proxying to auth-register, which is unique among sibling tools.

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

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

Description lists required and optional inputs, and explicitly states that operator must review terms and set operator_acknowledgement=true. Provides clear context on when and how to use, though it doesn't explicitly exclude certain scenarios.

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 transparency burden. It candidly discloses that evidence counts are read-time snapshots, that factual fields do not assess quality or credibility, that the deprecated filter should not be used as a meaningful state, and that the platform does not verify campaign accuracy. Pagination behavior is also disclosed: 'The response may not include all matching campaigns' and uses has_more/next_offset. This is exemplary 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?

The description is long, but every sentence adds value for an agent. It is front-loaded with the core purpose, then flows through fields, filters, sorting, pagination, and disclaimers. The only minor inefficiency is the repeated emphasis on the deprecated filter, but that is important for correct usage. Overall it earns its length without being bloated.

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 14 parameters, no annotations, and no output schema, the description is remarkably complete. It explains not just inputs but also response components (campaigns, total_matching, has_more, next_offset), the pagination algorithm, and critical caveats about verification and evidence counts. An agent has everything needed to use the tool correctly and iterate through results.

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 only 7% (only evidence_layer_status has a description), yet the description explains every parameter in prose: filters, sorting, pagination, country format, category enum, and defaults. It adds critical semantic detail beyond the schema, such as 'country must be an ISO 3166-1 alpha-2 code' and 'limit defaults to 20 and is capped at 100.' This fully compensates for the sparse schema documentation.

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 verb and resource: 'Search public campaign records with filters, sorting, and pagination.' This specific phrasing immediately distinguishes it from siblings like get_campaign, which would retrieve a single campaign by ID. The scope is well-defined and unambiguous.

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

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

The description provides extensive usage context: all inputs are optional, filter fields are enumerated, sorting and pagination defaults are specified, and explicit guidance is given to continue calling with offset until has_more is false. However, it does not explicitly mention when not to use this tool or recommend get_campaign for single-campaign lookups, so it stops short of full alternative guidance.

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