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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is covered structurally. The description adds genuine context beyond that: no credentials/account key are required, and the tool is limited to capability facts and docs rather than any notification or transfer action.

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 dense sentences with little padding, but the ordering is inverted for an agent: the product-scope sentence ('confirmed transfer notifications via webhook or Telegram') leads while the actual tool action ('Return official capability facts and documentation') is buried at the end of the final sentence.

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, read-only discovery tool with no output schema, the description states what is returned (official capability facts and documentation) and what is out of scope, which is sufficient to invoke it. Return format details are omitted, but with no output schema that gap is minor.

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 input parameters, which sets the baseline at 4. The description correctly implies a parameter-free discovery call with 'no account key needed' and adds no misleading parameter-like expectations.

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 final clause 'Return official capability facts and documentation' gives a concrete verb+resource, and the scope list ('no balance thresholds, arbitrary tokens, other chains or funds transfer') implicitly separates it from the watch/event siblings. However, the lead sentence describes the product's notification feature rather than the tool's action, which briefly muddles what the tool returns.

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 negative scope (no balance thresholds, arbitrary tokens, other chains, funds transfer) tells an agent when this tool is not the answer, and 'no account key needed' hints at prerequisites. It never states the positive trigger (e.g. 'call this to discover supported chains/notification methods') nor names an alternative sibling to use instead.

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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: records are 'retained' (retention-limited), deleted-watch history is absent, and the cursor must be passed back unchanged. Note the description says 'next_cursor' while the schema parameter is 'cursor', a minor naming mismatch worth flagging.

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?

Three short sentences, each earning its place: identity, pagination/availability constraint, and scope exclusion. The most important constraint (what this is not) is front-loaded alongside the 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 list tool with annotations covering safety and no output schema, the description adequately covers retention, pagination, and scope. It is incomplete on the filtering surface (limit, since, watch_id) that a caller needs to narrow results, which matters given 0% schema description coverage.

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% for four parameters, so the description carries the full burden, yet it only gestures at cursor semantics and says nothing about limit, since, or watch_id filtering. The 'next_cursor' wording also does not match the schema's 'cursor' field, so an agent gets no reliable mapping between the prose and the parameters.

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 retained TRON delivery records for your account'), which is clearly distinct from the watch-management siblings like list_watches or prepare_create_watch. The closing clause further pins the domain by ruling out balance/funds-transfer use. It stops short of naming a sibling to route against, so it is clear but not fully differentiated.

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?

'Follow next_cursor unchanged' gives an explicit pagination instruction, and 'deleted-watch history is unavailable' sets a boundary on when this data is usable. 'This is reconciliation data, not a balance or funds-transfer tool' excludes a class of misuse. No alternative tool is named for those other needs, so it is context without explicit routing.

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/idempotent/non-destructive, but the description adds real value beyond them: receiver paths, query strings and secrets are redacted from the response, which an agent cannot learn from the annotations or an empty schema. It stops short of explaining result shape or limits.

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?

Three short, efficiently front-loaded sentences; the safety statement is placed last as a boundary rather than leading. Minor redundancy with the readOnly annotation, but 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 no-parameter, no-output-schema read tool this covers purpose, scope and redaction behavior adequately. It does not say what fields are actually returned or whether results are paginated, which is a modest remaining 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?

The tool takes zero parameters, so the schema has nothing to document and the baseline is 4. The description correctly adds no parameter commentary, though the 'local mainnet API key' scoping is the only implicit input context.

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 watches') plus the scope ('your local mainnet API key'), and the closing 'Does not create, delete or send' separates it from the prepare_create_watch / prepare_delete_watch 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?

The exclusions ('Does not create, delete or send') imply this is the read-only path versus the prepare_* siblings, but no sibling is named and no condition for choosing it over list_events or get_capabilities is given. Usage is inferable 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?

