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

Annotations already declare non-read-only, idempotent and non-destructive, so the safety profile is baseline. The description adds real context beyond that: cross-type key rejection, validation/public-address checks and plan quotas matching the dashboard, verify-before-save for Stripe/Supabase, a first test result in the response but never a heartbeat URL, and retry guidance. That is above-average disclosure, but return-shape caveats are partly covered by the output schema, keeping it at a solid 3 (leaning 4).

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 action and the sibling alternative, then a dense per-type map where every clause carries information. It is a single long paragraph, though — a per-type list would parse faster — which keeps 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 6-parameter write tool with nested config, an output schema, and full annotations, the description covers the remaining gaps: per-type conditional requirements, validation and quota behavior, verify-before-save, retry semantics via request_id, and permission needs. Nothing an agent needs to call it correctly is absent.

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 cross-parameter semantics the schema cannot express: 'type decides what target is and which config keys apply', with each type's required config keys enumerated, and 'a key belonging to another type is refused'. That is genuinely additive, though it restates fields the schema already documents individually rather than adding formats or examples.

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 ('Create one monitor in an existing app') and immediately scopes it away from the sibling that handles a different case ('for a new app use provision_app instead'). An agent can pick between create_monitor and provision_app without inspecting 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 an explicit routing rule to the sibling provision_app, plus a precondition ('Needs write access') and the constraint that Stripe/Supabase checks must verify before saving. The only mild gap is no guidance on avoiding duplicates against an existing monitor, which is minor.

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 already state this is a non-read-only, non-destructive, idempotent operation, and the description adds meaningful context: it saves only a draft, returns an approval link, does not publish publicly, and requires write access. The request_id retry guidance further clarifies idempotent behavior beyond the annotation. There is no contradiction with 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 five short, front-loaded sentences with no wasted language. The core action, draft-only behavior, incident id source, retry guidance, and access requirement are all stated efficiently.

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

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

Given the annotations, complete schema coverage, and the presence of an output schema, the description covers what an agent needs in order to call the tool correctly. It explains the draft-only safety property, auth requirement, id source, and retry semantics.

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 schema already documents all four parameters, establishing a baseline of 3. The description adds useful meaning by explaining where the incident id comes from and how request_id supports safe retries, though it does not discuss the optional state parameter beyond what the schema says.

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 uses a specific verb and resource: saving a plain-text incident note as a draft. It clarifies that this does not publish and that the output is an approval link, distinguishing it from any publish action. It also points to get_incidents for the required incident id.

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 prerequisites: obtain the incident id from get_incidents and use request_id for safe retries. It also explains the draft will not appear publicly until a builder publishes it, implicitly defining the boundary against publishing. However, it does not explicitly enumerate alternatives or when-not-to-use cases beyond that boundary.

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, idempotent, non-destructive, so the description correctly spends its words elsewhere: masked snippets, only the latest published note per incident, and the cursor pagination contract. These are real behavioral details an agent cannot get from the annotations or 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?

Four short sentences, front-loaded with purpose, then return contents, then pagination. Every sentence carries distinct information and nothing is repeated from structured fields unnecessarily.

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 purpose, filterability, what the payload contains, the latest-note caveat, pagination termination, and downstream consumption of the ids. With an output schema present, 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?

Schema coverage is 100%, so the baseline is 3; the description earns one extra point by mapping the returned next_cursor to the 'cursor' parameter, a relationship the schema alone only implies. The inline restatement of app/start date/state filters adds little 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?

States a specific verb and resource ('Read incident evidence and timelines'), plus the diagnosis use case and optional filters. It also distinguishes itself from the nearest sibling by noting it returns incident ids for draft_incident_update, which no other sibling does.

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?

'for diagnosis' establishes the primary context and 'Follow next_cursor for older pages' gives a concrete continuation rule. It stops short of naming when to prefer get_uptime or scan_app instead, so there is no explicit alternative 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 cover safety (readOnly, idempotent, non-destructive), yet the description still adds substantive behavior: automatic downsampling tied to window length and the caveat that larger buckets report maxima of percentiles rather than a true percentile of raw requests. That caveat materially changes how an agent should interpret results.

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, zero filler. The primary capability is front-loaded, followed by granularity rules, then the accuracy caveat and pagination instruction in priority order.

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?

