TaskMarket Data

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

No annotations are provided, so the description carries the full burden. It discloses a significant behavioral trait: the cost of $0.001/call USDC on Base via x402 v1 exact scheme, and mentions the payment parameter. It does not explicitly state it's read-only, but the nature of retrieving full details implies a non-destructive operation. The cost disclosure is crucial for an agent to understand invocation requirements.

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

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

The description is exactly two sentences with zero fluff. The first sentence states the function and the specific details returned; the second states the cost and payment scheme. Every word contributes to the agent's understanding, and the description is front-loaded with the core function.

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 get-by-ID operation with full schema coverage and no output schema, the description is complete. It specifies the input (task ID), the nature of the output (full details listing key fields), and the required payment scheme. There are no nested objects or complex behavior to explain further.

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 baseline is 3. The description adds value beyond the schema by explaining the payment context ($0.001/call USDC and the x402 v1 scheme), which relates to the optional 'payment' parameter. It also clarifies that the taskId is a 32-byte hex ID (even though that's already in the schema). The description does not need to restate parameter syntax.

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

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

The description clearly states the tool's function: 'Full details of one TaskMarket task by ID' and enumerates the specific fields returned (reward, mode, deadline, acceptance criteria, demand). This is specific and distinct from the sibling tools (list and submissions), which clearly handle different operations.

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 context: when you need full details for a single task given its ID. It differentiates from tm_list_tasks (which lists tasks) and tm_task_submissions (which deals with submissions). However, it does not explicitly state when not to use it or mention alternative tools by name, though the need for a task ID is clear.

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

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

No annotations are provided, so the description carries the burden. It mentions the cost and payment scheme ($0.001/call USDC on Base via x402 v1), but does not explain the two-step payment process (first call returns terms, then pay and call again). The input schema partially covers this, but the description lacks explicit behavioral disclosure.

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

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

The description is a single concise sentence that includes the core purpose, key attributes, and cost. No unnecessary words or fluff.

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?

While the description covers the basic purpose and attributes, it omits the crucial two-step payment flow required to actually retrieve data. This is a significant operational detail that an agent needs to use the tool correctly, making the description incomplete despite its simplicity.

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 single parameter 'payment' is fully described in the schema. The description adds cost context but does not elaborate on the parameter itself. Since schema coverage is 100%, baseline is 3; the additional cost information slightly enhances understanding but does not exceed the baseline.

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

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

The description clearly states the tool's purpose: listing open TaskMarket tasks with specific attributes (reward, mode, deadline, submission demand). It also distinguishes from sibling tools like tm_get_task (single task) and tm_task_submissions (submissions).

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 the tool is for listing all open tasks, but does not explicitly provide guidance on when to choose this over tm_get_task or tm_task_submissions. No alternatives or conditions are mentioned.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses a genuinely material trait: the call costs $0.001 via x402 v1 exact scheme, and that omitting payment returns payment terms (a two-step invocation flow). However, it doesn't describe error cases (e.g., invalid taskId, nonexistent task), pagination limits, or rate constraints — notable gaps for a paid API endpoint.

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, front-loaded sentence delivers purpose, result scope, cost, and payment mechanism with zero filler. Every clause earns its place; the efficiency is exemplary.

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 2-param tool with no output schema and complete schema coverage, the description adequately covers the essentials: what it does, what it returns (workers, ratings, artifacts hint at the payload shape), and the payment workflow. It falls slightly short only on failure-mode documentation, but given the tool's simplicity, this is a minor gap rather than a systemic deficiency.

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 both taskId (32-byte hex) and payment (base64 X-PAYMENT value) are fully documented in the schema. The description adds marginal value by contextualizing the payment parameter with the $0.001 cost and x402 scheme, but it doesn't clarify semantics beyond the schema, which is the baseline-3 situation.

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 uses a specific verb+resource pairing: 'List submissions of one TaskMarket task by ID,' and enumerates the result contents (workers, ratings, artifacts). It clearly differentiates from siblings tm_get_task (fetch a task) and tm_list_tasks (list tasks) by scoping to individual task submissions.

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 payment flow is implied ('omit to receive payment terms'), giving a sense of when the two-step call sequence is needed, and the 'by ID' scoping indicates this is for a single task. However, no explicit when-to-use vs. alternatives guidance is provided — it doesn't state 'use tm_list_tasks to discover tasks first, then call this with a taskId,' nor does it name sibling tools as alternatives.

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