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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact — the call is "Free" (no credit cost) — but says nothing about the response shape or rate limits. That one extra disclosure fits a 3 against the annotation baseline.

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 with the primary purpose front-loaded and zero padding. The fragment "Free." is slightly choppy but still earns its place as a cost signal.

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, the description covers what it returns and when to invoke it. Nothing an agent needs in order to call it correctly is missing.

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 no parameter semantics for the description to carry. Baseline 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 resource and what it returns: the credit balance and remaining free records for the month. It doesn't explicitly name or contrast with any sibling, but the resource is unambiguous and distinct from the funding_*/watchlist_* tools.

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?

"Check it before a large paged search" gives a concrete trigger condition for calling the tool. It doesn't name alternatives or state when not to call it, but the context is clear enough for an agent to act on.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context beyond annotations: the endpoint is free and requires no API key, which affects auth handling before invocation.

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 fragments, front-loaded with what is returned and followed by the cost/auth caveat. Nothing extraneous; every clause carries 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?

For a trivial zero-param read with no output schema, the description covers what is returned at a high level (version and deployed build) and the auth/cost posture. It stops short of describing the response shape, which is the only minor gap given there is no output schema to defer to.

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 per the rubric the baseline is 4. There are no input semantics the description needs to explain, and it correctly does not attempt to.

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 resource (the API's version) and adds scope beyond the name by including the deployed build. Siblings are unrelated resources, so no explicit differentiation is needed, but the description could be clearer that this is a simple read-only status lookup.

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?

"Free, needs no key" gives prerequisite context (no authentication required), which helps an agent decide it can call this cheaply. However there is no when-to-use versus alternatives guidance and no stated exclusions; usage is only implied for a zero-arg informational endpoint.

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 flag openWorldHint and non-read-only; the description supplies the operationally important traits: it is free, capped at 10 delivered reports/hour per account, and the correct response to a 429 is to wait rather than loop. It also carries the writing constraint around secrets.

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 purpose followed by rate-limit behavior and submission discipline. Every sentence carries a distinct instruction; nothing is redundant or padded.

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 side-effecting submit tool with 100% schema coverage and no output schema, the description covers everything an agent must know: what to report, what to include, what to avoid, how to react to throttling, and the need for user consent.

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 semantic content: it tells the agent what belongs in `details` (the exact call, what came back, what was expected, ids like research_id) and forbids secrets/API keys. That goes beyond the schema's terse 'exact call, what came back' note.

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 (report) and enumerates the supported report kinds (bug, wrong/empty field, missing capability, question), scoping the tool to ProspectAPIs. No sibling tool overlaps with this function, so it is trivially distinguishable.

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?

Explicit when-to-use and when-not-to-retry rules: 'Send only when the user agrees', re-run the call to confirm a field is genuinely wrong before reporting, and 'a 429 means wait, do not retry in a loop'. This is about as actionable as usage guidance gets.

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, destructiveHint=false, and openWorldHint, so safety is covered. The description adds genuinely useful behavioral context beyond them: the $0.02 charge on a hit, free-record prioritization, and the free miss. It omits auth requirements or rate limits, keeping it short of a 5.

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

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

Two short sentences with no waste; the core action is front-loaded and the cost caveat follows as supporting detail. Every clause 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 should signal what comes back; 'Read one funding record' plus the 'when found'/'missing id' language adequately conveys the success and miss cases, and the pricing detail covers the main hidden cost. It gives no indication of auth or error conditions beyond the missing id.

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 single 'id' parameter is fully documented in the schema as a uuid sourced from funding_search. The description adds no format or sourcing detail beyond that, 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 ('Read'), resource ('one funding record'), and access path ('by id'), which cleanly separates it from funding_search, the only sibling touching the same resource. An agent can select it without opening the 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?

Usage is only implied: the description conveys that this is the id-based counterpart to searching, and the pricing note hints that callers benefit from free records being consumed first. There is no explicit 'use this after funding_search returns an id' statement or exclusion 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?

Goes well beyond the annotations by disclosing billing behavior ($0.02 per record after 100 free/month, empty result sets are free) and exact pagination semantics (pass `next_cursor` back verbatim; null means exhausted). The annotations already cover read-only/non-destructive safety, so this is pure added value.

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 tight sentences, front-loaded with purpose, then cost, then pagination, then filter advice. Every sentence carries distinct, actionable information with no 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 an 11-parameter, annotation-covered search tool with no output schema, the description covers purpose, cost, pagination, and filtering strategy, which is most of what an agent needs. It stops short of describing returned record fields or an example result shape, the one remaining gap given there is no output 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 coverage is 100%, so the baseline is 3; the description adds real semantic value on top by specifying cursor round-trip behavior and the cost trade-off between filters and `limit`. It does not clarify the semantics of the filter parameters themselves (e.g., `round` values), keeping it from a 5.

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 ("Search funding rounds") plus the covered categories (venture rounds, debt, grants, IPOs) and the default ordering (newest announcement first). An agent can distinguish this from the retrieval-by-id sibling funding_get without opening either 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 concrete operational guidance: it explains pagination via `cursor`/`next_cursor` and advises narrowing with filters before raising `limit`. It does not explicitly name an alternative tool or a when-not condition (e.g., use funding_get for a known round), so it falls short of a 5.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful context beyond annotations: it declares the endpoint is free and requires no API key, and describes the live, dynamic nature of the data. It does not discuss rate limits or error behavior, keeping it from a 5.

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

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

Two sentences with zero filler. The core purpose and inventory of pricing components are front-loaded, followed immediately by the usage cue and access note.

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 parameterless, read-only pricing endpoint with no output schema, the description is complete: it covers the return content (funding pricing, research availability/price, watchlist delivery costs) and authentication requirements. Nothing an agent needs to call it correctly is missing.

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, and schema description coverage is 100%, so the baseline score of 4 applies. The description does not need to explain parameter syntax and appropriately focuses on output content instead.

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

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

The description names the resource ("live price list") and enumerates exactly what it covers: funding records, research, and watchlist deliveries, with pricing detail for each. An agent can immediately distinguish this from sibling tools like funding_get or research_get, which fetch actual records rather than pricing.

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 when-to-use condition: "Use it to quote a cost before a large call." It also states the access model ("Free, needs no key"), which removes any uncertainty about prerequisites. No alternative pricing tool exists among the siblings, so no when-not guidance is needed.

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 read-only/non-destructive/open-world, so the bar is lower; the description still adds real behavioral context: the enumerated status lifecycle (queued, running, completed, failed), the fact that result/error appear only in terminal states, that the call is free, and that visibility is scoped to the caller's own account. That goes meaningfully 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?

A single dense sentence that front-loads the action and resource, then enumerates the returned fields. No filler and no redundancy.

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 naming every returned field (status, input, result, error) and when each is populated. No pagination or auth prerequisites are left ambiguous, so nothing needed to call and interpret it is missing.

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 parameter's description already states it is the research_id from research_submit, so the description largely repeats that. It adds no format or syntax detail beyond the schema, 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 ('Read a research job') and anchors it to the sibling that produces the id ('research_id research_submit returned'). An agent can distinguish this from research_submit and the other getters without opening the 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?

Implies the usage context clearly — call this after research_submit to poll a job — and names that sibling as the source of the id. It stops short of explicit when-not guidance or naming alternatives for listing multiple jobs, so it is clear context rather than full 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 declare non-read-only, non-destructive, open-world, but the description carries the substantive behavioral load: async 20-90s latency, polling cadence, and a full billing model (price from account_balance's research_price_usd, held on submit, charged on completion, refunded on failure, no free records).

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 deliverable, then identifier rules, then async/polling behavior, then cost. Dense but every sentence carries operational information; the cost sentence is long though justified since no annotation covers billing.

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 specifies the return value (research_id immediately, brief later) and the terminal statuses, plus timing and cost. An agent has everything needed to invoke and to follow up 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 100% so the baseline would be 3, but the description adds semantic constraints the schema cannot express: the mutually exclusive identifier set and the person_name/company_name pairing requirement. The `context` parameter's role in enabling the `fit` section is also restated usefully.

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 ('start a cited pre-call research brief on one prospect') and enumerates the brief's contents. It is clearly distinguishable from the sibling research_get, which it explicitly routes to for polling.

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 precise input rules (exactly ONE identifier, or person_name + company_name) and the operational loop: poll research_get every 10-15 seconds until status is completed or failed. The alternative tool and the condition that selects it are both named.

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 only declaring readOnlyHint=false, openWorldHint=true and destructiveHint=false, the description carries real weight: it discloses the HMAC signing scheme and header format, that the secret is shown exactly once, the per-event billing model, that charging occurs only on a 2xx webhook response, and the 20-active limit. This is behavior an agent cannot infer from the structured fields.

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

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

Roughly five short sentences, each carrying distinct information (resource definition, delivery/signing, billing, secret visibility, quota), with the core purpose front-loaded. No filler or repetition of the title.

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 mutating tool with no output schema, it covers delivery mechanism, signing, cost, secret handling and quotas, and it describes the returned secret that the schema cannot convey. What it omits is marginal—authentication expectations and any note on how filters interact with existing alerts—so it is nearly complete but not exhaustive.

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 name, filters and webhook_url are already documented, including the constraint that at least one funding_search filter is required. The description restates the filters-plus-webhook composition but adds no per-parameter syntax or format guidance beyond the schema, 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 description gives a specific verb and resource ('Save a funding-signal alert') and immediately defines the resource composition: funding_search filters plus an https webhook. It names the related sibling funding_search, so an agent can distinguish this from watchlist_list/watchlist_get without opening schemas.

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 supplies operating context (free to create, $0.02 per delivered event, 20-active cap) but never states when to pick this over siblings such as watchlist_test or how to validate a webhook before creating. Usage is implied by the resource definition rather than explicitly directed.

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 usefully discloses that deletion also removes delivery history (a real data-loss scope beyond a bare 'delete') and that the call costs nothing. However, this disclosure conflicts with the destructiveHint=false annotation, which would lead an agent to under-warn the user about irreversible data loss. The description is more truthful than the annotation, but the inconsistency is a behavioral gap an agent should be shielded from.

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

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

One front-loaded sentence stating the action and its destructive scope, plus a terse cost fact ('Free.'). Every word earns its place.

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

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

For a single-parameter delete with no output schema, the essentials (what is deleted, cost) are present, but the description omits whether the deletion is permanent or reversible, what happens on an unknown/already-deleted id, and any auth prerequisites. Adequate but with clear gaps.

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

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

Schema description coverage is 100% and the sole 'id' parameter is fully documented (UUID format/pattern and description) in the schema. The description adds no extra meaning about the id, so the schema carries the full load — baseline 3.

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 (Delete) and resource (a funding-signal alert / watchlist entry) plus the scope of deletion (its delivery history). An agent can distinguish this from watchlist_get or watchlist_list, though it never names a 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?

No guidance on when to use this versus alternatives such as watchlist_get or watchlist_deliveries, and no prerequisites, confirmation expectations, or reversibility notes. Only the bare action is described.

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 the safe read profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description nonetheless adds two non-obvious traits the annotations do not cover: the result is capped at the last 50 deliveries, and the call is free, which matters for a metered API with a sibling account_balance tool.

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

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

One sentence carrying the scope, the 50-record cap, the outcome enumeration, and the cost note, with the scope front-loaded. No filler whatsoever.

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 define the outcome vocabulary (delivered, retry, failed, no_credit) plus the row count. It omits what other fields each delivery carries and whether older deliveries are reachable, but for a simple read-only list tool this is close to sufficient.

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?

With a single required parameter and 100% schema description coverage, the schema already documents the id fully, so the baseline is 3. The description's phrase "one alert" is the only added semantics, and it slightly conflicts with the schema's "watchlist id" wording rather than enriching 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?

The description states a concrete result set (delivery records) scoped to one alert and enumerates the outcome vocabulary, so an agent can tell it apart from watchlist_get or watchlist_test. It never uses an explicit verb, and it calls the target an "alert" while the schema calls the parameter a watchlist id, a small terminology wobble that doesn't obscure the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance and no reference to alternatives such as watchlist_get or watchlist_test, which an agent would plausibly confuse this with. Usage must be inferred from the resource name alone.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds two genuinely useful disclosures beyond them: the secret is never returned, and the call is free (relevant given account_balance and pricing_get siblings). It does not describe error or pause-state edge 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?

A single dense sentence with no filler; the resource is front-loaded and the field list follows. Slightly clipped telegraphic style ('Free.') but every fragment carries 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?

With no output schema, the description usefully enumerates the returned fields and explicitly excludes the secret, which is exactly the kind of disclosure an agent needs. Minor gaps remain around failure modes for invalid or missing ids.

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 there is a single parameter documented as 'The watchlist id.', so the schema carries the load. The description adds nothing about id format or lookup semantics, 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 resource and scope: a single funding-signal alert, with the fields returned enumerated (name, filters, webhook URL, active/paused status). The singular 'One' implicitly separates it from the sibling watchlist_list, though no sibling is named 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?

Usage is only implied by 'One' – the agent can infer this is the single-item lookup versus watchlist_list, but there is no explicit when-to-use statement, no mention of the required id semantics beyond the schema, and no guidance on behavior for a nonexistent or deleted id.

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, so safety is covered. The parenthetical '(without their secrets)' hints the output strips secrets, which is a small useful note, but it's cryptic rather than disclosure. No mention of pagination, ordering, or what fields are returned for a no-arg list.

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 fragments, extremely short and front-loaded by size, but the brevity comes at the cost of meaning. 'Free' is unclear pricing noise.

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?

Zero-param read tool with no output schema. For a list tool the description should say what a list contains and how it relates to watchlist_get, watchlist_deliveries, and watchlist_create. 'Alerts (without their secrets)' is too thin to call the tool 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?

Zero parameters, so baseline 4. Nothing to document and the description introduces no confusion about 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?

The description 'Your funding-signal alerts (without their secrets). Free.' is a fragment, not a stated action. The name watchlist_list implies listing, but the description doesn't say it lists anything. It gestures at 'alerts' but never states the verb+resource, and it doesn't differentiate from watchlist_get.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this versus watchlist_get or the many other siblings. No context, no exclusions.

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=false, destructiveHint=false, and openWorldHint=true. The description adds value beyond them by disclosing that the event is signed and by stating the rate limit ('5 a minute'), which an agent needs to avoid throttling. It could say more about effects on the alert's real state, but it is solid.

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 compact sentence with the action front-loaded and the two most actionable facts (signed sample, rate limit) trailing. Every clause earns its place; nothing is padded.

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 action tool with no output schema, the description covers what it does, when to use it, and its rate limit. It does not describe what the test returns or whether the sample is recorded in deliveries, but no output schema exists to require that.

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 there is a single parameter, so the schema already documents the id fully. The phrase 'the alert's webhook' loosely ties the id to a watchlist/alert, 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?

The description states a specific verb and resource: 'Send a signed sample event to the alert's webhook now.' This clearly distinguishes it from siblings like watchlist_get, watchlist_create, and watchlist_deliveries without needing to open any 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?

It gives clear context for use: 'to build and verify the receiver,' implying it is a setup/verification action rather than a production send. It does not explicitly name alternatives or state when not to use it, but the intended moment is unambiguous.

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