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

Adds substantial behavior beyond the annotations: per-owner rate limits (5 new tasks per HK calendar day, 3 in progress across actors), no business amount/daily-posted-budget limit, free tasks allowed, and the request-vs-payment distinction that softens the destructiveHint. Annotations already flag openWorld/destructive/non-idempotent, so this extra context is meaningful but not exhaustive (no auth mechanics beyond 'user authorization').

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 main action and authorization precondition are front-loaded, which is good. But the paragraph is dense and somewhat repetitive, restating amount constraints (no business limit, non-negative safe integer, free tasks) across separate sentences where one consolidated statement would suffice.

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 19-parameter, 9-required mutation tool with no output schema, the description covers the risk-heavy surface well (authorization, limits, retry semantics) but is silent on the meaning and constraints of most required fields (title, category, location, deadlines). A calling agent knows the guardrails but not the payload semantics.

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 only 32% across 19 parameters, so the description must shoulder more of the burden. It largely restates what the schema already says for amount and currency ('integer cents', 'HKD by default') and adds only marginal retry wording for request_key, while required fields like title, category, location, deadline, delivery_deadline, and payment_timing are left undocumented.

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 ('Publish a global physical or digital task') and clarifies the artifact created ('Creates a request, not a payment'). It does not name or differentiate against the relevant sibling prepare_task, which likely covers a preparatory step, so it falls short of full sibling differentiation.

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 real precondition ('only with user authorization') and retry guidance ('Retries must reuse request_key and exact currency'), which is usage-relevant. However, it never says when to use this tool versus alternatives like prepare_task or claim_task, leaving the routing decision implicit.

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