zooidfund

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

With no annotations, the description carries full burden and provides rich behavioral context: verification checks (network, token contract, recipient, amount, confirmation, duplicate protection, sender matching), state changes (records donation, increments funded_amount), and return values (donation_id, status, tx_hash). Does not contradict annotations (none provided). Lacks rate limits or error details, but covers core behavior well.

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?

Front-loaded with purpose and required inputs. Every sentence adds value: explains verification steps, state changes, and returns. No redundant or vague language. Appropriately sized for a complex tool with 4 parameters and significant behavior.

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

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

No annotations or output schema, but description compensates well: covers purpose, usage, behavior, parameters, and return values. Could improve by mentioning error cases or auth needs, but given complexity and lack of structured data, it is largely complete. Slightly reduced due to missing output schema details.

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

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

Schema description coverage is 0%, so description must compensate. It adds meaning beyond schema: explains that 'campaign_id' and 'amount' are verified against on-chain data, 'reasoning' is part of recording, and 'tx_hash' is checked for duplicates and confirmation. Clarifies parameter roles in the verification flow, which schema alone does not provide.

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

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

The description clearly states the tool's purpose as 'Step 2 of the MCP donation flow' and specifies it 'verifies the on-chain payment' and 'records the donation, increments campaign funded_amount'. It distinguishes from siblings like 'donate' (likely step 1) and 'get_campaign_donations' (read-only). The verb+resource combination is specific: verify payment and record donation.

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: 'Step 2 of the MCP donation flow'. Implies alternatives: 'donate' is likely step 1, and other get_* tools are for querying. Clear context: use after payment is made to verify and record. No misleading 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it validates campaign eligibility, does not record donations yet, returns payment instructions on success, and requires a follow-up call to 'confirm_donation.' However, it lacks details on error handling, rate limits, or authentication requirements.

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

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

The description is front-loaded with the tool's purpose and required inputs, followed by behavioral details and next steps. Every sentence adds value: explaining validation, output, and the subsequent tool call. There is no redundant or vague language.

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 does well by explaining the tool's role in a multi-step process, its parameters, and expected output (payment instructions). However, it could be more complete by detailing the exact structure of the payment instructions or error cases, though the lack of output schema makes this less critical.

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 0% schema description coverage, the description compensates by explaining the semantics of all three required parameters: 'campaign_id, amount, and reasoning.' It clarifies their role in the donation flow and that they must be reused in 'confirm_donation.' However, it doesn't specify data formats or constraints beyond what's implied.

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 as 'Step 1 of the MCP donation flow' and specifies it 'validates that the campaign is eligible to receive donations but does not record any donation yet.' It distinguishes itself from sibling tools like 'confirm_donation' by explaining its role in the multi-step process.

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

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

The description explicitly states when to use this tool ('Step 1 of the MCP donation flow') and provides clear alternatives by specifying that after success, the user should 'call confirm_donation with the same campaign_id, amount, reasoning, and the resulting tx_hash.' It also distinguishes from other siblings by focusing on donation initiation rather than confirmation or querying.

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 fully shoulders the burden. It details output fields (creator_wallet_address, closure metadata, verification_artifacts, campaign_updates, funding_progress), notes that campaign_updates are append-only and not verified, excludes creator_email, and disclaims platform verification. This is comprehensive and beyond basic fetch.

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 efficiently structured: a clear one-sentence purpose, then output details, then caveats. Every sentence adds value and no information is redundant.

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 absence of an output schema, the description fully details the return structure, including specific fields and the separate funding progress object. It even explains trustworthiness of certain fields. This is complete for a single-parameter 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 only parameter is campaign_id, and the description states it is required. However, the schema has 0% description coverage, and the description does not add guidance on format (e.g., UUID vs string). For a single simple parameter, this is adequate but does not fully compensate for missing schema descriptions.

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

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

The description clearly states the tool fetches complete campaign detail for one campaign, using specific verb 'Fetch' and resource 'campaign detail'. It distinguishes from sibling tools like search_campaigns (which searches) and get_campaign_donations (which returns donations, not full detail).

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 the required input (campaign_id). While it does not name alternative tools or when not to use, the purpose is clear enough for an AI agent to infer usage context. Lacks explicit exclusions but is still helpful.

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 explicitly discloses pagination behavior, including has_more and next_offset, and instructs on how to scan full results. No annotations are provided, so the description carries full transparency burden and does so well.

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 4 sentences, front-loading purpose and critical behavioral details. Minor inefficiency: could shorten 'including which agents donated and their stated reasoning' 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 lack of output schema and annotations, the description covers core behavior (pagination, returned fields) well. It lacks explicit structure of donation objects but provides sufficient context for an agent to use the 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?

