longwatch

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 this is a one-time, non-persistent snapshot ('This-session snapshot only'), the cost ($0.001 USDC), and the payment requirement (no API key/account, 402 without payment). It also explains what EDGAR does (decodes 8-K items). Good transparency beyond basic structure.

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 paragraph but front-loaded with the core purpose and usage guidance. Every sentence serves a purpose, though it's on the longer side. It's structured logically: purpose → alternative → cost → free demo.

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?

Given the tool's complexity (9 params, 4 types) and no output schema, the description covers the key context: session scope, type semantics, cost and payment behavior, and alternatives. It doesn't detail each parameter, but the schema already does that. The description is sufficient for a competent agent to decide when and how to call it.

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 schema already provides descriptions for all parameters (100% coverage), so the baseline is 3. The description adds context about the 'type' parameter by listing the four types and what they do (e.g., 'edgar (8-K items decoded)'), but it doesn't elaborate on parameter formats or constraints beyond schema. It adds marginal value.

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 clearly states the action ('snapshot'), the scope ('This-session'), and the resource (URL, RSS, price, EDGAR). It distinguishes from create_watch by explaining it's for one-off checks, and lists the four source types with specifics (EDGAR decodes 8-K/Form 4).

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?

Explicitly says when to use ('when you will not come back') and when not to ('If the job spans runs, create_watch instead'), naming the alternative tool. Also provides free alternatives and payment details, giving clear context for decision-making.

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 full burden. It discloses cost, payment mechanics, 402 response on missing payment, the baseline behavior, persistence needs, and type-specific semantics. It tells the agent important side effects and response conditions beyond schema fields.

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 compact yet rich. Each sentence carries relevant info: persistence/cursor, watch types, baseline, cost, payment error, and free alternative. It's front-loaded including 'Keep watching between agent runs' immediately context.

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?

A 10-parameter, no-output-schema tool with 100% schema descriptions is well covered. The description adds important context about watch semantics, payment requirements, and cursor usage. It lacks a bit of detail on full success response, but permissions and failures are handled. Complete enough to avoid misinvocation.

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?

Input schema already covers all 100% of parameters with field descriptions. The description adds meaning by explaining what each watch type does (page text diff, new RSS items, threshold/24h price move, new EDGAR filings), and the baseline behavior that makes the next poll useful. This enriches the parameter meaning beyond the schema.

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 clearly states the tool's purpose: creating a persistent standing watch. It names the concrete result (watch_id and key), lists all four watch types with their specific behaviors, and positions the tool relative to poll_alerts, making it easily distinguishable from 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?

It explicitly explains when to use this tool (start continuous watching across agent runs), how to follow up (later poll_alerts), and gives an explicit free alternative for users without a wallet, so the agent knows when not to call / that alternatives exists.

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 must fully disclose behavior. It only says 'Stop and delete' without clarifying side effects (e.g., irreversibility, required permissions, or impact on related resources). The irrelevant 'Free' remark adds confusion.

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 but includes irrelevant filler ('Free. Free — no payment required.') that detracts from clarity. The useful first sentence is not enough to earn a higher score.

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 deletion tool with no annotations and no output schema, the description fails to cover return behavior, error conditions, or usage context. Sibling tools exist but are not referenced. The description is incomplete.

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 100%—both parameters have descriptions. The tool description adds no extra parameter context beyond what the schema already provides. Baseline score of 3 is appropriate.

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 'Stop and delete a watch' with a specific verb ('Stop and delete') and resource ('a watch'). This clearly distinguishes it from sibling tools like create_watch, check_now, and poll_alerts.

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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., needing a valid watch from create_watch) or when not to use it.

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 provided, the description carries the full burden and does so strongly: it discloses the keep-alive side effect, 7-day expiry, per-call cost via x402, no API key/account requirement, and the 402 failure mode. This is substantial behavioral context beyond the schema.

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 front-loaded with purpose and usage, then covers behavioral, cost, and alternative details. It is a bit long, but each sentence contributes necessary operational context rather than being filler.

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 tool with no output schema and no annotations, it covers purpose, parameters, payment, and failure. However, it does not describe the actual alert response shape beyond the cursor, and error handling is only addressed for the 402 case, leaving the description adequate but incomplete.

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 schema already documents all three parameters with 100% coverage. The description adds useful meaning by tying `since` to the last seen sequence and the returned cursor, and by noting that `key` and `watch_id` come from create_watch.

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 clearly states the tool polls a watch for new alerts and explains 'What is new since your last run' with `since={last seq you saw}`. It is distinct from create/delete watch, but it does not explicitly differentiate itself from sibling tools like check_now or poll_trial.

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 concrete usage context: pass the last seen sequence, the response carries a new cursor, and polling keeps the watch alive. It also offers free alternatives for no-wallet use, but it does not explicitly say when to prefer sibling tools such as check_now or poll_trial.

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 must disclose behavioral traits. It mentions the tool is free, uses a cursor mechanism (since parameter), and is time-limited. However, it does not describe what happens when the trial expires during polling, error behaviors, rate limits, or idempotency. The polling semantics (returning new alerts since given sequence) are only implied via the cursor mention, not fully explained.

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 three sentences, each serving a clear purpose: stating the operation, explaining the parameter usage, and providing the transition to the paid alternative. It is front-loaded with the main action and contains no redundant or unnecessary words.

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?

Given the tool's simplicity (3 params, no output schema, no annotations), the description covers the basic flow and usage boundaries. However, it lacks information about the response format (what the cursor carries, what else is returned) and error conditions. Since there is no output schema, the agent must infer the response structure from the description alone. This gap makes it only partially 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 coverage is 100%, so baseline is 3. The description adds some value by explaining the 'since' parameter usage ('Pass since={last seq you saw}; the response carries a new cursor'), which reinforces the schema description. However, it does not add meaning for 'key' or 'watch_id' beyond the overall context of being returned by try_watch. The description does not significantly exceed the schema's own parameter descriptions.

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 clearly states the tool polls a trial watch created by try_watch. It uses the specific verb 'poll' and identifies the resource as a trial watch. It distinguishes from siblings by mentioning try_watch as the creator and create_watch as the paid alternative, making the purpose 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?

The description explicitly tells when to use this tool vs create_watch ('Once the trial expires, create a paid watch...'). It also implies use after try_watch. However, it does not contrast with the sibling poll_alerts, which might be a similar polling tool, leaving a minor ambiguity. The 'Free' note provides cost guidance.

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?

Without any annotations, the description carries the full burden. It clarifies the free nature, duration, and webhook limitation, but does not disclose error behaviors, response format, or what happens if a trial already exists. It provides adequate but not exhaustive transparency.

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 extremely concise at 3 sentences, front-loads the key differentiator (free trial), and every sentence adds unique value. No redundancy or filler.

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?

Given the tool has 9 parameters, no output schema, and no annotations, the description covers the core behavioral aspects (free, 24h, one at a time, no webhooks) but leaves gaps about response format, error handling, and trial state management. It is adequate but not comprehensive.

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 parameters are well-documented in the schema. The description adds the concept of 'same watch types as create_watch' but does not elaborate on individual parameters beyond what the schema already describes. A baseline of 3 is appropriate.

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 explicitly states the tool creates a free trial watch with no payment or account, and clarifies it supports the same watch types as the sibling create_watch. This clearly distinguishes it from other tools like create_watch and poll_trial.

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 provides excellent usage guidance: use this first to preview alerts before paying, mentions the 24h duration, notes one-at-a-time limitation per caller, and explicitly says it cannot use webhooks. It also recommends the alternative create_watch for production use.

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