SideQuest

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

With no annotations, the description carries the full burden and does disclose the most important trait: approval releases the secured reward, a real financial side effect. It also discloses the auto-approval fallback at 72 hours. Gaps remain on permissions required, whether approval is reversible, and what state the quest must be in.

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 distinct information: action, side effect, optional parameter, and timing fallback. The most important fact (reward release) is front-loaded and there is no filler.

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

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

For a two-parameter mutation with no output schema, the description covers the action and its effect but says nothing about the response (e.g., updated quest status or transaction confirmation) or failure conditions such as an already-approved or disputed quest.

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%, so the description must compensate. It clarifies that rating targets the quester, is optional, and is on a 1-5 scale, but quest_id gets no explanation of format or where it comes from, and the 1-5 bounds merely restate the schema's min/max.

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?

Names a specific verb and resource (approve a submitted quest) plus the concrete consequence (secured reward released). The mention of "disputed" gestures toward the dispute_quest sibling, but it never explicitly contrasts with cancel_quest or dispute_quest.

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

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

The phrase "after checking its proof" implies the prerequisite verification step, and the 72-hour auto-approval note signals that calling this tool is optional. However, there is no explicit routing guidance (e.g., use dispute_quest instead when proof is invalid), so the when-not-to-use case is left to inference.

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

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

With no annotations, the description carries the full load and does so well for a destructive operation: it discloses irreversibility once claimed, the precondition, and the financial side effect (full refund on paid quests). Missing are permission/auth requirements and what happens on a repeat call or on an already-claimed quest.

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, front-loaded with the action and precondition, then the monetary consequence, then the hard limit. Nothing is redundant and nothing needs rereading.

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 destructive tool with no annotations and no output schema, the description covers the essentials an agent needs: when it is legal, what gets reversed, and what is permanent. Error/edge behavior (nonexistent id, already-cancelled id, idempotency) is the only notable omission.

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 adds no meaning about quest_id — no format, no source (e.g. from list_quests or get_quest). The parameter is self-evident for a single-id cancel tool, so the gap is minor rather than disabling.

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?

A specific verb+resource ('Cancel a quest') with an explicit scope qualifier ('before a quester claims it'). It is distinguishable from approve_quest/create_quest by the verb, but the description never names or contrasts with any sibling, 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?

Gives a clear use condition (pre-claim) and an explicit exclusion (claimed quests cannot be cancelled). It does not point to any alternative action for claimed quests, such as dispute_quest, which would be the natural routing fallback.

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

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

With no annotations, the description carries the full burden and does well: it explains that prepaid balance covering reward plus 20% fee means instant publish, otherwise a checkout_url is returned for a human to pay. It also discloses that prohibited categories are rejected. It omits auth/account prerequisites and what the rejection path looks like (error vs. silent refusal).

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

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

Four tight sentences: purpose first, then payment behavior, then the funding escape hatch, then the use/exclusion boundary. No filler and nothing repeated for its own sake.

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 10-parameter creation tool with a nested details object and no output schema, the description covers the key outcome (instant publish vs. checkout_url) that an agent needs to interpret the result. Location, template, and field-level semantics are left entirely to the 100%-covered schema, which is reasonable but leaves the description thin on the required lat/lng conditionality.

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

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

Schema coverage is 100%, so the baseline is 3, and the description largely restates what the schema already declares about reward_usd fee math and funding modes. It adds a little framing on how funding choice affects flow, but no new syntax or format detail beyond the schema.

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

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

The opening sentence states a specific verb and resource ('Post a paid real-world quest'), plus the audience ('verified human quester') and the geographic scoping. It is unmistakably distinct from siblings like get_quest, list_quests, approve_quest, and cancel_quest.

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 a positive use case ('tasks only a person on site can do') and an explicit exclusion list (account creation, social posting, reviews, CAPTCHAs, illegal work), plus a funding-mode alternative ('use funding: balance to fail instead'). It does not name sibling tools it routes to, though the template enum in the schema points at list_templates.

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

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

With no annotations, the description carries the full burden, and it does disclose one meaningful trait: funds remain held pending a human reviewer's decision. It omits required permissions, whether the dispute can be withdrawn or reversed, how long review takes, and what the caller receives back.

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, front-loaded with the action and its precondition, then the consequence, then the input requirement. Nothing is redundant and every sentence adds 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 two-parameter mutation with no annotations and no output schema, the description covers the trigger and the funds-held consequence well, but omits outcome (what a successful dispute returns), eligibility, and reversibility. Adequate but with clear gaps for an agent to act confidently.

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, and it does partially: 'a submitted quest' constrains quest_id to an already-submitted quest, and 'Give a specific reason' signals that reason should cite the unmet instruction rather than be generic. It still gives no format or length expectations for either field.

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 ('Dispute') and a precisely scoped resource ('a submitted quest whose proof does not meet the instructions'), which distinguishes it from create_quest or get_quest. It does not name approve_quest as the contrasting action, so the sibling differentiation is only implicit.

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 trigger condition is clear: use it when submitted proof fails to meet the instructions. However, it never states the inverse (when to approve instead), who is eligible to dispute, or whether a quest can be re-disputed after resolution, leaving the agent to infer the boundary with approve_quest.

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

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

With no annotations, the description carries the full burden and does disclose the three values returned and the read-only nature implied by "Check". It stops short of stating auth requirements, rate limits, or the currency/unit of the balance, which matter for interpreting the result.

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, both front-loaded: the first declares what is returned, the second converts that into an actionable decision point. No filler, no 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 zero-param read tool with no output schema and no annotations, the description is the sole source of return-value information, and it names the three returned quantities plus the decision it enables. It would be complete if it also said what unit the balance is denominated in and how to interpret a low or zero balance.

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 takes zero parameters, so per the baseline there is nothing for the description to disambiguate. It correctly adds no parameter noise and spends its words on return contents and timing instead.

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?

