longwatch

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

Annotations already declare readOnly, idempotent, and open-world, but the description adds genuinely new behavior: a $0.001 USDC x402 charge per call, no API key or account needed, and a 402 response with payment requirements when unpaid. That is exactly the pre-call context an agent needs; only return shape and any rate limits are left unstated.

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 purpose is correctly front-loaded, but roughly half the text is a promotional block pointing at unrelated demo endpoints (including an NVDA Form 4 sample, which has nothing to do with crypto prices). Useful payment info is diluted by marketing copy.

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 paid, no-output-schema tool backing a 'does it meet the condition' check, the description never indicates what comes back — a boolean, the price, both? Given there is no output schema, that return-shape gap is the agent's remaining blind spot, though payment and auth behavior are well covered.

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%, and the schema itself documents the CoinGecko id format, the USD threshold examples, and the 'provide above, below, or move_pct_24h' exclusivity rule. The description only restates those concepts at a high level, adding no syntax or edge-case detail beyond the schema, so baseline 3 applies.

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 first sentence gives a specific verb and resource ('Check a CoinGecko asset price') plus the evaluated conditions ('USD threshold or 24-hour move condition'), so the operation is unambiguous. It does not explicitly contrast itself with the closely-named sibling watch_crypto_price, leaving the one-shot vs. persistent-watch distinction to inference from the tool names.

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?

Usage context is implied rather than stated: the payment terms and the free sample/watch endpoints signal this is a paid one-shot check with free alternatives. However, it never tells the agent when to pick this over watch_crypto_price (persistent monitoring) or check_now, which is the sibling decision that actually matters.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds behavior they cannot express: exact cost ($0.001 USDC per call, Base), the payment protocol (x402), that no API key/account is required, and the failure mode (unpaid calls return 402 with payment requirements). That is precisely the extra context an agent needs to decide whether and how to invoke it.

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 capability statement is front-loaded and the pricing/auth sentences each carry operational weight. The closing free-alternative sentence with two raw URLs is partly promotional and could be trimmed, though it still serves a routing purpose.

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 read-only fetch tool with fully documented params and no output schema, the description compensates well by listing the return fields (buyer/seller, shares, value, type, 10b5-1 status). The remaining gap is the undefined scope of 'recent' — no lookback window, count, or limit is mentioned or parameterized, so the agent cannot anticipate result volume.

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% and the schema descriptions already state that ticker and cik are alternatives with examples (NVDA, 1045810). The description's 'for a ticker or CIK' merely restates that relationship without adding format or precedence rules, so the baseline 3 applies.

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 first sentence names a specific verb and resource ('Get recent Form 4 insider transactions for a ticker or CIK') and enumerates the parsed fields returned, so the agent knows exactly what it retrieves. It does not explicitly distinguish itself from the sibling watch_insider_trades (one-shot lookup vs. recurring watch), leaving that contrast to be inferred from the verb 'Get recent'.

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 gives concrete operating context — paid per call via x402, no API key or account needed, and a 402 response if unpaid — which tells the agent what to expect before calling. It also routes to free alternatives, but at the external-URL level only; it never says when to prefer the sibling watch_insider_trades over this one-shot check.

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 annotations already declaring destructive/openWorld/non-idempotent, the description still adds critical context: cost ($0.001 USDC per call on Base), no API key or account, and that an unpaid call returns a 402 with payment requirements rather than failing silently. It also discloses probe behavior (validates the 402 challenge without sending payment) and output decoding (8-K items decoded, Form 4 trades parsed).

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?

Front-loads the most decision-relevant fact (snapshot-only, no cursor) before alternatives, per-type requirements, and pricing — a sensible ordering. It is dense and clause-heavy, and could be broken into shorter sentences, but almost every clause carries distinct information rather than 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 14-parameter tool with no output schema, the description covers the essentials an agent needs: temporal scope, conditional parameter requirements, payment flow and failure mode, and qualitative description of what comes back per type. What it does not do is hint at the response structure (e.g. snapshot shape or field names), which matters more here because no output schema exists.

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 the baseline is 3; the description goes beyond the flat schema by stating cross-parameter conditional requirements per type (url/rss/x402 → url; price → coin plus one of above/below/move_pct_24h; edgar → ticker or cik). That conditional routing is not obvious from the schema alone and is genuinely useful, though it doesn't cover the x402 expectation params.

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 concrete verb and a family of concrete resources (url/rss/price/edgar/x402) and immediately names its scope: "this-session snapshot only — no watch, no cursor." It also explicitly contrasts with the watch_* family ("If the job spans runs, create_watch instead"), so an agent can distinguish it from ~18 siblings without opening a schema.

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 explicit when-to-use ("use when you will not come back"), when-not (multi-run jobs → create_watch with watch_id + key), and two named free alternatives (longwatch.dev/demo and /try) for agents without a wallet. Nothing about selection is left to inference.

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?

