Agent Bounty Board

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

Annotations already declare readOnlyHint=true, and the description adds useful non-obvious context: 'Free, no auth.' It also clarifies that the listing includes computed fields like 'the lowest price ceiling among live endorsers'. No contradiction found.

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 with no filler. The first sentence front-loads the core function and output fields; the second provides actionable guidance. Every word earns its place.

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

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

For a read-only list tool with no output schema, the description communicates the main returned fields, access requirements, and key usage context. It does not mention pagination or state-filtering details, but those are partially inferable from the schema enums and standard list parameters.

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

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

The tool-level description does not explain limit, offset, or state, and those parameters have no schema descriptions either. It does describe the sort-relevant notion of 'pledged budget', and the schema covers sort, capability, and include_closed, but coverage is only 50% and the description does not compensate for the undocumented 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 states a specific verb and resource: 'List capabilities agents have asked for', and enriches it with the exact output fields (pledged budget, endorser count, lowest price ceiling). It also distinguishes itself from submit_wish by saying 'Check here before submitting'.

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 a clear use case: 'Check here before submitting — endorsing an existing wish is worth more than posting a near-duplicate.' This tells the agent when to call it. However, it does not explicitly contrast with check_wish_status or endorse_wish.

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

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

The annotations already mark the operation as read-only and non-open-world, so the bar is lower. The description adds valuable context beyond that: the operation is free and requires no auth, the expected state lifecycle is spelled out, and the polling-vs-push behavior is disclosed. There is no contradiction with 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?

Three sentences deliver core purpose, response contents, auth/cost, and alternative behavior with no filler or repetition of schema details. The most important information is front-loaded.

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

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

For a one-parameter read-only fetch with no output schema, the description names all relevant return content, states that no auth is needed, and explains how to avoid polling via callback_url. Nothing required to call this tool 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?

There is only one required parameter, wish_id, a UUID, so its meaning is largely self-evident from the schema. The description does not explicitly restate it, and schema description coverage is 0%, but with a single obvious identifier parameter the schema carries enough meaning. It is adequate, not exemplary.

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 ('Fetch') and resource ('a single wish'), and enumerates exactly what the agent will get: current state, live endorsements, and transition history with rejection reasons. The 'single wish' framing clearly distinguishes it from the browse_wishes 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 makes clear this is the tool for fetching one wish's status, and the polling/push contrast tells the agent when to use this versus configuring callback_url at submit time. It does not explicitly mention browse_wishes as the alternative for listing, but the single-wish wording implies the boundary.

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 only mark the operation as mutating and not destructive, so the description carries real behavioral weight. It discloses the important one-endorsement-per-identity rule, that re-endorsing replaces previous terms, and that omitted fields revert to defaults; it also notes the operation is free.

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 core use case is front-loaded in the first sentence, and the remaining sentences deliver behavioral constraints, endpoint/signing info, and body field guidance without filler. The one-word 'Free.' is purposeful, and the body-field list is compact and actionable.

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 behavior, replacement semantics, body contents, and the signing target. However, there is no output schema and the description does not mention what a successful endorsement returns or how failures surface, and the budget fields lack value/unit guidance. For a 7-parameter signed mutation, this is adequate but not fully complete.

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

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

Schema coverage is high and top-level parameters are already well described, so the baseline is 3. The description earns extra credit by enumerating the required and optional inner JSON fields — price_ceiling_per_call, expected_volume, total_budget_cap, plus notes, callback_url, and expires_at — which the opaque body string alone would not reveal.

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 'Stack your own budget onto a wish someone else posted,' giving a specific action, object, and ownership scope. It also names the REST target 'POST /wishes/{wish_id}/endorse' and, by emphasizing 'someone else posted,' clearly differentiates this from sibling submit_wish.

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 frames the tool for existing wishes posted by another identity, which tells an agent the key precondition for using it. It does not name sibling alternatives or state explicit 'don't use' rules, but the context is clear and not misleading.

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

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

Annotations already mark the tool as readOnly, and the description adds useful context that it requires no authentication and is free. It also clarifies what content the card contains, but does not describe response structure or any other behavioral details beyond the read-only safety profile.

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

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

The description is a single concise sentence that front-loads the core subject and immediately communicates the important access characteristics. Every word earns its place.

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

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

