check_watch

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

With no annotations provided, the description carries the full burden and it delivers: 'Read-only against Zameen' explicitly disclaims mutation, and 'the only state kept is the local id list' preempts the natural worry about persistent side effects from re-running a watch. This is exactly the transparency an agent needs when annotations are absent. Minor gap: no disclosure of error behavior for a nonexistent watch name.

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?

Two sentences, zero filler. The core action and differentiator are front-loaded in sentence one, and sentence two adds the single most valuable behavioral fact (read-only). Every word contributes.

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 two-parameter tool with an output schema covering return values, the description is largely adequate: purpose, read-only nature, and state semantics are all stated. The gap is that both parameters — especially the required 'name' — remain semantically unexplained, and error conditions for an unknown watch are unaddressed.

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%, so the description bears full responsibility for explaining parameters, yet it explains neither. 'name' (required) is only inferable as the watch identifier from the phrase 'saved watch', and 'limit' is never described as capping the number of reported NEW listings. The output schema covers return shape but not how these inputs steer it.

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 precise verb-resource pairing: re-run a saved watch's search. The 'report NEW listings since last check' clause is the decisive differentiator, cleanly separating it from search_properties (ad-hoc search), add_watch/remove_watch/list_watches (watch lifecycle), and get_listing_details (per-listing detail).

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 'NEW listings since last check' phrasing clearly implies the incremental-monitoring use case, and 'Re-run a saved watch's search' situates it against a previously created watch. However, no sibling is named and there are no explicit exclusions (e.g., 'for a fresh ad-hoc search use search_properties') — usage is conveyed by implication, not instruction.

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