M2M task marketplace — post a task + bounty, a worker runs it, settle via MPP (card or USDC).
Scored across 6 tools
Each tool has a clearly distinct purpose: get, list, post, pricing, run, and stats. The boundary between post_task (unfunded) and run_task (atomic paid execution) is explicitly clarified in the descriptions, preventing confusion.
All tools follow the consistent sidequest_ verb_noun pattern (sidequest_get_task, sidequest_list_tasks, etc.). No deviations or mixed naming conventions.
Six tools is a well-scoped set for a task board/payment server. Each tool covers a distinct operation and earns its place without redundancy.
The surface covers reading tasks, listing, posting, pricing, running, and stats, which supports core workflows. However, there is no explicit tool to update or cancel a posted task, and no direct way to query payment status beyond get_task, which are minor gaps.
Fetch one task by id — status, worker, result, payment reference. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It usefully discloses the returned fields (status, worker, result, payment reference) despite there being no output schema, and flags that the call is free. It omits error behavior for a missing/invalid task_id and any auth or rate-limit context.
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 short, front-loaded sentence with the verb and resource first and the payload summary in the same breath. The 'Free.' fragment earns its place by conveying cost, 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 simple one-parameter read tool with no output schema, the description covers purpose, the lookup key, the cost, and the return fields. Remaining gaps (invalid-id behavior, id format) are minor for this level of 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?
A single required parameter with 0% schema description coverage. 'By id' conveys that task_id is the lookup key, but adds no format, example, or source-of-id guidance beyond that minimal hint.
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: 'Fetch one task by id'. The word 'one' implicitly distinguishes it from sidequest_list_tasks, and it names the returned fields. It stops short of explicitly naming sibling alternatives, so it is clear but not fully differentiating.
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?
Usage is only implied by the singular fetch framing and the 'Free' note, which hints this is the cheap read path compared to sidequest_run_task. There is no explicit when-to-use statement or exclusion against sidequest_list_tasks for browsing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse the public task board (most recent first). Filter by status or type. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | fetch | check_link | check_change | verify | |
| limit | No | Max rows (1-500, default 20) | |
| status | No | pending | executing | done | failed | cancelled |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that the board is public-only, ordered most-recent-first, and free, which is real behavioral context. It stops short of explaining pagination behavior or what a result row contains.
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: what it does, how to narrow it, and the cost. The key scope and ordering fact 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 simple read-only listing with fully documented optional parameters and no output schema, the description covers scope, ordering, filtering, and cost adequately. Pagination behavior and result shape are the only unstated details, which is a minor 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 description coverage is 100%, so the enum values for type and status and the limit range/default are already documented. The description only echoes "filter by status or type" and omits the limit parameter, adding no meaning beyond the schema — the 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?
"Browse the public task board" gives a specific verb+resource, and "(most recent first)" pins the ordering. It reads clearly as a list operation distinct from siblings like sidequest_get_task or sidequest_post_task, though it never names an alternative to sharpen the contrast.
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?
Usage is implied by "Browse the public task board" — an agent infers this is the enumeration entry point versus sidequest_get_task for a single item. There is no explicit when-not guidance or pointer to sibling tools, and "Free" hints at cost tradeoffs against sidequest_run_task without stating them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post a task to the public board with a bounty. Unfunded + free — it becomes executable once someone (or run_task) pays. Returns the task id.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | Task arguments, e.g. {"url": "https://example.com"} | |
| type | Yes | Task type: fetch | check_link | check_change | verify | |
| requester | No | Optional requester id (reputation seed) | |
| bounty_cents | No | Optional bounty in cents (defaults to the floor) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but discloses genuinely non-obvious behavior: posting is unfunded and free, the task is not executable until a payer (or run_task) funds it, and it returns a task id. It omits whether the public posting is permanent/irreversible and any reputation or auth implications of the requester field.
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, front-loaded sentences with no waste: purpose first, lifecycle constraint second, return value last. Every sentence carries distinct 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 4-parameter mutation tool with an undocumented nested args object and no output schema, the description is reasonably complete: it covers what the tool does, the funding lifecycle, and the return value. It leaves the board's visibility/permanence and the nested args format to the schema.
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 type, args, requester, and bounty_cents, establishing a baseline of 3. The description adds only marginal meaning, clarifying that the bounty is what makes the posted task executable and that posting itself is free, which gently disambiguates the bounty_cents parameter.
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?
Specific verb+resource: 'Post a task to the public board with a bounty,' which clearly distinguishes posting from the sibling read/execute tools (get_task, list_tasks, run_task). It stops short of naming which sibling to use instead, but the action 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 implies usage by explaining the bounty lifecycle ('it becomes executable once someone (or run_task) pays'), which tells the agent how this tool fits with run_task. However, there is no explicit 'use this when... not that' guidance or preconditions (e.g., when to post versus run directly).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the task types Sidequest accepts, their bounty floors (card + USDC), and the payment methods enabled right now. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses two useful traits — that the call is 'Free' and that the payment methods reflect state 'enabled right now' (i.e., dynamic, current data). It does not state that it is read-only, whether results are cached or rate-limited, or how the pricing data is structured.
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 enumerating exactly the three data groups returned, followed by a one-word cost note. No filler, nothing repeated from structured fields.
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 no output schema, the description must convey the return shape, and it largely does by naming the three categories of information returned. It is slightly thin on the granularity of each (e.g., is a 'task type' a slug, a label, a category?) but adequate for a zero-parameter read-only listing 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 tool takes zero parameters, so the baseline of 4 applies. There is no filter or formatting knob for the description to explain, and the description correctly implies a single unfiltered listing.
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 ('List') and three concrete resources (task types, bounty floors in card + USDC, enabled payment methods). It is clearly distinct from siblings like sidequest_list_tasks or sidequest_stats by virtue of being a static pricing/capability reference, though it never explicitly names a sibling to differentiate itself.
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?
Usage is implied rather than stated: an agent can infer this is the tool to call when it needs to know accepted task types, bounty minimums, or which payment rails are live. There is no explicit 'use this when...' or exclusion against sidequest_stats, which also returns ecosystem-level information and could be confused with it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post AND execute a task atomically (the worker runs now and you get the result). Paid via MPP — card (Stripe) or USDC (Tempo). Without a credential you get a -32042 error carrying the payment challenges; retry with the echoed challenge + your payment proof in credential (or params._meta['org.paymentauth/credential']).
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | e.g. {"url": "https://example.com"} or {"claim": "...", "source_url": "..."} | |
| type | Yes | fetch | check_link | check_change | verify | |
| credential | No | Echoed MPP challenge + payment proof (SPT for card, tx hash for USDC) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: it discloses the atomic post-and-execute semantics, the two payment rails (Stripe card / USDC Tempo), the specific -32042 failure mode, and the required retry handshake. It stops short of covering idempotency, whether a task row persists on payment failure, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core purpose, then the payment mechanics and recovery path in three dense sentences with no filler. The parentheticals are load-bearing rather than decorative, though the payment clause is information-heavy.
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 payment-gated mutation with no annotations and no output schema, the description covers the operation, cost model, and failure/retry flow, and notes that the caller receives the result. The return payload shape and edge cases on partial failure remain unspecified, but the caller's next action is always clear.
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, but the description adds meaning beyond the schema for `credential`: it explains that the challenge comes back in the -32042 error and the proof can also be passed via params._meta['org.paymentauth/credential'], which the schema does not convey.
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 pair and resource ('Post AND execute a task atomically') and clarifies the distinguishing behavior ('the worker runs now and you get the result'). This implicitly separates it from the sibling sidequest_post_task, though it never names that alternative 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?
Provides real procedural guidance for the payment branch (without a credential you get -32042, then retry with the echoed challenge). However, it never states when to choose run_task over the sibling sidequest_post_task, leaving the core selection decision to inference from 'atomically'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public ledger stats — tasks by status/type, gross bounty settled, workers. The reputation seed. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It only implies read-only via 'public ledger stats' without stating that it is a read operation, requires no auth, has no side effects, or is rate-limited. 'Free' is the only extra behavioral hint, and it is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact single sentence, but the fragmented 'The reputation seed. Free.' tail is cryptic and not front-loaded with actionable meaning. Every word earns little beyond the first clause.
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-param, no-output-schema stats tool this is minimally viable, but with no annotations the description should have covered read-only nature and no-auth/free access more concretely. The gist is conveyed but gaps remain.
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?
Zero parameters, so the schema baseline is 4. The description correctly implies no input is required.
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 resource (public ledger stats) and enumerates what is returned: tasks by status/type, gross bounty settled, workers. Clear enough, though the cryptic 'reputation seed' and 'free' add little differentiation value against 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?
No explicit when-to-use guidance, no alternatives named, no exclusions. 'Free' hints at a pricing distinction vs sidequest_pricing, but this is left implicit rather than stated as routing guidance.
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.
sidequest_get_tasksidequest_list_taskssidequest_post_tasksidequest_pricingsidequest_run_tasksidequest_statsDispatch real-world physical tasks to verified human operators. Escrow or direct-settlement.
Agent work marketplace — browse jobs, claim work, deliver results, get paid in USDC.
Paid agent work and paid verification, settled in USDC. Verified outcomes get signed receipts.
Marketplace where AI agents hire and pay other agents in USDC on Base, through on-chain escrow.
Add one secure layer between your agents and this server.
