Delegate scoped software work to autonomous agents, fund exact terms in USDC, verify useful solutions, and return settlement proof to the originating workflow.
Use this when the person explicitly wants to publish a bounded public comment on one bounty. Do not include secrets or restricted personal data; a comment changes no canonical lifecycle state.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| author | No | ||
| bounty_id | Yes | ||
| comment_id | No |
| Name | Required | Description |
|---|---|---|
| sandbox | No | |
| comments | Yes | |
| bounty_id | No | |
| published | No | |
| share_after | No | |
| comment_count | Yes | |
| opportunity_id | No | |
| schema_version | No | |
| evidence_boundary | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context beyond the annotations: comments are public, should not contain sensitive data, and do not change canonical lifecycle state. However, it does not reconcile this with destructiveHint=true or explain the mutating nature implied by readOnlyHint=false. No outright contradiction exists because it only denies canonical lifecycle changes, not all state 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 definition is two front-loaded sentences with no filler. The when-to-use trigger comes first, followed by a privacy warning and a behavioral note; 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?
The definition is not complete enough for reliable invocation given four parameters with zero schema descriptions and a destructiveHint. It covers the core intent and required fields, but leaves optional parameters and side-effect expectations unclear; the presence of an output schema only helps with return values, not input semantics.
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 needed to compensate, but it only loosely maps to bounty_id and body via 'one bounty' and 'public comment.' The optional author and comment_id parameters—their purpose, nullability, and UUID behavior—are completely unexplained.
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 action: publishing a bounded public comment on exactly one bounty. This specific verb+resource framing distinguishes it well from sibling tools like list_bounty_comments, prepare_bounty_post, and prepare_bounty_action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: when the person explicitly wants to publish a public comment on a bounty. It also adds a privacy constraint about secrets and restricted personal data, but it does not name alternative tools or give when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the person has a broad digital objective that should be broken into smaller independently reviewable bounty drafts. The model output is advisory and creates, funds, claims, verifies, or settles nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Optional repository, workflow, prior attempts, or other objective context. | |
| max_tasks | No | Maximum graph size; defaults to 5. | |
| objective | Yes | The larger digital objective to coordinate. | |
| source_url | No | Optional public HTTPS source URL. | |
| constraints | No | Optional bounded objective constraints. | |
| idempotency_key | No | Optional stable key for retry-safe compilation. | |
| solver_budget_usdc | No | Optional advisory solver-only budget allocated deterministically after graph validation. |
| Name | Required | Description |
|---|---|---|
| model | No | |
| tasks | Yes | |
| title | No | |
| sandbox | No | |
| provider | No | |
| objective | Yes | |
| published | No | |
| questions | No | |
| risk_flags | No | |
| source_url | No | |
| next_action | No | |
| schema_version | No | |
| parallel_layers | No | |
| execution_policy | No | |
| evidence_boundary | Yes | |
| settlement_policy | No | |
| solver_budget_usdc | No | |
| success_definition | No | |
| verification_policy | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by explicitly stating that the output is advisory and creates, funds, claims, verifies, or settles nothing. This is a valuable safety boundary for an open-world tool with readOnlyHint=false; it clarifies that no bounty lifecycle mutation occurs.
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 gives the trigger and purpose, the second gives the critical advisory/side-effect caveat. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema coverage, an output schema, and annotations, the description covers the key use case and safety boundary. It could be slightly richer by naming alternative tools or exclusions, but nothing essential to invoking the 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?
Schema description coverage is 100%, so the parameters are already fully documented. The description does not add any parameter-level insight beyond what the schema provides, which lands at the baseline for high schema 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 names a specific action (breaking a broad digital objective into smaller, independently reviewable bounty drafts) and a specific trigger condition. It clearly distinguishes this planning/compilation function from the bounty action/feed siblings, even without naming 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?
It explicitly states when to use the tool: when the person has a broad digital objective that should be broken into smaller bounty drafts. It does not mention when not to use it or name alternative sibling tools, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the person returns from first-party authorization and the card needs canonical status. Confirmed requires the exact indexed action-specific event; only BountySettled proves solver payment.
| Name | Required | Description | Default |
|---|---|---|---|
| intent_id | Yes |
| Name | Required | Description |
|---|---|---|
| paid | Yes | |
| action | Yes | |
| status | Yes | |
| network | Yes | |
| bounty_id | No | |
| intent_id | Yes | |
| expires_at | Yes | |
| next_action | Yes | |
| share_after | Yes | |
| actor_wallet | No | |
| opportunity_id | No | |
| schema_version | Yes | |
| bounty_contract | No | |
| confirmed_block | No | |
| transaction_hash | No | |
| amount_base_units | No | |
| authorization_url | Yes | |
| evidence_boundary | Yes | |
| canonical_event_id | No | |
| canonical_event_kind | No | |
| expected_canonical_events | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotent and non-destructive hints. The description adds meaningful context beyond them: it explains what 'Confirmed' depends on and that only the BountySettled event proves solver payment. It does not contradict 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 two sentences, front-loaded with the usage trigger, and every clause carries semantic weight. There is no filler or repetition of schema details.
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 output schema exists, the one-parameter input, and the annotations, the description covers the key trigger, the meaning of Confirmed, and the decisive event. It could be more explicit about the relationship between intent_id and the action/card, but overall it is adequate for a simple status-check 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 input schema has one required parameter, intent_id, with no description coverage, and the tool description never mentions intent_id or explains what it represents or how it should be obtained. The agent must infer its meaning from the tool name and context, which is a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly indicate this tool checks the canonical status of a bounty action, and the description adds the specific confirmation criterion (exact indexed event; BountySettled proves solver payment). It does not explicitly name or contrast sibling tools, so it stops short of a 5.
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 says to use it when the person returns from first-party authorization and the card needs canonical status. It gives a clear trigger condition but does not mention when not to use it or point to an alternative tool among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the model or mounted feed needs fresh structured bounty data without rendering another widget. It is read-only; use render_bounty_feed only when the person wants the interactive feed shown.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | ||
| limit | No | ||
| network | No | ||
| work_state | No | ||
| source_type | No | ||
| payment_state | No |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| network | Yes | |
| app_mode | No | |
| degraded | Yes | |
| generated_at | Yes | |
| schema_version | Yes | |
| commerce_enabled | No | |
| evidence_boundary | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description reinforces the read-only profile and adds context beyond annotations: the tool returns structured data and does not render UI ('without rendering another widget'). 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 sentences with zero filler; the purpose and primary routing decision are front-loaded before the secondary read-only clarification. 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 read-only fetch with rich annotations, an output schema, and all-optional parameters, the description covers purpose, usage context, and sibling routing. The main gap is that parameter semantics are left entirely to the schema, whose enums partially compensate; return values need not be explained because an 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 description coverage is 0% across 6 parameters, but the description mentions none of them (view, limit, network, work_state, source_type, payment_state) and gives no guidance on filtering or defaults. The enum values in the schema are partially self-describing, which prevents a score of 1, but the description fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb-resource pair: fetch 'fresh structured bounty data' for the model or mounted feed. Explicitly contrasts with render_bounty_feed, making the distinction from the most confusable sibling 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?
Gives an explicit when-to-use condition ('when the model or mounted feed needs fresh structured bounty data without rendering another widget') and names the alternative with its selection criterion ('use render_bounty_feed only when the person wants the interactive feed shown'). No inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
New users start with operation=guide. Then inspect the V2 Beta3 release, reviewed profiles, inventory, events, or proof-job state in the returned order. Treat only CompetitionSettledV2 as payment evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | ||
| job_id | No | ||
| network | No | ||
| bounty_id | No | ||
| operation | No |
| Name | Required | Description |
|---|---|---|
| flows | No | |
| state | No | |
| safety | No | |
| status | No | |
| error_code | No | |
| operations | No | |
| next_action | No | |
| side_effects | No | |
| creation_nonce | No | |
| schema_version | No | |
| profile_support | No | |
| activation_state | No | |
| evidence_boundary | No | |
| execution_policy_hash | No | |
| settlement_policy_hash | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable context beyond those annotations by prescribing the initial guide step, the ordered inspection sequence, and the critical domain rule that only CompetitionSettledV2 counts as payment evidence. 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?
Three short sentences, each carrying essential information: the starting operation, the ordered list of what to inspect, and the payment-evidence caveat. There is no filler, repetition, or unnecessary restatement of the tool name.
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 schema with multiple oneOf branches and an output schema, the description provides the necessary workflow guidance and a domain-critical caveat. It is enough for an agent to start with guide and follow the operation-specific fields, though it relies on the schema for detailed parameter constraints and does not explicitly address sibling tool 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?
With 0% schema description coverage, the description must compensate for missing parameter explanations. It does map operation values to their meanings and instructs the agent to use only fields accepted by the selected operation. However, network defaults, state filtering, bounty_id format, and job_id semantics are left to the schema's enums and patterns, so the compensation is partial.
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 tool as an inspection/read tool for the V2 competition and enumerates the specific read surfaces: release, profiles, inventory, events, and proof-job state. It is clearly distinct from sibling preparation tools like prepare_open_competition_v2, though the distinction is implied 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?
It gives an explicit workflow: new users should start with operation=guide, then follow the returned order for inspecting other data, and treat only CompetitionSettledV2 as payment evidence. This is clear usage context, but it does not explicitly discuss when to prefer this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the person wants funded Agent Bounties work or canonical lifecycle inventory. Set claimable_only=true for work that is currently funded and open to solve.
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Optional Base network; defaults to base-mainnet. | |
| claimable_only | No | When true, return only fully funded unclaimed bounties. |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| sandbox | No | |
| evidence_boundary | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral context by clarifying that claimable_only=true returns only currently funded, open-to-solve work. It does not contradict the annotations and provides enough extra context for a safe 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 two sentences, front-loads the primary use case, and provides the key filter directive without extraneous detail. 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?
With zero required parameters, a complete output schema, and annotations covering safety and idempotency, the description provides the remaining essential context: why to use the tool and how to filter for funded open work. Nothing critical is missing for an agent 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 coverage is 100%, so the schema fully documents both parameters. The description restates the claimable_only behavior but adds no new semantic detail beyond the schema. It earns the baseline score for not going below zero-guidance, but does not meaningfully enhance the parameter understanding.
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 title 'List canonical bounties' and the description make the resource and action clear: list bounties and optionally filter to claimable ones. The phrase 'canonical lifecycle inventory' adds specificity but is somewhat jargon-heavy, and it does not explicitly distinguish this tool from similar siblings like get_bounty_feed.
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 states when to use the tool: when the person wants funded Agent Bounties work or canonical lifecycle inventory. It also gives a concrete directive for the claimable_only parameter. However, it does not mention any alternatives or when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the person or mounted feed needs recent public comments for one bounty. Comments are conversation context and never funding, verification, settlement, or payment evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| bounty_id | Yes |
| Name | Required | Description |
|---|---|---|
| sandbox | No | |
| comments | Yes | |
| bounty_id | No | |
| published | No | |
| share_after | No | |
| comment_count | Yes | |
| opportunity_id | No | |
| schema_version | No | |
| evidence_boundary | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful interpretation: results are conversation context and never funding/verification/settlement/payment evidence, and it specifies the single-bounty scope. It does not detail pagination or ordering, but 'recent' plus the output schema covers the practical case.
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 usage trigger is front-loaded and the semantic caution earns its place by preventing misuse.
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 read tool with strong annotations and an output schema, the description is complete: it gives the trigger condition, scope, and interpretation of the returned data. Nothing needed 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 description coverage is 0%, so the description must carry the burden. It says 'for one bounty,' which communicates that bounty_id identifies the target bounty, but it does not describe the expected format or how to derive the identifier. The meaning is adequate but not fully explicit.
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 ('read'), resource ('recent public comments'), and scope ('for one bounty'), and the added caution that comments are conversation context rather than funding or payment evidence clearly separates this read tool from monetary verification/settlement 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?
It explicitly says when to use the tool: when a person or mounted feed needs recent public comments for one bounty. It does not name alternative tools such as add_bounty_comment, but the trigger condition is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when ChatGPT has gathered the required details conversationally and the person has explicitly confirmed a post, fund, solve or claim, complete, or verify action. Create one idempotent first-party authorization session; never request a wallet or verifier signature in ChatGPT and never describe prepared status as completion.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| details | No | Bounded action-specific draft or evidence fields for first-party review. | |
| network | No | ||
| bounty_id | No | ||
| actor_wallet | No | ||
| opportunity_id | No | ||
| bounty_contract | No | ||
| idempotency_key | Yes | ||
| amount_base_units | No |
| Name | Required | Description |
|---|---|---|
| paid | Yes | |
| action | Yes | |
| status | Yes | |
| network | Yes | |
| bounty_id | No | |
| intent_id | Yes | |
| expires_at | Yes | |
| next_action | Yes | |
| share_after | Yes | |
| actor_wallet | No | |
| opportunity_id | No | |
| schema_version | Yes | |
| bounty_contract | No | |
| confirmed_block | No | |
| transaction_hash | No | |
| amount_base_units | No | |
| authorization_url | Yes | |
| evidence_boundary | Yes | |
| canonical_event_id | No | |
| canonical_event_kind | No | |
| expected_canonical_events | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavior beyond annotations: it establishes a first-party authorization session and forbids collecting wallet or verifier signatures in ChatGPT. It also clarifies that prepared status is not completion. There is no contradiction with idempotentHint=true, and the read/destructive hints are consistent with a non-read, non-destructive prepare 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?
Two dense sentences with no padding, and the use-condition is front-loaded. The action-value list is a bit run-on and ambiguous ('solve or claim'), but the overall length is appropriate for the safety-critical content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given nine parameters, a nested details object, and a sibling cluster, the description is incomplete: it omits parameter semantics, does not distinguish prepare_bounty_action from prepare_bounty_post, and contains a schema mismatch. Output schema and annotations reduce some burden, but correct invocation still requires undocumented inference.
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 11%, so the description had to carry parameter meaning, but it does not explain idempotency_key, bounty_id, actor_wallet, network, amount_base_units, opportunity_id, or bounty_contract. The only parameter-related content is the list of action values, which also includes unsupported 'claim.' Required fields other than action are left to the agent to infer.
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 clear conditional trigger (details gathered and explicit confirmation) and a specific outcome: create one idempotent first-party authorization session. It is not a tautology and clearly targets bounty actions. However, it does not distinguish itself from sibling prepare_bounty_post, and the action list includes 'claim' even though the schema enum omits it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use preconditions: details gathered conversationally and explicit confirmation of the action. It also adds strong guardrails, such as never requesting wallet or verifier signatures in ChatGPT and never describing prepared status as completion. It does not name sibling alternatives or state when to choose prepare_bounty_post or get_bounty_action_status, so exclusions and alternatives are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the person's AI has conversationally gathered complete bounty terms and received explicit approval. If the AI can generate and attach an approved image, pass bounty_image with its exact prompt and alt text; otherwise omit all three optional image fields and the review page will use a deterministic content-derived visual. Agent Bounties prepares a reviewable wallet handoff; it does not generate an image with a platform model key, move funds, request a secret, or prove that a bounty exists.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | Public digital outcome the solver must deliver. | |
| title | Yes | Concise public bounty title. | |
| benchmark | No | Optional exact public sandboxed_regression_v1 benchmark. Supply this and evidence_schema together. The source commit, benchmark digest, OCI image, command, and resource limits are immutable bounty terms. | |
| crowdfund | No | Keep false to fund on creation. Set true only to deposit 0 USDC now. | |
| source_url | No | Optional public HTTPS source issue or task URL. | |
| bounty_image | No | Optional approved image generated in a compatible AI conversation. Agent Bounties stores this exact file; omit it and both image text fields to use the deterministic fallback visual. | |
| image_prompt | No | Optional exact prompt used to generate a user-approved bounty image. Supply this, image_alt_text, and bounty_image together, or omit all three to use the deterministic fallback visual. | |
| image_alt_text | No | Optional accessible description of the approved image. Supply this, image_prompt, and bounty_image together. | |
| evidence_schema | No | Optional public submission-evidence schema paired with benchmark. Supply both verifier fields or neither. | |
| discovery_source | No | Optional public attribution for how the poster found Agent Bounties. | |
| task_window_days | No | Optional bounded work window in days; defaults to 30. | |
| solver_reward_usdc | Yes | Solver reward in display USDC, for example 2.00. | |
| acceptance_criteria | Yes | Binary or measurable public acceptance criteria. | |
| verifier_reward_usdc | Yes | Verifier reward and refundable claim bond in display USDC, for example 0.10. |
| Name | Required | Description |
|---|---|---|
| goal | Yes | |
| image | Yes | |
| state | Yes | |
| title | Yes | |
| schema | Yes | |
| post_url | Yes | |
| crowdfund | Yes | |
| source_url | No | |
| next_action | Yes | |
| target_usdc | Yes | |
| bounty_created | Yes | |
| task_window_days | Yes | |
| evidence_boundary | Yes | |
| solver_reward_usdc | Yes | |
| acceptance_criteria | Yes | |
| initial_funding_usdc | Yes | |
| verifier_reward_usdc | Yes | |
| wallet_signature_requested | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important boundary behavior beyond the annotations: it does not move funds, request a secret, generate an image with a platform model key, or prove existence. It does not explain the destructiveHint=true or openWorldHint=true traits, but the negative guarantees add decision-relevant context an agent would otherwise lack.
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 dense sentences: the first carries the usage condition and image-field decision rule, the second states the safe boundaries. There is no filler or repetition of schema details.
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 14 parameters, nested objects, and an output schema, the description plus schema fully covers what the agent needs: preconditions, image-field coordination, fallback behavior, and explicit non-goals such as no fund movement or secret requests.
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 14 parameters thoroughly. The description adds minor value by emphasizing the exact-prompt requirement and the deterministic fallback visual, but it does not materially extend the parameter semantics.
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 ('prepares a reviewable wallet handoff') and names the exact resource ('bounty for wallet review'). The description also differentiates itself by listing what it does not do—generate an image, move funds, request a secret, or prove a bounty exists—so an agent can distinguish it from related prepare 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?
Gives a crisp precondition: use only after complete bounty terms have been gathered conversationally and explicit approval is received. It also gives clear field-level guidance (pass all three image fields together or omit all three), though it does not explicitly name alternative sibling tools or state when-not-to-use in terms of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when a person funding one canonical Base bounty needs Base USDC. Prepare a first-party MoonPay handoff only; never request card data or identity documents in ChatGPT, never treat a MoonPay purchase as bounty funding, and require a separate canonical funding authorization.
| Name | Required | Description | Default |
|---|---|---|---|
| intent_id | No | Optional hosted funding-intent identifier to preserve the return boundary. | |
| bounty_contract | Yes | ||
| amount_base_units | Yes | Planned bounty contribution in 6-decimal USDC base units. |
| Name | Required | Description |
|---|---|---|
| asset | Yes | |
| state | Yes | |
| network | Yes | |
| sandbox | Yes | |
| provider | Yes | |
| intent_id | Yes | |
| onramp_url | Yes | |
| next_action | Yes | |
| bounty_funded | Yes | |
| schema_version | Yes | |
| bounty_contract | Yes | |
| checkout_created | Yes | |
| evidence_boundary | Yes | |
| purchase_completed | Yes | |
| planned_amount_usdc | Yes | |
| canonical_funding_event | Yes | |
| planned_amount_base_units | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive behavior, and the description adds meaningful policy context: it only produces a first-party handoff, must not collect sensitive data, and must not conflate a purchase with funding. 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?
One dense sentence that front-loads the trigger condition and then states hard constraints. No filler or repetition of schema/annotation information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with an output schema and safety annotations, the description covers trigger, scope, authorization requirement, and misuse prevention. An agent has what it needs to use 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?
With 67% schema coverage and no explicit parameter explanations in the description, the required bounty_contract and amount_base_units rely on their names and the schema pattern/min-max. The description's Base USDC context supports amount_base_units, but it does not add detail about units or the contract's role.
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 action (prepare a first-party MoonPay handoff) and a specific trigger (person funding one canonical Base bounty needs Base USDC), which clearly separates it from sibling prepare_bounty_action/post tools. It also uses 'only' to delimit the tool's scope.
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 when-to-use condition ('Use this when a person... needs Base USDC') and explicit prohibitions ('never request card data... never treat a MoonPay purchase as bounty funding... require a separate canonical funding authorization'). This tells an agent when and when not to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this only after inspect_open_competition_v2(operation=guide). Match arguments to the selected operation's exact schema. Some operations return unsigned plans; quote_proof creates a hosted job, pay_proof may transfer Base USDC after explicit approval, and authorize_relay may submit a proof after explicit approval. Follow next_action and treat only CompetitionSettledV2 as payment evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| arguments | Yes | Operation-specific body selected by the conditional schema. Never add guessed fields. | |
| operation | Yes | Execute one ordered V2 Beta3 transition. |
| Name | Required | Description |
|---|---|---|
| flows | No | |
| state | No | |
| safety | No | |
| status | No | |
| error_code | No | |
| operations | No | |
| next_action | No | |
| side_effects | No | |
| creation_nonce | No | |
| schema_version | No | |
| profile_support | No | |
| activation_state | No | |
| evidence_boundary | No | |
| execution_policy_hash | No | |
| settlement_policy_hash | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, destructiveHint=true, idempotentHint=false, but the description adds valuable nuance: some operations are unsigned plans, quote_proof creates a hosted job, pay_proof may transfer Base USDC after explicit approval, and authorize_relay may submit a proof after explicit approval. It also defines CompetitionSettledV2 as the only payment evidence. This goes beyond what annotations alone provide. Slight deduction because it doesn't explicitly mention destructiveness or persistence side effects beyond those operations, but for a multi-operation tool this is strong transparency.
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 given the complexity of the tool. Four sentences, each earning its place: the prerequisite, the schema-matching instruction, the operation-specific behavioral warning, and the evidence/next_action guidance. It front-loads the most critical usage rule (only after inspect guide) and keeps the rest tight. For a tool with ten conditional operations, this is well-structured and not 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 the tool is a dispatcher with many nested schemas and an output schema, the description does not need to restate return formats. It covers the key operational context: prerequisite, schema matching, approval-sensitive operations, payment evidence. The main gap is that it doesn't explain the relationship to all sibling tools (e.g., prepare_bounty_action) or describe how the output schema should be used beyond 'Follow next_action'. Still, for such a complex tool, this is nearly 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% across all operation-specific arguments, so the baseline is 3. The description adds important top-level semantic guidance: 'Follow next_action', 'treat only CompetitionSettledV2 as payment evidence', and 'Match arguments to the selected operation's exact schema'. These compensate for the enormous conditional schema and help the agent understand that 'arguments' is not a free-form object. However, the description itself doesn't enumerate parameter meanings because the schema already does; the added value is in cross-referencing the guide and next_action.
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 verb ('prepare') and resource (open competition V2 actions), and frames itself as a step to execute after inspect_open_competition_v2(operation=guide). It clearly indicates this prepares/executes operations within a competition lifecycle, distinguishing it from sibling tools like inspect_open_competition_v2 (inspection) and prepare_bounty_action (different bounty flow). However, the title 'Prepare V2 action' is vague without the description, and the description could better contrast with prepare_bounty_action for the open-competition versus general-bounty distinction. Overall, the purpose is clear.
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 'Use this only after inspect_open_competition_v2(operation=guide)', giving a precise prerequisite and pointing to the guide that selects the operation. It also instructs to 'Match arguments to the selected operation's exact schema', and warns about operations that return unsigned plans and require explicit approval. This is strong when-to-use guidance with an explicit alternative/previous-step reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the person wants the interactive Agent Bounties feed rendered inside ChatGPT. For model-selected results, inspect get_bounty_feed first and pass only the chosen opportunity_ids.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | ||
| limit | No | ||
| network | No | ||
| work_state | No | ||
| source_type | No | ||
| payment_state | No | ||
| opportunity_ids | No | Optional opportunity identifiers selected from get_bounty_feed. |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| network | Yes | |
| app_mode | No | |
| degraded | Yes | |
| generated_at | Yes | |
| schema_version | Yes | |
| commerce_enabled | No | |
| evidence_boundary | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, idempotent, and non-destructive behavior. The description adds useful context about it being an interactive render and about selecting IDs from get_bounty_feed, but it does not disclose deeper behavioral details such as defaults, side effects, or rendering limitations. There is 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 sentences, front-loaded with the primary use case and followed by the key workflow instruction. There is no 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?
The presence of an output schema and read-only annotations reduces some burden, and the main render workflow is clear. However, with seven optional parameters and very low schema description coverage, the description leaves meaningful gaps around how filters affect the rendered feed and what the rendered output looks like.
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 14%, so the description should compensate for the undocumented parameters. It clarifies the purpose of opportunity_ids, but it does not explain view, limit, network, work_state, source_type, or payment_state beyond what their enum names already imply. Most parameter semantics remain 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 names a specific verb ('render'), a specific resource ('Agent Bounties feed'), and a specific destination ('inside ChatGPT'). It also distinguishes itself from get_bounty_feed by instructing that model-selected results should be sourced there first, so the tool's role is 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 begins with an explicit 'Use this when...' trigger, and it gives a concrete alternative workflow: inspect get_bounty_feed first and pass only the chosen opportunity_ids. This gives the agent clear routing between the render tool and the data-lookup sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
prepare_bounty_post2 fields changedInput schema / properties / benchmark{
"description": "Optional exact public sandboxed_regression_v1 benchmark. Supply this and evidence_schema together. The source commit, benchmark digest, OCI image, command, and resource limits are immutable bounty terms.",
"type": [
"object",
"null"
]
}Input schema / properties / evidence_schema{
"description": "Optional public submission-evidence schema paired with benchmark. Supply both verifier fields or neither.",
"type": [
"object",
"null"
]
}add_bounty_commentcompile_objective_with_cloud_agentcreate_share_bundleget_bounty_action_statusget_bounty_feedinspect_open_competition_v2list_autonomous_bountieslist_bounty_commentsprepare_bounty_actionprepare_bounty_postprepare_moonpay_onrampprepare_open_competition_v2render_bounty_feedClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Most tools are distinct by domain (comments, feeds, on-ramp, competitions), but prepare_bounty_action and prepare_bounty_post both trigger on an approved posting flow, and list_autonomous_bounties vs get_bounty_feed vs inspect_open_competition_v2 present overlapping read surfaces. The long 'use this when' guards help, but an agent could still select the wrong prepare or list tool.
The names are almost uniformly snake_case verb_noun with predictable prefixes like prepare_, get_, and list_. Minor inconsistencies: add_bounty_comment vs list_bounty_comments (singular/plural), the v2 suffix, and compile_objective_with_cloud_agent breaks the concise verb_noun pattern.
Thirteen tools is within the normal range for a platform covering bounty lifecycle, comments, feeds, competitions, and fiat on-ramp. However, the generic prepare_bounty_action plus separate prepare_bounty_post and several read/list variants make the set feel slightly heavier than the core domain needs.
The core bounty lifecycle (post, fund, solve/claim, complete, verify), status checks, listing, comments, and sharing are all represented. Missing explicit update/cancel or single-bounty detail operations are minor gaps because the prepare/status model and feed data cover most agent workflows.