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

Goes well past the annotations by disclosing cost ($0.01 USDC per call, Solana for crates and Base for npm), the settlement rule ('settled only if the answer exists'), local reads of the lockfile, and external service routing. This clarifies the non-idempotent, non-destructive paid-call profile that the annotations only imply.

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 usage trigger, then input forms, routing, exclusions, and pricing in four dense sentences with no filler. Every clause carries decision-relevant 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?

No output schema exists, so the description should ideally sketch the return shape (advisory IDs, severity, remediation); it implies a per-answer result via the settlement rule but never says what comes back. Everything else an agent needs to call it correctly is present.

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 adds real meaning: the accepted lockfile filenames, that lockfile_path is read locally, the 100-package cap for the list form, and that ecosystem is required only with raw text or an explicit package list. It does not explain precedence when multiple input forms are supplied.

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 ('known advisories for pinned dependencies') with its exact scope: lockfiles or up to 100 pinned packages. The sibling tools (scan_repo, get_scan_report, watch_*) cover repo/contract scanning and watchers, so an agent can tell this is the dependency-advisory lookup 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 trigger conditions ('Use before adding or upgrading a dependency, or to triage a lockfile') and exclusions ('Only registry packages are checked; workspace and git dependencies are skipped'). It also routes by ecosystem, telling the agent where each package type is checked.

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 relying on annotations it discloses the cost ($0.05 USDC on Base), the payment rail (x402 from WATCHDOG_EVM_PRIVATE_KEY), and the no-code exemption ('an address with no code is not charged'). It also explains the analysis depth (following owner/controller to one key, a Safe with threshold, or a timelock with delay) and Sourcify verification, which reconciles the non-readOnly annotation with what is otherwise an inspection call.

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 dense sentences, front-loaded with the usage trigger and then the analysis behavior, with pricing last. The long parenthetical list of proxy kinds costs some readability but each entry conveys a distinct detection capability, so it largely earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so by describing the resolution chain (one key, Safe threshold, timelock delay) and Sourcify verification. Payment mechanics and the no-code exemption round out what an agent needs to invoke it correctly.

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 both parameters (chain with enum and default, address format), establishing the baseline of 3. The description adds a little scope context (Base vs Robinhood Chain, free for codeless addresses) but no new syntax or format guidance 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 states a specific verb and resource — detecting proxy kind, resolving live implementation, and following the upgrade controller and owner to the end. It enumerates the proxy standards (EIP-1967, UUPS, beacon, zeppelinos, EIP-1167, diamond, EIP-7702), which makes it unmistakable against siblings like solana_program_authority or get_scan_report.

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 an explicit trigger condition: use before approving a token, depositing into, or signing for a contract on Base or Robinhood Chain. Chain scope also implicitly separates it from the Solana sibling. It does not, however, name an alternative tool or state 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?

Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds two real behavioral facts beyond that: the call is free (cost) and it returns status first, report only 'once done' (non-blocking/polling semantics). It omits auth/accessToken requirements, rate limits, and job lifetime.

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 short sentences with no waste; the cost note and the scan_repo linkage are front-loaded. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and 0% parameter coverage, the description should describe the report payload shape and the meaning of the three required inputs, but it only says 'its JSON report'. For a status-plus-report tool this leaves the agent materially under-informed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and there are three required parameters, so the description carries the full burden — yet it explains none of them. jobId, ecosystem (enum solana/evm), and accessToken are all left undefined in both schema and description, leaving the agent to guess their formats.

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 (returns) and two concrete resources (scan status, JSON report), and ties itself to the sibling that creates the job (scan_repo). An agent can distinguish it from watch_status/watch_create on the basis of the scan_repo linkage alone.

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?

'Started with scan_repo' implies the polling workflow after a scan is kicked off, which is a useful usage cue. However, there is no explicit when-to-use/when-not guidance and no alternative named (e.g. versus watch_status), so the routing signal is only inferred.

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: a concrete cost of $0.50 USDC and accepted payment rails (Solana or Base), the async contract (waits up to wait_seconds, otherwise returns jobId and accessToken), and an explicit scope disclaimer ('A scan, not an audit'). Annotations only cover readOnly/openWorld/idempotent hints, so this pricing and async-flow disclosure 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 trigger condition, then scope, then ecosystem mapping, then cost, then async behavior, closing with the scope disclaimer. Every sentence carries distinct operational information; there is no filler or restatement of the name.

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, but the description covers the two possible return shapes (inline report when the wait succeeds, jobId+accessToken otherwise) and points to get_scan_report for retrieval. With required params, enum meaning, cost, and async semantics all addressed, an agent has everything needed to invoke it correctly.

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 only 33%, yet the description compensates: it maps the bare enum values to real meaning ('solana' for Rust/Anchor programs, 'evm' for Solidity with Foundry/Hardhat) and explains wait_seconds' behavioral consequence (report returned inline vs jobId/accessToken fallback). The repo parameter's public-repo constraint is also stated in prose, not just 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?