Adds substantial context beyond the annotations: cost ($0.001 USDC via x402 on Base), no API key/account needed, and the exact failure mode (402 with payment requirements) when unpaid. The annotations already cover safety (readOnly, idempotent, non-destructive), and the description correctly reinforces rather than contradicts them. The free-alternative endpoints are useful but read partly as promotion.

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 core purpose and payment mechanics are front-loaded and efficient, but the trailing free-alternative URLs (demo NVDA Form 4 sample, 24h trial watch) are tangential to calling this tool and dilute focus.

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 one-parameter read tool with full annotation coverage and no output schema, the definition covers purpose, cost/payment flow, and error behavior adequately. Return shape ('latest items') is only sketched, but that is a minor gap.

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% for the single 'url' parameter, which is already documented as a 'public RSS or Atom feed URL.' The description adds the RSS/Atom acceptance detail but nothing about format or validation beyond the schema; baseline 3 applies.

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 ('Read the latest items from a public RSS or Atom feed') with clear scope ('now', 'one-session lookup'). It implicitly contrasts with the sibling watch_rss_feed but never names it, so an agent must infer the persistent-watch counterpart.

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 scopes usage to 'a one-session lookup,' which tells the agent this is the non-recurring option. It offers free alternatives (demo/try endpoints), but doesn't explicitly route recurring use to watch_rss_feed.

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?

Goes well beyond the readOnly/idempotent annotations by disclosing payment mechanics: $0.001 USDC per call via x402 on Base, no API key or account, and a 402 response with payment requirements when unpaid. This is exactly the kind of operational detail an agent needs before invoking a paid endpoint.

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?

Purpose and return contents are front-loaded in the first sentence, with payment terms immediately after. The trailing free-alternative URLs are slightly promotional but still operationally useful, so the length is largely justified.

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?

No output schema exists, and the description fills the main gap by naming the decoded 8-K items and parsed Form 4 transactions. It still omits result count, date range, and pagination behavior, leaving some uncertainty about what 'recent' means.

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% and already documents ticker, cik, and forms with examples. The description only restates 'ticker or CIK' and adds nothing on the forms filter or mutual exclusivity beyond what the schema says, so the baseline 3 applies.

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 ('Get recent SEC filings for a ticker or CIK') and adds what is returned ('decoded 8-K items and parsed Form 4 transactions'). It does not name the obvious sibling watch_sec_filings to explain one-shot vs recurring monitoring, so differentiation is only implied via the '/try 24h watch' mention.

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 clear context on when to use it (fetch filings now for a ticker/CIK) and points to free alternatives (demo sample, 24h try endpoint) when no wallet is available. It lacks an explicit exclusion such as 'for ongoing monitoring use watch_sec_filings', leaving that inference to the agent.

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?

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavior: $0.001 USDC per call via x402 on Base, no API key or account, and a 402 response carrying payment requirements when unpaid. Only gap is a thin characterization of what "normalized text metadata" actually contains.

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 core action and pricing come first, followed by the free alternatives, which is the right order for an agent deciding whether it can even call this tool. The two fallback URLs with their full descriptions are somewhat verbose but still information-bearing rather than 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 single-param read tool with no output schema, the description covers cost, auth model, failure response (402) and a free escape hatch. What remains unstated is practical envelope detail: page-size limits, JS-rendered content handling, and what fields the returned metadata includes.

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 is a single required `url` parameter and schema description coverage is 100%, so the schema already declares it as a "public http(s) page URL". The description adds no syntax, format or constraint detail beyond that baseline.

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?

"Fetch a public web page now and return normalized text metadata" gives a concrete verb, resource and output shape. The "one-session lookup" framing implicitly separates it from the watch_web_page sibling, though it never names that tool outright.

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?