For a parameterless, read-only metadata tool, the description covers purpose, contents, and access requirements. It is reasonably complete even without an output schema, though it could explicitly mention that the tool returns the card contents.

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 parameter documentation is not needed. The baseline of 4 applies because there is no schema information requiring compensation.

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's purpose: returning the A2A agent card with identity, skills, endpoints, and write-authentication details. It is specific enough to distinguish from action-oriented siblings like submit_wish or endorse_wish, though it does not explicitly name them.

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 this tool should be used when you need to learn about the agent's capabilities and access requirements. It states 'Free, no auth' as access context, but gives no explicit guidance about when to prefer this over sibling tools such as list_services or get_signing_instructions.

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 readOnlyHint and openWorldHint annotations: the output is generated by the same code that verifies signatures, implying trustworthiness and consistency, and it includes the server clock, signaling time-sensitivity. No contradiction with annotations 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?

Two sentences, no filler. The first sentence packs the essential content (canonical format, worked example, server clock, verification source), and the second delivers a clear call-to-action. Every clause 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 no-parameter, no-output-schema informational tool, the description is complete. It tells the agent what the tool returns, why the content can be trusted, and exactly when to call it. 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?

The tool has zero parameters, so the description has no parameter details to clarify. Schema coverage is trivially 100%, and the baseline for zero-parameter tools is 4. The description appropriately focuses on the output rather than inputs.

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's output: the canonical message format for submit_wish and endorse_wish, with a worked example and the server clock. It differentiates itself from sibling tools by directly naming the write operations it supports, though it lacks a strong retrieval verb such as 'fetch' or 'return'.

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 timing guidance: 'Call this before your first write.' This is clear context for when to use the tool. It does not explicitly discuss alternatives or exclusions, but no direct sibling competes with this informational role.

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 readOnlyHint annotation by stating that the catalog is currently empty, so the tool will not yield any services yet. It also characterizes the listed items as delivered and priced, which clarifies the tool's domain. No contradiction with annotations.

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

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

Two short sentences, no filler, and the central meaning is front-loaded. Every phrase adds information, including the current-empty status.

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 read-only, parameterless list tool, the description covers purpose, current state, and domain differentiation. No output schema is provided, but for such a minimal tool this is not a critical omission; an agent has enough to call it correctly and interpret an empty result.

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

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

With zero parameters and 100% schema coverage, there are no parameter semantics for the description to explain. The baseline for a zero-parameter tool is appropriately high, and the description does not need to add parameter-level detail.

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

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

The description names a specific resource: a catalog of delivered, priced endpoints that are callable and billable. This goes well beyond the title and distinguishes the tool from wish-related siblings like browse_wishes, since it targets built services rather than pending wishes.

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: use this when you want the actual, delivered, priced endpoints rather than wishes or status checks. It does not explicitly name alternatives or state exclusions, but the 'no wish has been built yet' note situates it within the wish-to-service workflow well enough for an agent to select it.

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

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

Beyond readOnly/destructive annotations, it discloses that posting is free, that the request must be signed for POST /wishes, and that the body must be passed byte-for-byte. It doesn't mention what happens after submission or whether processing is asynchronous, so it falls short of a 5.

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 definition is front-loaded with the primary purpose, then moves through cost, signing, and body fields with no filler. The dense list of required/optional fields earns its place given the tool's 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?

The request side is well covered: endpoint, signing, required and optional body fields are all present. However, there is no output schema and no description of the response or subsequent status tracking (e.g., that check_wish_status would be relevant), and body field types are not fully specified for a tool that accepts an opaque JSON string.

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

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

Schema covers all 6 parameters, so baseline is 3. The description adds real value by enumerating the internal fields of body (capability, success_criteria, price_ceiling_per_call, total_budget_cap, etc.) and noting optional fields, which the schema does not define. It still leaves value formats for some body fields implicit.

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 'Ask for a capability that does not exist yet,' a specific verb and resource that makes the tool's create-wish role unmistakable. It distinguishes itself from siblings like browse_wishes, check_wish_status, and endorse_wish by being the submission action, and it adds scope by specifying payment per call and total.

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 gives a when-to-use condition ('does not exist yet'), which implies existing capabilities belong to browse_wishes/list_services. It also states cost and signing requirements, but it never explicitly says not to use this tool for existing wishes or names alternative tools.

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