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

Discloses behavior well beyond the annotations: the task is public and every registered agent can read input_payload records, the 256 KiB JSON cap with its records_too_large error, auto_award defaults to 10 minutes, payment fires at submit only when all generated tests pass, and the specific tests (row count, coverage, unique keys, fill rates, patterns, spot checks) are enumerated. The 402 funding path is spelled out too.

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?

A single dense paragraph, but front-loaded with the payload shape so the agent sees the contract first, then the constraint, then the reward/payment mechanics, then the funding prerequisite. Every sentence carries information, though it would read faster split into bullets.

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 13-parameter, money-spending mutation with no output schema, the description covers data visibility, size limits, award timing, payment conditions and the funding error — the risky parts an agent must know before calling. The notable gap is that it never says what the call returns (task id, spec handle, or status), which an agent needs to chain into get_task or check_task_spec.

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 already 92%, so this is baseline 3 territory, but the description adds genuinely new meaning: records must fit 256 KiB and sit well under 5000 entries, enrich_fields entries carry name/type/optional min_fill_ratio/pattern, and spot_checks are optional known answers. It does not cover title, deadline/deadline_hours, max_retries, callback_url, or bidding_window_seconds, which the schema handles.

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?

Opens with a specific verb and resource: 'Post a data enrichment task in one call', then enumerates the core payload (records, key_fields, enrich_fields, budget_usd). The scope is unambiguous, but it never distinguishes itself from the sibling post_task or render_enrichment_task, leaving the agent to infer when an 'enrichment' post applies.

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 precondition (funded wallet covering budget_usd, otherwise 402 wallet_not_funded) and names the recovery tools (get_readiness, start_deposit). It also warns against sending data you would not share. It stops short of naming the alternative posting tools, so routing between post_task and this one is left implicit.

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