"Use for a one-session lookup" establishes the usage context, and the description explicitly points to free alternatives (GET /demo, POST /try) for wallet-less cases. It stops short of naming watch_web_page as the alternative for repeated/persistent checks.

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?

Adds real context beyond the annotations: cost of $0.001 USDC per call on Base, no auth requirements, and the expected 402 response when unpaid. However, the annotations declare destructiveHint=true and readOnlyHint=false, and the description itself never warns that probing can alter the target -- that caveat lives only in the method parameter's schema text. The description therefore leaves the most safety-critical behavior undisclosed.

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, front-loaded with the core action and followed by payment mechanics. The trailing free-alternative sentence is somewhat promotional and drifts into unrelated NVDA/Form 4 detail, slightly diluting an otherwise tight definition.

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?

There is no output schema, so the description should explain what the tool returns; it only states that an unpaid call returns a 402 from the target, not what the tool itself reports back to the caller (validation result, mismatches, recipient). With six parameters and a nested object, that is a meaningful gap.

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%, so all six parameters are already documented in the schema, including the destructive POST/PUT/PATCH warning and the atomic-units example. The description mentions networks, scheme, amount and recipient but adds no syntax or format detail beyond the schema. Baseline 3 applies.

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?

Opens with a specific verb and resource: 'Send an unpaid request and validate the endpoint's HTTP 402 challenge, accepted networks, scheme, amount, and recipient.' That is far more precise than the tautological title. It never names the sibling watch_x402_endpoint, so an agent must infer the boundary between validating once and creating 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?

Gives clear conditions: no payment is attached, no API key or account is needed, and calling without payment yields a 402 with the payment requirements. It also offers a free alternative path. It does not say when to prefer this over watch_x402_endpoint, which is the most relevant sibling.

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 annotations already declaring destructiveness and open-world behavior, the description adds substantial context: the $0.005 USDC x402 cost on Base, no API key or account needed, the 402 response with payment requirements when unpaid, that creation includes the baseline plus 7 days of polling, and that a webhook is optional while polling still works. This is exactly the pricing/auth/failure-mode detail annotations cannot express.

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?

Purpose and persistence contract are front-loaded, then the type requirements, then cost — a sensible order with no repeated content. The closing free-alternative sentence is longer than strictly necessary and reads slightly promotional, but it does carry actionable routing information for wallet-less agents.

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 16-parameter, nested, destructive, paid mutation tool with no output schema, the description supplies the pricing model, the payment failure mode, the id persistence contract, the polling handoff, and the per-type required fields. An agent can select and invoke it without further exploration; the remaining gap (alert payload shape) is covered by the sibling poll_alerts.

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 the baseline is 3, but the description earns more by stating conditional requirements the schema cannot express: url/rss/x402 need url, price needs coin plus a threshold, edgar needs ticker or cik. That cross-parameter rule is the single most useful thing an agent needs before building the call, and it is not derivable from the per-field schema text.

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 and resource — 'Keep watching a source between agent runs and alert when it changes' — which clearly frames this as a persistent watch rather than a one-shot check. It never names the sibling check_* tools (check_web_page, check_sec_filings) or watch_* variants to explain when this generic creator is preferred over the typed ones, so differentiation is implied by 'between agent runs' rather than stated.

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 says when to use the tool (persistent monitoring across agent runs) and names the follow-up flow: persist watch_id, then poll_alerts with since=<last cursor>. It also gives concrete free alternatives (demo endpoint, try endpoint / try_watch) for agents without a wallet. What's missing is guidance on when to choose create_watch versus the typed siblings like watch_web_page or watch_crypto_price.

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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is mostly covered. The description adds only a cost note ('Free — no payment required'), but does not explain irreversibility, key requirements, or what 'stop and delete' entails beyond the annotations.

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-loaded with the action, but 'Free. Free — no payment required.' is redundant and wastes space. Every sentence should earn its place, and this repetition does not.

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 rich annotations and full schema documentation, the core information needed to invoke the tool is present. However, the description lacks context about when this tool is appropriate relative to siblings and what happens to the watch after deletion.

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 both required parameters (key, watch_id) are documented in the schema. The description contributes no additional parameter meaning, which is acceptable given the complete 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 states a specific verb ('stop and delete') and resource ('a watch'), making the action clear. It does not explicitly distinguish itself from siblings like create_watch or try_watch, but the verb contrast is sufficient.

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 guidance on when to use this tool versus alternatives such as create_watch or try_watch. The only contextual note is that it is 'Free — no payment required', which addresses cost but not usage conditions.

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?