Uses a specific verb ("Check") against three named resources: prepaid balance, this key's spend caps, and 24-hour spend. This is unambiguous against every sibling, all of which operate on quests rather than account state, so an agent can route to it without opening the schema.

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

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

Gives explicit when-to-use guidance: call it before posting quests to know whether they will be paid instantly, which directly ties it to create_quest. It does not name exclusions or a true alternative tool, but no sibling overlaps in function, so the missing piece is minor.

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 supplied, the description carries the full burden and does reasonably well: it discloses that results are limited to the caller's own quests, that proof data (photo URLs, GPS, timestamp, notes) only appears once submitted, and that photo URLs require the same API key. It stops short of describing error behavior for missing ids or any pagination/size concerns, but the read-only nature is clear from "Get".

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 front-loaded sentence plus a short parenthetical enumeration and an auth caveat; nothing is padded. The trailing "Photo URLs need the same API key" is terse to the point of being slightly cryptic, but it earns its place as non-obvious 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 one-parameter read tool with no output schema and no annotations, the description covers purpose, returned fields, ownership scoping and an auth quirk — enough to call it correctly. The main residual gap is the id format and error/empty behavior, which are minor for this complexity.

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 single quest_id is untyped in prose beyond "by id". The description does add meaningful scope semantics — the id must identify one of your own quests — but gives no hint about the id format or where to obtain it (presumably from list_quests or create_quest).

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?

"Get one of your quests by id" states a specific verb (get), resource (quest), scope (owned quests, singular) and even previews the payload (status plus quester proof). This implicitly separates it from list_quests, though no sibling is named explicitly.

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 single-by-id framing implies the use case (fetch details for a known quest), but there is no explicit when-to-use vs list_quests, no statement about what happens with an unknown or foreign id, and no prerequisites beyond the API-key note about photos.

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 supplied, the description carries the full burden and does disclose two useful traits: results are ordered newest first and are scoped to the caller's own quests. It says nothing about pagination behavior, whether a default limit applies, or how large a result set can be.

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 tight sentences with the core behavior front-loaded and the filter list appended as optional detail. The status enumeration is long but each value earns its place given the schema has no enum. No filler wording.

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

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

For a simple read tool with no output schema and no annotations, the essentials are present, but an agent still cannot tell whether results are truncated, what the default limit is, or what fields come back. Adding one clause about the limit parameter would close the remaining gap.

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

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

Schema coverage is 0%, so the description must compensate. It does so well for status by enumerating all nine valid values, which the schema does not (status is an unconstrained string). However, the limit parameter is left entirely unexplained, with no default or mention of the 200 cap.

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

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

States a specific verb and resource ("List your quests") plus a default ordering ("newest first") and ownership scoping via "your". It clearly distinguishes itself from get_quest by being a list, though it never names that sibling explicitly.

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 word "Optionally" signals that no filter is required, implying the tool can be called with no arguments for a full listing. There is no explicit guidance on when to use this versus get_quest for a single quest, nor any mention of how to page through large result sets.

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

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

With no annotations, the description carries the full burden, and it discloses the key behavioral facts: this is a catalog lookup, the in-person templates require lat/lng coordinates, and remote templates work for anyone anywhere with optional country scoping. It does not state the return format beyond listing names, but for a static enumeration that is a minor gap.

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, front-loaded with the purpose, then a grouped enumeration by category, then the routing instruction. Every clause carries usable information with zero filler.

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

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

For a zero-parameter, side-effect-free listing tool with no output schema, the description supplies everything an agent needs: what is listed, the exact values, their constraints, and the sequencing relative to quest creation.

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 takes zero parameters, so there is no parameter semantics to explain; baseline 4 applies. The description correctly implies no inputs are needed to retrieve the full catalog.

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

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

States a specific verb and resource ("List the quest types") and immediately equates templates with quest types, then enumerates the exact values returned. This distinguishes it cleanly from sibling list_quests, which lists actual quests rather than available templates.

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?

"Call this first to pick the right template" gives explicit ordering guidance and implies it precedes create_quest. It also gives selection criteria (in-person vs remote, country limiting). It stops short of naming create_quest as the follow-up tool or stating when the tool is unnecessary.

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

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

With no annotations, the description carries the full burden, and it does disclose two valuable traits: callbacks are signed, and the signing secret is returned only once (so it must be captured immediately). It omits auth/permission requirements, whether re-calling overwrites the existing endpoint, retry/failure behavior, and delivery semantics — meaningful omissions for a mutation tool with zero annotation coverage.

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 compact sentences, front-loaded with the core effect and the polling alternative, then the one-time secret warning. The event list is long but each entry is necessary information, not padding.

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

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

There is no output schema, and the description does cover the key return value (signing secret, returned once). However, for a write/configuration tool with no annotations and no output schema, an agent still cannot tell what happens on repeated calls, what the response body looks like beyond the secret, or what permissions are needed.

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

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

Schema description coverage is 100% and there is a single parameter ('Your https endpoint'), so the schema already explains the input. The description adds only the implicit HTTPS requirement, which the schema also states, so baseline 3 applies.

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

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

The description names the concrete effect (signed HTTPS callbacks on quest status changes) and enumerates every event type, which makes it easy to distinguish from read tools like get_quest. The registration action itself ('set_webhook') is only implied by 'receive' and 'returns a signing secret once', so the agent must infer that calling this registers an endpoint rather than fetching callbacks.

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 alternative and the condition that selects it: use this 'instead of polling get_quest'. It does not state when not to use it, whether only one webhook can exist, or whether a second call replaces the first, which leaves real gaps for a configuration tool.

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