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

With no annotations at all, the description carries the full burden and does well: it discloses that the initial baseline is silent (no notification burst on creation), that polling is persistent and independent of the calling process, that the Telegram destination is administrator-configured rather than caller-specified, and what triggers a notification. It omits auth requirements, any cap on concurrent watches, and failure/retry behavior, which keeps it from a 5.

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?

Five short, front-loaded sentences with no filler; the most important behavioral facts (persistence, silent baseline, notification scope) come first. The fragmentary style and the unexplained 'Hermes' reference cost it a point.

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 mutation-style tool with zero annotations and no output schema, the description covers runtime behavior well but leaves the agent guessing about parameter meaning and about what is returned on success (presumably a watch identifier). Adequate but with clear gaps given the 0% schema coverage on a nested-object parameter.

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 must compensate and largely does not. It only addresses 'interval_seconds' (default 600, which the schema already states as a default) and constrains 'query.order' to newest_first — a genuinely new constraint since the enum allows other values. The 'name' parameter and the price/section/currency/marketplace fields of the nested query get no explanation at all.

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 concrete verb+resource: 'Create persistent polling', and adds scope that separates it from one-shot siblings like search_items ('persistent', 'silent initial complete baseline'). It never names a sibling explicitly, and 'independent of Hermes' is opaque jargon that assumes prior knowledge, so it falls short of a 5.

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?

'New IDs only, not price drops' and 'Watch queries must use newest_first' give the agent real constraints on when this tool is appropriate and how it behaves once active. However, there is no explicit statement of when to choose create_watch over search_items or how it relates to list_watches/update_watch, so usage is only implied.

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

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

With no annotations, the description carries the full burden, and it sometimes delivers: it discloses the real side effect that seen IDs are removed while global deduplication and queued deliveries survive, which is behavior an agent could not infer from the schema. However, it never states whether the deletion is irreversible, what permissions are required, or what happens if the watch_id is unknown.

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 front-loaded sentence with zero filler, split cleanly between what is destroyed and what is preserved. It is arguably too terse for a destructive tool, but every word earns its place.

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 an irreversible mutation with no annotations, no output schema, and an undocumented required parameter, the description is thin. It omits irreversibility, error semantics, and any hint about prerequisites such as locating the watch_id via list_watches.

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 needs to compensate, but it says nothing about watch_id — not its origin, how to obtain it (e.g., from list_watches), or whether the watch must be paused first. Only the schema's integer type and minimum 1 constrain the argument.

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 states a specific verb and resource ("Delete a watch") and names what is removed alongside it ("its seen IDs"), which distinguishes it from siblings like pause_watch or update_watch. It stops short of explicitly naming those alternatives, so it does not reach the top of the scale.

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?

There is no when-to-use or when-not-to-use guidance at all, even though pause_watch is an obvious softer alternative that an agent might prefer. The agent must infer the delete-versus-pause decision entirely from sibling names.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that no credentials are required and names some state fields returned, but it does not explicitly state read-only behavior, pagination, ordering, or error-handling semantics; the 'List' verb weakly implies a read operation.

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 is short and front-loads the main list action before listing returned state categories. The fragment 'No credentials' is slightly telegraphic but still useful, and there is no wasted wording.

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 zero-parameter list tool with no output schema, the description gives the main return categories but omits result shape, ordering, pagination, and how it relates to sibling read/status tools. It is adequate but leaves gaps an agent would need to infer.

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?

There are zero parameters, so there is no parameter semantics to document. The schema is empty and the description does not need to compensate for missing parameter documentation.

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 uses the verb 'List' with the resource 'persistent searches' and enumerates returned state categories such as baseline state, scan freshness, and errors. It distinguishes the tool from mutation/control siblings like create_watch and pause_watch, though it does not explicitly differentiate it from monitoring_status or search_items.

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 list operation implies its usage, and the phrase 'No credentials' hints at access conditions. However, there is no explicit when-to-use guidance, no exclusion of monitoring_status or search_items, and no prerequisites or routing advice.

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

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

No annotations are supplied, so the description must carry the full behavioral burden. It mentions authentication and the data points checked, but omits whether the tool is read-only, what permissions are required, and whether it triggers external actions such as contacting Telegram.

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 is a single compact sentence with no filler, and the three monitored items are front-loaded. The fragment style leaves some ambiguity, but it is not verbose or structurally wasteful.

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?

With no annotations and no output schema, the description should explain the return shape or at least what the status report includes. It lists three signals but leaves the agent unable to interpret freshness thresholds, error format, or backlog 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?

The tool takes zero parameters, so the baseline is 4. The description does not need to explain parameter usage, and the empty schema is sufficient.

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 names the monitored signals—scan freshness, errors, and Telegram backlog—so the general purpose is inferable. However, it is a noun phrase with no verb, and 'authenticated scan' is ambiguous without context. It is still distinguishable from the watch-management siblings.

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?

There is no explicit guidance on when to use this tool versus alternatives. Usage is only implied by the listed data points, and no exclusions or sibling routing are provided.

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

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