The description adds substantial context beyond annotations: new paid watches include 7 days of polling, a $0.005 paid poll renews 7 days, polling keeps the watch alive, beta watches remain free, and no API key is required. This is valuable for a non-read-only tool (readOnlyHint=false) with a monetary side effect, although the repeated billing sentences dilute the signal.

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 first sentence is well front-loaded, but the pricing/payment rules are repeated three times with near-identical wording ('New paid watches include 7 days...', 'Free through the watch's included polling window...', 'After that window, one $0.005 paid poll renews...'). Much of the text does not earn 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?

There is no output schema, so the description should explain what comes back; it only says the response carries a new cursor and never describes the alert payload. It does cover the complex payment/liveness model and auth (no API key), but it omits the actual response shape and task-selection guidance.

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%, so the schema already explains watch_id, key, and since. The description restates the since cursor concept and mentions the new cursor in the response, but adds no syntax or format detail beyond the schema baseline.

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 opening sentence, 'What is new since your last run,' implies incremental polling of an existing watch, and the title supplies the missing verb/resource. However, the description itself never explicitly says it polls a watch for new alerts, and it does not distinguish this from siblings 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?

It gives a mechanical instruction to pass since={last seq you saw}, but does not state when to use this tool versus check_now, poll_trial, or the watch_* variants. The only contextual guidance is billing-related, not task-selection 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?

Adds real behavioral context beyond the annotations: cursor advancement via the since parameter, and the trial-expiry handoff to create_watch. However, readOnlyHint=false is unusual for a poll and the description never explains what that mutation is (cursor/state advance) or what happens if you poll an expired trial — presumably an error, but unstated.

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 core instruction and the since/cursor mechanic are front-loaded, which is good. But 'Free. ... Free — no payment required.' is stated twice, wasting a whole clause in an already short description.

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 output schema, the description should characterize the response; it only notes that a new cursor accompanies it, saying nothing about the alert payload shape. The trial-expiry path is covered, but what a caller gets back from a successful poll is not.

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%, so all three parameters are already documented. The description's 'Pass since={last seq you saw}' largely restates the schema's 'highest alert seq already seen; 0 on first poll' and adds no format or edge-case detail beyond 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 specific verb (poll) and a specific resource (a trial watch created by try_watch), tying it directly to the sibling that creates it. An agent can distinguish this from poll_alerts (paid watches) and check_now without opening a schema.

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?

Explains the lifecycle clearly: use this while the trial is active, and once it expires move to create_watch for a paid watch (which bundles 7 days of polling and renewal). It never names poll_alerts explicitly, so the trial-vs-paid polling choice is only implied rather than stated.

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?

The annotations declare destructiveHint=true and openWorldHint=true, so the safety bar is lower, yet the description adds real operational context: 24h lifetime, one concurrent trial per caller, no webhook delivery, and no wallet/payment. It does not explain why the tool is flagged destructive (the schema hints at x402 write methods, not the description), so the disclosure is strong but incomplete.

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 core constraint and the types are front-loaded in the first two sentences, and the trial limits follow logically. The closing "Free — no payment required" restates the opening "no payment, no wallet, no account," making the final sentence partly redundant.

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 14-parameter creation tool with no output schema, the description supplies the key behavioral envelope (trial duration, concurrency, webhook limitation, cost) that an agent needs before calling. It leans on the fully documented schema for parameter details, which is appropriate, though the destructive x402-method risk is only surfaced in the schema.

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% with 14 well-documented parameters, so the schema already carries parameter meaning. The description only repeats the type enum values that the schema lists, adding no syntax, defaults, or per-type requirements beyond that.

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 ("Create a free trial watch") and explicitly enumerates the five watch types it supports, tying it to the create_watch sibling rather than leaving the relationship implicit. An agent can distinguish this from create_watch and from the individual watch_* helpers on the first read.

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 gives a clear directive: "Use this first to see what the alerts look like before paying," which tells the agent when to prefer it over the paid path. It also states the trial constraints (24h, one at a time per caller, no webhooks), but it never explicitly says when to switch to create_watch, leaving that inference to the reader.

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 the description the agent would not know about the 7-day polling window, one-shot alerting with hysteresis re-arming, or the $0.005 x402 payment flow and that an unpaid call returns 402 with requirements. These are exactly the operational facts annotations (readOnlyHint/idempotentHint) do not convey.

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 purpose and payment sentences are front-loaded and efficient, but the trailing 'free alternative' sentence promotes an unrelated NVDA insider-trades sample and a trial endpoint, which does little to help invoke this specific crypto watch tool.

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?

Covers the trigger semantics, poll duration, and payment/error behavior needed to call it correctly with 6 params and no output schema. It stops short of describing what a successful watch returns (an id? a confirmation?) or how hysteresis thresholds behave numerically.

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 every parameter including the nested webhook object and idempotency_key is already documented in the schema; baseline 3 applies. The description adds only the conceptual 'hysteresis' notion, which maps to no named parameter.

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 concrete verb+resource ('Monitor a crypto price') with scope detail: runs between agent turns, alerts once on threshold cross, re-arms via hysteresis. This distinguishes it from the check_* siblings by its async/alerting nature, though it never explicitly names check_crypto_price or the generic create_watch as the alternatives.

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?

'Monitor a crypto price between agent runs and alert once when it crosses a threshold' gives a clear usage context (background monitoring vs one-shot checks) and the payment/free-trial notes tell the agent how to get a free look. No explicit when-not guidance or named alternative among sibling tools.

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?

Adds substantial operational context beyond the annotations: x402 USDC cost on Base, no API key or account required, 402 payment-required behavior, and the 7-day polling window. These details are not covered by the existing safety annotations.

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?

Front-loads the core purpose and polling window, then covers payment and free alternatives efficiently. It is slightly dense with x402 and URL details, but each sentence contributes relevant operational information.

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?

Covers payment flow and watch duration well, but for a monitoring tool with no output schema it does not explain the success return shape or how the agent retrieves/watch alerts after creation. The 402 behavior is described, but the normal successful result remains unspecified.

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%, so the schema already documents cik, ticker, webhook, and idempotency_key. The description adds no parameter-level meaning beyond that, making the baseline 3 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?

States a specific action and resource: monitor a company for new Form 4 insider buys, sells, grants, and tax withholding. The phrase 'between agent runs' and 'includes 7 days of polling' distinguishes this ongoing watch from one-off sibling tools like check_insider_trades.

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?

Explains the appropriate context clearly: ongoing monitoring between agent runs with 7 days of polling. It also provides free sample/trial alternatives, but does not explicitly route agents between this tool and sibling checks such as check_insider_trades or watch_sec_filings.

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?

Goes well beyond the annotations: discloses pricing ($0.005 USDC via x402 on Base), that no API key or account is needed, that an unpaid call returns 402 with payment requirements, and the 7-day polling retention window. These are exactly the operational facts an agent needs that annotations (readOnlyHint=false, openWorldHint=true) cannot convey.

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?

Purpose and delivery semantics are front-loaded in the first sentence, and the payment/error behavior follows logically. The trailing 'Free alternative' sentence carries two raw URLs and reads partly as promotion, which is useful but slightly bloats an otherwise tight definition.

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 output schema and a nested webhook object, the description should say what the call returns (e.g. a watch identifier) and how new items are later retrieved via poll_alerts. It covers cost and lifetime well but leaves the post-creation workflow and the webhook-vs-polling relationship unexplained.

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%, so url, webhook, and idempotency_key are already documented in structured fields; baseline 3 applies. The description adds nothing parameter-level — it never mentions the optional webhook push or the idempotency key's retry semantics, so it neither reinforces nor compensates.

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 ('Monitor an RSS or Atom feed') plus the behavioral distinction that matters most: it runs 'between agent runs' and fires 'once per new item', which implicitly separates it from the one-shot check_rss_feed. However, it never names that sibling or create_watch/try_watch, leaving the agent to infer the boundary from the word 'monitor'.

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 paid/free distinction is spelled out (free demo GET and free 24h try POST endpoints), which is genuine routing guidance for a paid tool. But there is no guidance on when to pick this over the sibling tools check_rss_feed, create_watch, or try_watch, so the core when-to-use decision is left implied by the title 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?

Goes well beyond the annotations: discloses the exact price ($0.005 USDC via x402 on Base), the no-API-key/no-account auth model, the failure mode ('calling without payment returns 402 with the payment requirements'), and the 7-day polling window. These are precisely the operational facts — cost, auth, error behavior — that readOnlyHint/idempotentHint flags cannot convey.

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?

Purpose and polling window are front-loaded, and the pricing/payment sentence earns its place by preventing a failed-call surprise. The free-alternative sentence is longer than needed and slightly dilutes the core call guidance, keeping it from a 5.

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 5-parameter mutating watch tool with no output schema, the description covers cost, persistence window, auth, and the unpaid-request failure path. It omits how results are later retrieved (the poll_alerts path) and what the webhook push payload/signature looks like, which an agent creating a watch would want to know.

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%, so cik/ticker, forms, webhook, and idempotency_key are already documented in structured data. The description adds no parameter-level meaning (no note on ticker-vs-cik precedence or form filter defaults), so the baseline 3 applies.

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 ('Monitor a company ... for new SEC filings, decoded 8-K events, and parsed Form 4 trades') plus the distinguishing trait of persistence 'between agent runs' with 7 days of polling. That implicitly separates it from the one-shot check_sec_filings sibling, but it never names that sibling, so the differentiation is inferred rather than stated.

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 clear usage context ('between agent runs' = persistent watch) and points to concrete free alternatives (the /demo sample and the 24h /try watch) when payment is a barrier. It does not explicitly say when to prefer check_sec_filings or create_watch instead, so the sibling routing is left to inference.

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?

Adds substantial context beyond annotations: 7-day polling window, what an alert contains (added and removed text), the $0.005 USDC x402 payment requirement on Base, and the exact 402-with-requirements failure mode when unpaid. Annotations only cover safety/openWorld traits, so this payment/auth and lifecycle detail is genuinely additive.

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?

Front-loads the core behavior and cost, and every sentence carries information. The free-alternative URLs are useful but slightly promotional and could be trimmed for tightness.

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 output schema, the description still explains what alerts contain and the polling lifetime and payment path, which is what an agent needs to commit. It stops short of saying how alerts are retrieved (poll_alerts) or how the webhook interacts with polling as the primary delivery 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 100%, so the schema already documents url, webhook, and idempotency_key; the description adds nothing parameter-specific (no mention of webhook push vs polling tradeoff beyond what the schema says). Baseline 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?

States a specific verb and resource ('Monitor a public web page') plus the key differentiator versus check_web_page/check_now: persistence 'between agent runs' with added/removed text on change. An agent can tell this apart from one-shot check siblings without opening a schema.

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 'between agent runs' framing clearly implies when to use this over a one-shot check, and it routes free/low-commitment users to /demo and /try. It never explicitly names the alternative siblings (check_web_page, create_watch, try_watch) or states when not to use this, so it's clear context but not full when/when-not 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?

With annotations already declaring destructiveHint=true and openWorldHint=true, the description adds real value: the probe does not attach payment, the watch lasts 7 days, the exact price and payment rail, and that an unpaid call returns a 402 with requirements. The one gap is that it never mentions the destructive potential of POST/PUT/PATCH/DELETE probing or webhook alert delivery — those only live in 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 core behavior is front-loaded in the first two sentences, and pricing/auth follow logically. The closing free-alternative sentence is useful routing but crams two full URLs plus a sample description into one breath, making the tail heavier than it needs to be.

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 8-parameter, nested-object tool with no output schema, the description covers the essentials an agent needs to decide and call: what is monitored, duration, cost, payment mechanics, and unpaid-call behavior. It leaves alert delivery, cancellation, and the danger of mutating methods entirely to the schema and annotations.

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%, so every parameter is already documented, and the baseline is 3. The description's list of watchable attributes (price, network, scheme, recipient) loosely maps to the expected_scheme/expected_network/expected_amount_atomic params, but it adds no format or matching semantics 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 first sentence states a specific verb and resource ('Monitor an x402 endpoint') and enumerates exactly what is tracked: downtime plus changes to payment challenge, price, network, scheme, and recipient. That scope plus '7 days of polling' implicitly separates it from the one-shot check_x402_endpoint sibling, but it never names that sibling explicitly.

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 gives concrete preconditions (no API key or account, $0.005 USDC per call on Base, 402 returned without payment) and routes wallet-less users to free alternatives (/demo and /try) rather than leaving them to guess. It does not say when to prefer this ongoing watch over the one-off check_x402_endpoint or check_now, so the sibling routing is only partial.

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