An output schema exists, so return-shape explanation is unnecessary, and the description covers the non-obvious pieces: sampling resolution, the meaning of downsampled values, and pagination completion criteria. Nothing an agent needs to call or interpret this tool 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 coverage is 100%, so baseline is 3; the description earns above baseline by explaining that bucket granularity is a function of the chosen window and that location filtering is optional. It does not clarify cursor/limit interaction, which the schema already handles.

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 response-time series for a monitor') with scope modifiers (city/country). The resource is clearly distinct from get_uptime and get_status, but it never names or contrasts with those siblings, so an agent must infer the boundary itself.

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: which windows map to which bucket sizes, and the instruction to follow next_cursor until all points are collected. It stops short of saying when to prefer this over get_uptime/get_status, so there is no explicit alternative 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 establish readOnly/idempotent/non-destructive, so the bar is lower; the description still adds substantive behavior: a null date means Staygreen has no date and 'never guesses one,' plus follow-next_cursor pagination guidance. It stops short of stating result shape or size limits, which keeps it below 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?

Four tight sentences with no filler, front-loaded with what it returns and immediately followed by scoping, alternative routing, and pagination. Each sentence carries distinct, actionable 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?

An output schema exists so return-value detail is unnecessary, and the description covers the remaining agent-critical points: scope semantics, null-date handling, sibling routing, and pagination. Nothing needed to invoke 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?

Schema coverage is 100%, giving a baseline of 3, but the description adds real semantics beyond the schema: omitting app means every SSL monitor in the workspace versus passing an app id for that app's hosts only. The cursor sentence reinforces the paging contract in practical terms.

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 ('Read certificate and domain expiry dates, with days remaining') and scopes it to monitored hosts. It also names the sibling it is not (get_status) so the agent can discriminate 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?

Explicitly gives the selection rule: 'Use this for renewal deadlines; use get_status instead for whether a site is up now.' It also spells out the app-or-not branching, so an agent knows exactly when to omit or pass the app parameter.

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, closed-world, and non-destructive, so the safety profile is largely covered. The description still earns credit for adding non-obvious behavior: private monitors are included in results, draft notes are excluded, and an out-of-workspace app id returns not_found rather than erroring or empty. It stops short of describing result size or pagination, which keeps 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?

Front-loaded with the scope and payload, then usage routing, then the default/error semantics. Four dense sentences with no restatement of the title or name; each one adds new information an agent needs.

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?

An output schema exists, so return values needn't be spelled out, yet the description still tells the agent what categories of data come back and what is deliberately absent (draft notes). Combined with the entry-point guidance and error semantics, nothing required to call this 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?

Schema description coverage is 100%, so the baseline is 3 and the schema already documents the app id format and the '*' const. The description adds semantic weight by explaining that omitting the param is equivalent to passing '*' and by describing the not_found failure mode for foreign ids, which the schema alone does not convey.

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 resource ('Read the current status of one app or every app') and then enumerates exactly what 'status' contains: overall state, monitors (including private ones), status page components, and open incidents with their latest published note. Sibling tools with overlapping domains (get_uptime, get_incidents) are explicitly positioned as history-only, so the boundary is unambiguous.

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

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

'Start here: its app, monitor and incident ids feed the other tools' gives an explicit entry-point rule, and 'Use get_uptime or get_incidents for history' names the alternatives and the condition that selects them. The '*'-vs-omit behavior and the not_found case for out-of-workspace ids close the remaining ambiguity.

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 and destructiveHint=false, so the safety profile is covered. The description does add genuine behavioral context beyond that: the 30d window cap unless the plan includes a year of history, that the result reports the effective window, pagination via next_cursor, and the important caveat that unmeasured time is no data rather than 100% uptime.

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 what is read, then scoping/pagination, then alternatives. Every sentence carries information, though the window cap is stated in both description and schema, a small 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 an output schema present the description need not explain return shape, and it still covers the caveats an agent needs: window capping, cursor following, and the misreading risk of treating missing data as full uptime.

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 interaction semantics the schema does not: monitor=* means every monitor a page at a time while a specific id returns that monitor alone and must not be paired with a cursor. It also explains that window may be silently reduced and the effective value is reported back.

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 plus the exact metrics returned (uptime, downtime minutes, incident counts, daily history). It also names the two siblings that cover adjacent concerns, so an agent can distinguish it from get_response_times and get_incidents without reading 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?

Explicitly routes latency questions to get_response_times and failure-cause questions to get_incidents. It also gives the operational rules for choosing a scope: omit monitor or pass * for all (paginated), pass an id for one monitor and no cursor with 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 declare readOnly/idempotent/non-destructive, but the description adds real value: it discloses that credentials and heartbeat URLs are never returned, explains the three meanings of last_check_precision, and gives the pagination contract (re-call with cursor until next_cursor is null). It does not mention rate limits or page-size interaction, but the safety and paging profile is well covered.

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 resource, ordering and contents, then filters, then return caveats, then sibling routing — a sensible priority order. It is dense with six sentences and the last_check_precision sentence is somewhat compressed, but no sentence is pure 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?

All five optional params are schema-documented, an output schema exists, and annotations cover the safety profile; the description still adds the filter-combination rule, the credential/heartbeat exclusion, pagination loop, and sibling routing. Nothing an agent needs to call this 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?