States a specific verb+resource (scans a public GitHub repo) and enumerates exactly what it produces: pinned-dependency advisories split by on-chain vs tooling, build hygiene, and file:line code leads for bug classes. This is clearly distinguishable from narrower siblings like dependency_advisories, and the closing line 'A scan, not an audit' bounds the deliverable.

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 it ('before a release or an integration') and names get_scan_report as the continuation path when the wait window expires. It does not explicitly state when to avoid it in favor of siblings such as dependency_advisories or the watch_* tools, so it stops short of full when/when-not coverage.

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 (readOnlyHint=false, non-idempotent, openWorld) are unusual for a query tool, but the description explains the cause: it costs $0.05 USDC via x402 from WATCHDOG_SOLANA_PRIVATE_KEY and is not charged when the address holds no program. That payment/side-effect disclosure is exactly the context annotations cannot convey. It does not cover failure modes or latency.

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-loaded with the trigger condition and the core question, then the returned data, then cost mechanics. Dense but every clause carries information; the middle enumeration is long but justified by the variety of authority models.

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 compensates by enumerating the return contents (authority type and multisig threshold/members/time lock, last deploy date, OtterSec verified build, security.txt, severity-ranked flags). An agent knows both when to call it and what it will receive.

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?

Only one parameter (programId) with 100% schema coverage, so the schema fully documents it. Baseline for a single well-described parameter is a 4; the description adds no format detail beyond base58, but none is needed.

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 question it answers ('who can replace its code') and enumerates the exact authority models it resolves (immutable, single key, Squads v4/v3, SPL Governance). This distinguishes it cleanly from siblings like evm_contract_control and get_scan_report.

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 before signing a transaction for, or depositing into, a Solana mainnet program' gives an explicit trigger condition and scope. It does not name an alternative tool or exclusion, but the condition is clear enough for correct selection.

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 only cover the safety profile (not read-only, open-world, non-idempotent); the description adds substantial detail beyond them: 30-day duration, hourly polling cadence, POST delivery to an https webhook, the x-watchdog-signature HMAC scheme, the $0.90 USDC cost with per-chain payment, and the once-only exposure of watchId/secret/accessToken.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence plus a short tail sentence; the value proposition and duration lead, and detail follows. The heavy parenthetical lists are information-packed rather than redundant, though the sentence is long enough to be slightly harder to scan.

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 compensates by naming the returned credentials and stressing they are shown once. Cost, payment chain, cadence and delivery contract are covered; lifecycle questions (renewal after 30 days, how to inspect an existing watch via watch_status) are left implicit.

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 only 20% (just webhook), so the description carries the load and does so well: it maps programId to authority/multisig/upgrade concerns, address+chain to implementation/owner changes, and lockfile_path to advisories. The chain enum value 'robinhood' is never addressed, which is a small gap given the enum exists in 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?

States a specific action and resource: subscribe to change alerts for three concrete target types (Solana program, EVM contract, lockfile), each identified by its parameter. The scope (30 days, hourly checks) and target taxonomy make it immediately distinguishable from sibling scanners like scan_repo or dependency_advisories.

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 for when to reach for it ('something you rely on changes') and maps each parameter combination to a distinct monitoring scenario. It does not, however, name alternatives or exclusions, so the agent isn't told when a one-shot scan tool is preferable to a persistent watch.

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 and openWorldHint=true, and the description is consistent with that, adding real context beyond the structured data: it returns addresses only (not keys), and it exposes caps, budgets, spend, and tool prices. It stops short of explaining pagination or response format, but the added scope detail is substantive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence with 'Free.' front-loaded as the most decision-relevant fact, followed by the returned fields. 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 carries the return-value burden and does so by enumerating the five things it surfaces. It is close to complete; only the exact response shape and any address-truncation behavior are left 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?

The tool takes zero parameters, so there is nothing for the schema to document and no parameter-level detail to add; the baseline of 4 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 (Shows) and resource (the server's payment wallet configuration) and enumerates exactly what is surfaced: wallet addresses, per-call cap, session budget, spend, and per-tool pricing. It is clearly distinguishable from siblings like watch_status or watch_create, though it never explicitly disclaims them.

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 leading 'Free.' signals there is no cost barrier to calling it and implicitly positions it as the tool to check before incurring spend, but there is no explicit when-to-use/when-not-to-use guidance or named alternative.

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 readOnlyHint=false, so the cancellation risk is signaled structurally. The description usefully adds cost ('Free') and durability context (events retained even when the webhook was down), which the annotations cannot convey, but it omits auth requirements and whether cancellation is reversible or permanent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence with the cost note front-loaded and the mode switch highlighted. Efficient, though packing two distinct behaviors into one clause risks being read too quickly.

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, no parameter descriptions, and a destructive cancel mode, the description does far too little: it never says what the returned events look like, how authentication is supplied, or what happens after cancellation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and three required parameters (ecosystem, watchId, accessToken) are completely undocumented in both schema and description. Only the cancel flag gets semantic explanation, which is genuinely additive but leaves most parameters ambiguous.

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+resource pair: listing what a watch has seen, plus a second mode that cancels the watch. The dual list/cancel nature is clear and implicitly differs from the watch_create sibling, though no sibling is named 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?

The description implies usage (call it to inspect a watch's event history; pass cancel:true to cancel), but gives no conditions for when to prefer this over watch_create or watchdog_wallet, and no prerequisites. Implied rather than explicit guidance.

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