With no annotations, the description carries the full behavioral burden and does add one useful detail: previously queued notifications still deliver. However, it does not explain the resulting watch state, permissions, reversibility, idempotency, or what happens to scans already in progress.

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 is short, front-loaded with the main action, and avoids unnecessary wording. The semicolon cleanly adds the queued-notification behavior, though the term "scans" is slightly ambiguous.

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?

This is a mutation tool with no annotations, no output schema, and an undocumented required parameter. The description mentions one important side effect, but it is not complete enough for an agent to understand the state change, permissions, or recovery path.

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 should compensate by explaining watch_id, but it never mentions the parameter. Its meaning as the identifier of the watch to pause is only inferable from the tool name and schema field name.

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 gives a specific verb, "Pause," but the resource is described only as "scans" rather than clearly as a watch. The watch context is inferable from the tool name and sibling tools, but the description itself does not explicitly tie the action to a watch.

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?

There is no explicit guidance about when to use pause_watch versus resume_watch, delete_watch, or update_watch. Usage is only indirectly implied by the verb "Pause."

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

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

With no annotations, the description carries the full behavioral burden, and it only gestures at traits via unexplained jargon: 'bounded recovery' and 'ID deduplication' hint that replay is limited and duplicate items are filtered, but no bounds, error behavior, idempotency, or resulting state change is disclosed. Nothing tells the agent what happens if the watch is already running or if the watch_id does not exist.

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?

One front-loaded sentence with no filler or repetition. It loses a point only because the compact phrasing spends its words on unexplained jargon rather than on information the agent can act on.

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?

This is a state-changing operation with no annotations, no output schema, and an undocumented parameter, so the description should do more work. Key facts are missing: preconditions, failure modes, whether resumption is idempotent, and what 'bounded recovery' or 'ID deduplication' concretely mean for the caller.

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% and the single parameter watch_id is not mentioned in the description at all. The name is self-explanatory enough to prevent total failure, but the description adds no meaning such as required watch state, expected errors, or what the integer identifies.

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 ('Resume') against the resource implied by the watch family, and the antonym relationship with sibling pause_watch makes the intent readable. The object of the verb is 'scans' rather than 'a watch', which adds slight ambiguity, but an agent can still tell what operation this performs.

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?

There is no explicit when-to-use guidance, no statement that the watch must currently be paused, and no naming of alternatives (e.g. create_watch or update_watch for cases where no paused watch exists). The agent must infer the precondition from the tool name alone.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses local vs. category-path filtering per section, that paginated results can move or repeat, and the absence of reliable timestamps, exhaustive coverage, and price-drop detection. These are exactly the operational caveats an agent needs before trusting results.

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 most important constraint (immediate, one page, no watch) is front-loaded, and each subsequent line adds a distinct caveat rather than repeating. The telegraphic fragment style is dense but slightly reads as notes rather than prose.

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 search tool with no output schema, it covers the behavioral limits (pagination instability, coverage gaps) that would otherwise mislead a caller. It omits any indication of the result shape and the price-filter semantics, which are the remaining gaps.

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 must compensate, and it partially does: it explains section semantics (all excludes Lavoro), the order default, and that ordering is not filtering. It says nothing about min_price/max_price, page, or limit semantics, leaving a meaningful portion of the nested query object 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?

"Immediate one-page Italy/EUR search" names a specific verb and a tightly constrained scope, and "no watch or Telegram message" distinguishes it from the sibling family of watch-management tools. It stops short of a crisp one-line statement of what it returns, but an agent can tell what it is for.

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 "no watch" phrasing implies this is the one-shot alternative to create_watch, and it instructs the caller to set section and order explicitly and warns that newest is ordering rather than a time filter. However, it never names an alternative tool or states an explicit when-not-to-use condition, leaving the routing inference implicit.

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

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

With no annotations at all, the description carries the full burden and does add real behavioral context: filter changes reset a silent baseline, queued notifications survive the update, and unsupported filter types are called out. It still omits error behavior for an invalid watch_id, whether a name/interval-only change also touches the baseline, and what the call returns.

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?

Four short sentences, front-loaded with the mutation semantics, no filler. The phrase 'silent baseline' is slightly jargon-y but is the key operational detail and is placed early rather than buried.

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 no-annotation, no-output-schema mutation tool with an undocumented nested Query object, the description covers the important side effects but leaves interval units, watch_id validity handling, and response shape unaddressed. Adequate, not complete.

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 must compensate; it correctly conveys that query is a whole-object replacement (not a merge), which is genuinely non-obvious from the schema. But watch_id is never mentioned, and interval_seconds is left without units or the 60–604800 bounds, so the compensation is partial.

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 names the three mutable facets (query, interval, name) and makes clear the query is fully replaced rather than patched, which distinguishes it from create_watch. It never states plainly that this modifies an existing watch identified by watch_id, but the verb 'replace' plus the sibling set makes the intent unambiguous.

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?

It implicitly steers the agent toward create_watch for new watches and away from this tool for price-drop or time-filter needs by declaring those filters unsupported. However, it never names an alternative tool or states a when-not condition (e.g., use pause_watch to suspend rather than editing), so the routing guidance is only implied.

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