Beyond the annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false), the description discloses that the return is a private browser-fragment draft, that no key or secret is embedded in the link, and that no notification is sent and no watch is created. These are material behavioral traits an agent cannot infer from the annotations alone.

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?

Three tight sentences with the critical 'DO NOT EXECUTE' warning front-loaded, followed by what the tool returns and what it does not do. No filler or repetition.

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 usefully characterizes the return value (private browser-fragment draft with no secret) and all non-effects. For a read-only, idempotent tool the safety and outcome picture is complete; only the parameter meanings are under-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 0% across 5 parameters, so the description carries the full explanatory burden, yet it only hints at asset_filter ('USDT/TRX') and address. Keywords like channel (webhook vs telegram), webhook_url, and direction are never explained, leaving most parameters semantically opaque.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb+resource: 'Prepare (DO NOT EXECUTE) a TRON USDT/TRX watch creation' and specifies the artifact returned ('private browser-fragment draft'). This cleanly separates it from execute-style tools and from sibling 'prepare_delete_watch' by naming the exact action and asset scope.

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 clearly frames this as a preparation step whose output the owner reviews and confirms in the official console, and explicitly says it does not create a watch or send a notification. It does not, however, name alternatives such as validate_watch_config or explain when to prefer that tool over this one, so guidance is clear but not exhaustive.

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 behavior beyond the annotations: it states this tool never issues DELETE (explaining why destructiveHint=false is safe), discloses downstream effects of the eventual deletion (notification/attempt history is removed, an in-flight delivery may still complete), and names the precondition (scoped GET, ownership, console confirmation).

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 with the most safety-critical constraint front-loaded in parentheses. Zero filler; each sentence adds a distinct fact (stage, confirmation owner, side effects, non-execution).

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, non-executing staging tool with no output schema, the description covers the essential semantics. It leaves minor gaps: what artifact or handle the 'preparation' yields and whether it expires before the owner confirms.

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 single watch_id parameter has 0% schema description coverage, so the description must carry the load. It implies the ID must reference an *owned* watch fetched via a scoped GET, which is meaningful, but it never names or describes watch_id, its format, or how to obtain 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 (prepare, explicitly DO NOT EXECUTE), a specific resource (an owned watch), and the precondition (after a scoped GET). The parenthetical '(DO NOT EXECUTE)' disambiguates it from any real delete operation in a way an agent can act on immediately.

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?

Clearly positions the tool as the prepare half of a two-step, human-confirmed flow ('Owner confirms in the console'), which tells the agent when to call it. It does not, however, name or contrast against any sibling tool, and no sibling covers deletion, so routing guidance relies on 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?

Annotations already declare readOnlyHint=true, non-destructive and idempotent, but the description adds genuinely new behavioral context: no DNS lookup, no account change, no notification, and that checksum, receiver policy, quota and Telegram binding are only enforced at confirmed creation. This prevents the agent from over-trusting the result. What's missing is any statement of error or failure behavior.

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 dense sentences, front-loaded with the action and its side-effect exclusions, with no filler. The phrasing is slightly elliptical in the second clause but nothing is 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?

With no output schema, the description should say more about what a validation result looks like, and with 0% schema coverage it should cover the three remaining parameters. It does a good job on scope and side effects, but the parameter and return-value gaps leave the agent guessing on invocation details.

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% across five parameters, so the description carries the full burden. It alludes to only two of them obliquely (address shape via 'Address shape is checked', channel via Telegram binding) and says nothing about direction, webhook_url, asset_filter, their enums or defaults.

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 a specific verb+resource ('Validate a TRON USDT/TRX watch draft') and immediately bounds the scope ('without DNS lookup, account change or notification'). It implicitly separates itself from creation-time behavior, though it never names the sibling prepare_create_watch that the agent must choose between.

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 is implied rather than stated: the agent can infer this is a lightweight pre-flight check before confirmed creation, and the 'without ...' clause signals what it deliberately avoids. There is no explicit when-to-use versus prepare_create_watch, nor any stated prerequisites for calling it.

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