Schema coverage is 100%, so baseline is 3; the description earns above that by explaining that app/type/status filters intersect rather than union, and that omitting all of them yields every monitor including automatic SSL checks — semantics the schema does not state. It also adds cursor loop behavior, though limit and enum value meanings are left to 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 and resource plus the exact payload shape ('with their app ids, current state and last check, ordered by id'), so an agent knows the return contents and ordering before calling. It also distinguishes itself from get_status and get_uptime by name, so it is unambiguous against 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?

Explicitly routes the agent: use get_status for per-app overall state and open incidents, get_uptime for history. It also explains how filters combine and what the no-filter default returns, removing ambiguity about when this tool is the right choice.

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, the description explains the maximum pause window, automatic resumption, and the idempotency contract for request_id (a repeated request returns the original deadline without extending it). It does not detail what monitoring data or alert behavior is affected while paused, but the core mutation semantics and reversibility are well disclosed.

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 definition is three short sentences, front-loaded with the action and scope, then id sources, idempotency, and permissions. Every sentence adds useful information without 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 an output schema present, the description need not explain return values. It covers the mutation scope, timing limits, idempotency, and write-access requirement. It could say more about what happens to active alerts or monitoring data during the pause, but it is sufficient for correct invocation.

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 meaningful semantics not obvious from the schema alone: exactly one monitor or all monitors of one app, the 1440-minute cap, and the idempotent behavior of request_id when repeated.

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 (pause) and resource (exactly one monitor or every monitor of one app), including the scope and automatic-resume behavior. It clearly distinguishes the tool from adjacent monitoring and listing tools by naming its mutation effect and the id sources.

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 tells the agent where to obtain the required ids ('list_monitors or get_status') and notes the write-access prerequisite. It does not explicitly name when *not* to use it or compare it to other alternatives, 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?

Adds substantial behavior beyond annotations: all-or-nothing transactionality, whole-call refusal on failed pair verification, plan_limit creating nothing, needs write access, and heartbeat URLs being returned only to this request and retries with the same request_id. It doesn't restate the idempotentHint annotation but gives its practical shape via URL normalization.

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 what gets created, then conditional rules, then error/idempotency behavior; nearly every clause carries a distinct fact. It is dense and long for a description, though none of it is clearly wasted.

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 10-parameter, multi-effect write tool with an output schema, the description still covers the failure modes (pair verification failure, plan_limit), idempotency, retry semantics, and skipped reporting. An agent can decide whether and how to call this without further inference.

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

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

Schema coverage is 100%, so baseline is 3; the description still contributes pairing semantics for supabase_url/supabase_key and stripe_key/stripe_endpoints (half-pair reported in skipped, failed full pair refuses), plus name uniqueness and hostname fallback rules that complement 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?

Opens with a specific verb + resource and enumerates exactly what gets created atomically (website check, conditional SSL/domain check, status page, heartbeats per crons_from entry). It also distinguishes itself from the create_monitor sibling by directing users there for added checks.

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 guidance and alternatives: re-provisioning an existing URL returns the existing setup, and additional checks should go through create_monitor. It also states the conditions under which mcp_url and status_domain merely report as skipped.

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: it discloses that optional keys are used once and never stored or returned, that read access is required, that usage is limited per credential and globally, and that MCP server health is 'Coming soon' (a known limitation). These are the exact behavioral facts an agent needs before sending secrets, and none are derivable from readOnlyHint/destructiveHint.

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 the 'no monitor is created' boundary are front-loaded, and every sentence carries a distinct fact. It is dense — several clauses (limits, key handling, cron source, coming-soon caveat) are packed into one block, which slightly hurts scannability but not information value.

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 an output schema handling return values and 100% schema coverage handling parameters, the description fills the remaining gaps: authorization, rate limiting, secret handling, scope boundaries, and a feature that is not yet available. An agent has enough to decide to call it and to call it safely.

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 already 100%, so the baseline is 3, but the description adds real semantic value: it explains the purpose of the optional Stripe/Supabase keys (health and 30-day delivery failures), the handling contract for those keys, and that 'crons' comes from repository findings supplied by the client. It does not cover the URL constraint (no credentials/query params), which the schema carries.

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 ('Run a one-time silent-failure scan of a public app URL') plus the concrete findings it reports. It explicitly distinguishes itself from the monitoring siblings by declaring 'No monitor is created', separating it from create_monitor and provision_app.

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 'one-time' framing and 'No monitor is created' make clear this is a diagnostic pre-check rather than a monitoring setup step, and the note that cron findings 'may be supplied by the client' tells the agent when to pass them. It stops short of naming specific alternatives (create_monitor, list_monitors) or stating exclusion conditions explicitly.

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