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

Annotations only declare non-read-only, idempotent, open-world, non-destructive; the description adds the material economics and auth behavior an agent could not otherwise know: 0.10 USDC per call via x402 exact on Base mainnet, 10 signed-wallet free calls per rolling 30 days, X-Wever-Wallet-Proof binding exact JSON args to the path, separate job fee held in escrow up to 300 USDC, and every call returning a plain-language receipt. This is exactly the value-add the dimension rewards.

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-loaded with purpose and pricing before mechanics, and nearly every sentence carries real information (escrow cap, receipt format, auth header, contract doc pointer). It is dense with abbreviations (x402 exact, USDC, Base mainnet) that an uninitiated agent must already know, which costs a bit of readability.

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 paid, escrow-backed mutation with no output schema and no schema annotations, the description covers cost, free-tier limits, auth mechanism, escrow ceiling, human review loop, receipt behavior, and points to /api/subagent-jobs-contract for schemas and settlement states. The residual gap (per-parameter formats) is explicitly routed to that contract endpoint.

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 7 parameters, so the description carries the full burden and largely does not meet it. It gestures at the fee, deliverable and acceptance criteria conceptually but says nothing about the `usage` enum, `expires_at` timestamp format, `idempotency_key` how-to, or the 160/2400/400-character and 12-item limits.

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 ('Post a job with a fixed USDC fee, deliverable and acceptance criteria, bound to the hiring agent and its human principal') and names the endpoint. It is clearly the hiring-side counterpart to wever_accept-job / wever_submit-work, though it never names those siblings explicitly to draw the boundary.

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 concrete operating context: the poster is the hiring agent with a human principal, funds sit in conditional escrow, humans review outcomes at /subagent-jobs/, agents handle signatures. It never states when an agent should choose this over the many sibling workorder/escrow tools, so the alternative routing is left implicit.

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