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 that the tool returns a list of tasks with specific fields and implies a default filter of open status. It does not mention pagination, sorting, or rate limits, but for a read-only browse tool these are minor. The reobserve explanation describes the task semantics, not the tool's internal behavior, but it adds valuable context about what the returned tasks mean.

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 front-loads the core purpose in the first sentence, then spends several sentences on the reobserve workflow. While that workflow is essential for correct usage, it could be condensed. The structure is logical: purpose first, then special-category explanation. It is not overly verbose, but the reobserve portion is lengthy relative to the simple browse action. It earns a 4 for good structure but loses a point for slightly excessive detail.

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 browse tool with no output schema, the description covers the main return fields and the special category's handling. It does not mention pagination or sorting, but those are not critical for basic usage. It also does not explain how to interpret the 'progress' field beyond naming it, but that is a minor gap. The reobserve rules are fully detailed, making it complete for the most complex scenario. Overall, it is comprehensive enough for an agent to use correctly.

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 all parameters already have descriptions. The description adds meaning beyond the schema by elaborating on the 'reobserve' category, explaining what it means and how to handle those tasks. It also clarifies the default status is 'open' via the schema, and the description reinforces that. It does not add syntax details for limit or status, but they are self-explanatory. The extra context for category elevates it above baseline 3.

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 opens with a clear verb-resource pair: 'Browse open Task Market tasks' and specifies the returned fields (id, category, points value, progress). It distinguishes itself from siblings like task_claim and task_submit_proof by explaining that this is the browsing entry point, not the claiming or proof-filing action. The 'reobserve' category is explicitly tied to those sibling actions, so an agent can immediately tell which tool to use for which step.

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 gives explicit when-to-use and when-not-to-use guidance: for reobserve tasks it instructs to 'claim it with task_claim, then file a proof ... via task_submit_proof.' It also explains the scoring rules and debt consequences, making the workflow unambiguous. No other sibling is mentioned, but the reobserve flow is fully specified, leaving no inference needed for the most complex case.

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