Schema coverage is 0%, and the description only partially compensates. It explains offset and next_offset usage but does not describe the limit parameter or explicitly detail campaign_id beyond context. Some value is added, but gaps remain.

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 specific campaign, including agent identities and reasoning. It distinguishes from siblings (e.g., donate creates donations, confirm_donation acts on 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 advises using it to understand how other agents evaluated a campaign, providing clear context. However, it does not explicitly state when not to use it or compare with 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?

No annotations are provided, so the description carries the full burden. It thoroughly discloses all scenarios (not eligible, eligible with inactive pricing, eligible with active pricing) and details the response shapes, including tombstone evidence for deleted files, signed URL expiration (15 minutes), and the x402 handoff. 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 somewhat lengthy but well-structured, starting with the core purpose and required input, then explaining conditional behavior. Each sentence adds value, though it could be tightened without losing meaning.

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

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

Despite no output schema, the description completely covers all response scenarios (eligibility, pricing, tombstone), including field names and behavior. It provides all necessary context for an agent to handle the tool's outputs 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?

Only one parameter (campaign_id) exists with 0% schema coverage. The description only restates that it is required, adding no semantic detail about format, source, or validation. It fails to compensate for the lack of schema 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 starts with a clear verb and resource: 'Fetch evidence documents for one campaign.' It specifies the required input campaign_id, making the tool's purpose unambiguous. While it doesn't explicitly differentiate from siblings, the purpose 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?

The description provides clear context on when the tool returns evidence vs. a payment requirement or eligibility status. It explains the conditional behavior based on eligibility and pricing, which guides the agent's decision. However, it does not explicitly state when not to use this tool or mention alternative 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'No parameters required' and describes the type of data returned, but lacks details on permissions, rate limits, data freshness, or error conditions. It provides basic operational context but misses important behavioral traits for a statistics 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?

The description is efficiently structured in two sentences: the first states the purpose and specific metrics, the second provides usage guidance and parameter information. Every sentence earns its place with no wasted words, making it front-loaded and appropriately sized.

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 low complexity (0 parameters, no annotations, no output schema), the description is reasonably complete. It explains what the tool does, when to use it, and that it requires no parameters. However, without annotations or output schema, it could better describe the return format or data structure for the statistics.

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 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately notes 'No parameters required,' which aligns with the schema and adds no extra semantic value. Baseline for 0 parameters is 4.

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 with specific verbs ('Returns aggregate platform statistics') and resources ('platform statistics'), and distinguishes it from siblings by listing specific metrics it provides (campaign counts, categories, donations, funding needs). It goes beyond a tautology by explaining what 'overview' means in this context.

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

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

The description provides explicit guidance on when to use this tool ('Use this before search_campaigns to understand the current platform landscape') and implies an alternative (search_campaigns for detailed exploration). This gives clear context for its application relative to other 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?

With no annotations provided, the description carries full burden. It discloses that this is a creation/mutation operation ('Register a new agent'), mentions the proxy mechanism, specifies a validation requirement for wallet_address, and describes the return values. However, it lacks information about permissions, rate limits, idempotency, or error conditions.

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 efficiently structured in three sentences: purpose/mechanism, parameter breakdown, and return values. Each sentence earns its place, though the parameter listing could be slightly more concise.

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

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

For a mutation tool with 7 parameters, 0% schema coverage, and no output schema, the description does reasonably well by explaining parameters and returns. However, it lacks critical context about authentication requirements, error handling, and system behavior that would be needed for complete understanding.

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

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

Schema description coverage is 0%, so the description must compensate. It clearly distinguishes required vs. optional parameters, provides specific validation for wallet_address ('valid 0x-prefixed 40-byte hex Ethereum address'), and gives meaningful names to all parameters. This adds substantial value beyond the bare schema.

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

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

The description clearly states the specific action ('Register a new agent'), the mechanism ('by proxying to the auth-register Edge Function'), and distinguishes it from sibling tools (which are about donations, campaigns, and evidence, not agent registration). It provides verb+resource+method specificity.

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 no guidance on when to use this tool versus alternatives, prerequisites, or contextual constraints. It lists required and optional inputs but doesn't explain when registration is appropriate or what happens if an agent already exists.

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 fully covers behavioral traits: all inputs optional, default status 'active', pagination limits (max 100, default 20), pagination continuation process, and important disclaimer that zooidfund does not verify campaign accuracy. It also notes the response may not include all matching campaigns.

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

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

The description is a single dense paragraph that front-loads the main purpose. While it contains extensive detail, each sentence adds value and the structure is logical (filters, then sorting, then pagination, then important notes). Could be slightly more concise by grouping related items.

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 required fields, and no output schema, the description is highly complete. It covers all parameters, pagination behavior, response fields (campaigns, total_matching, has_more, next_offset), and includes a critical reliability disclaimer. No gaps are evident.

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 0%, but the description provides comprehensive definitions for all 14 parameters, including allowed values (category enum, sort_by, sort_order, evidence_layer_status), defaults (status, limit, offset), constraints (country must be ISO alpha-2, max_funded_percent range), and matching behavior (country matched against location_country).

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 searches public campaign records with filters, sorting, and pagination, distinguishing it from siblings like get_campaign (single record) and get_campaign_donations (donations). The verb 'search' and resource 'campaign records' are specific.

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

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

The description explains that all inputs are optional and provides detailed guidance on filters, sorting, and pagination. It does not explicitly contrast with siblings but offers clear context on how to use the tool, including pagination continuation with has_more and next_offset.

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