UK Source Intelligence

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

readOnlyHint=true already declares the operation is a safe read, so the description's real contribution is the auth disclosure ('No key required') and the fixed-set nature of the listing. It does not explain what 'check database status' actually reports, so meaningful behavioural gaps remain against a low annotation bar.

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 short sentence with the core listing action front-loaded and no padding. The appended 'and check database status' clause is the one element that costs clarity rather than earning 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 no-parameter, read-only tool this covers the essentials: what is listed and that no key is needed. With no output schema and no annotation detail about return values, the unexplained 'database status' check leaves the agent unsure what the response contains, which is a real gap for this otherwise simple tool.

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 description to cover and the baseline is 4. The description correctly implies a no-argument call ('No key required'), adding 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?

States a specific verb ('List') and a specific resource ('the six public GOV.UK pages on UKSI's fixed monitoring schedule'), which implicitly separates it from the user-scoped sibling list_my_watches. The trailing 'and check database status' muddies the single purpose, and no sibling is named explicitly, so it falls short of 5.

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 via 'No key required', which tells the agent no auth setup is needed, but there is no explicit when-to-use, no when-not-to-use, and no naming of alternatives such as list_my_watches or watch_govuk_page.

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 readOnlyHint=true already declaring the safety profile, the description still adds meaningful context: the auth prerequisite (trial/paid key), the scope boundary that it is not a correctness checker, and the fingerprint-comparison behavior behind previous_fingerprint. It does not cover rate limits or output characteristics, but for a read-only inspection tool this is above the bar.

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 front-loaded sentence listing exactly what is returned, followed by a short boundary clause and the auth prerequisite. Every clause earns its place; there is no padding or restatement 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?

There is no output schema, yet the description enumerates the return payload (title, timestamps, SHA-256 fingerprint, quote-presence result) and states the input constraint (supported Content API pages) and auth requirement. It stops short of describing the response shape for the optional quote test or any failure modes, which is the only notable gap for a 4-parameter call.

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 carries parameter meaning (including the 400-char quote limit and the api_key/Bearer guidance). The description adds only light framing around the quote check and the fingerprint, and does not clarify how previous_fingerprint is compared or what a mismatch means.

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 (Retrieve) and a concrete resource set: the GOV.UK Content API source title, update timestamps, and SHA-256 fingerprint of the current page. The word 'current' implicitly separates it from the history-oriented siblings (page_history, page_changes), but no sibling is named explicitly, so differentiation is inferential rather than stated.

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

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

Gives a clear usage condition ('optionally test whether quoted wording is present') and a real exclusion ('Not a factual or legal correctness checker'), plus the prerequisite that a trial or paid key is required. It never names the alternative tools (watch_govuk_page, page_history) that an agent would choose between, so routing is left partly to inference.

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

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

Annotations only declare readOnlyHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: the call requires a key and consumes daily request quota, and the response includes limits and expiry. Missing only details like pagination or ordering.

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 front-loaded sentence covering scope, return content, auth requirement and quota cost, with no filler. 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 carries the burden of describing returns, and it does so at a high level (limits and expiry). For a read-only list tool with one optional parameter this is nearly complete, with only minor gaps around result format and pagination.

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 api_key parameter already documents the usi_ prefix and the preference for Authorization: Bearer in connection settings. The description adds nothing new about the parameter beyond 'requires key', 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 names a specific verb (List) and resource (GOV.UK pages registered for monitoring) scoped to the caller's trial/paid key, which is enough to distinguish it from watch_govuk_page and remove_govuk_watch. It does not explicitly name a sibling (e.g. fixed_monitored_pages vs. user-specific watches), so it falls short of full sibling differentiation.

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

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

Usage is implied (check what you currently have monitored) and the description states a prerequisite (requires key) and a cost (counts towards daily requests). There is no explicit when-to-use vs. when-not guidance or reference to an alternative tool.

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?

readOnlyHint=true already establishes this is a safe read. The description adds two genuine behavioral facts: a key is needed, and a single-baseline page yields no change report (an empty/error condition). It does not describe output shape, snapshot cadence, or what 'distinct' means, so it adds moderate but not rich context.

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, front-loaded with the operation and scope. 'Requires key.' is terse to the point of being vague, slightly weakening an otherwise efficient structure.

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 only two well-documented parameters, the description supplies the essential semantics (what is compared, which two snapshots, baseline caveat). It omits the monitoring prerequisite for producing those snapshots and any notion of result size, but nothing critical to invoking 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 coverage is 100%, so both url and api_key are already documented, making 3 the baseline. The description's 'Requires key' is weaker than the schema's 'Optional UKSI API key', leaving ambiguous whether the key may come from the Authorization header instead; it adds no further syntax 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 (compare) plus a precise resource scope: text blocks from the last two distinct observed snapshots of a monitored GOV.UK page. That scope implicitly separates it from page_history (all snapshots) and inspect_govuk_page, 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 line 'A baseline alone has no change report' tells the agent a precondition: the page must have at least two snapshots. It does not say when to choose this over page_history or fixed_monitored_pages, so usage is only implied.

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 declare readOnlyHint=true; the description goes further by disclosing the temporal limitation ('snapshots start when monitoring begins') and an auth requirement ('Requires key'). It does not cover return volume, pagination, or rate limits, but the added context 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?

Three tight sentences with the core action front-loaded, followed by eligibility and auth constraints. No filler, though the final 'Requires key' fragment is terse enough to be slightly ambiguous.

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

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

For a read-only tool with a rich 100%-documented schema and annotations covering safety, the description supplies the missing operational context (eligibility, snapshot start, auth). No output schema exists, but the description names what is returned, so little is left unclear.

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 both parameters are already documented, and the baseline is 3. The description adds only marginal meaning: it scopes url to a single page and hints that a key is required, without clarifying the header-vs-parameter choice the schema raises.

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 (read) and resource (fingerprints and timestamps from monitored versions of a GOV.UK page), so the agent knows exactly what comes back. It differentiates implicitly from siblings like page_changes and inspect_govuk_page by scoping to 'monitored versions', but never names an alternative 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?

'Available only for fixed pages or your registered watches' states an eligibility precondition, which is useful, but the description never says when to pick this tool over page_changes or inspect_govuk_page. Usage is implied rather than routed.

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 destructiveHint=true already declaring mutability, the description adds meaningful scope clarification: it will not delete captured historical snapshots, and a key is required. This tells the agent exactly what is and is not destroyed, going beyond the annotation. It does not cover return/confirmation behavior, so not 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?

Three short, front-loaded sentences with no filler; the core action leads. Minor redundancy between 'for your key' and 'Requires key' 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 destructive, single-page remove tool with no output schema and fully documented params, the definition supplies the essential destruction scope and key requirement. Missing only confirmation/error behavior, which is a small gap.

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

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

Schema description coverage is 100%, so both url and api_key are fully documented in the schema; the baseline is 3. The description's 'Requires key' loosely reinforces api_key but slightly conflicts with the schema marking it optional (header alternative), adding 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?

The description states a specific verb+resource ('Remove a page from the monitoring list') and a scope qualifier ('for your key'), clearly positioning it as the inverse of watch_govuk_page. It doesn't explicitly name that sibling, so it stops short of a 5 on differentiation.

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

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

Usage is implied (stop monitoring a page), but there is no explicit when-to-use/when-not guidance or reference to alternatives such as list_my_watches or fixed_monitored_pages. Implied context only, which maps to a 3.

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, so the safe-read nature is covered. The description adds the useful 'no API key required' auth detail, but says nothing about response shape, rate limits, or what happens on an outage, so it adds only modest behavioral context.

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 front-loaded sentence with no filler, stating the action, the resource, and the auth condition economically.

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

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

For a zero-parameter, read-only status probe with no output schema, the description tells the agent everything needed to invoke it. It could say more about what the returned version/availability data looks like, but the call itself is fully specified.

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 the baseline of 4 applies. There is nothing for the description to clarify beyond what the empty schema already conveys.

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 (check) and resource (public availability and version of UK Source Intelligence), which is unambiguous. It does not explicitly contrast itself with any sibling, though the 'service status' name sufficiently separates it from the watch/page-history siblings.

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

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

The phrase 'without an API key' implies this is the unauthenticated, entry-point health check usable before obtaining credentials. However, it never states when to reach for this versus the other siblings, leaving the usage context to inference.

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

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

Annotations only declare readOnlyHint=false; the description carries the real behavioral load by disclosing the quota (10 requests per UTC day), per-network and capacity limits, and critically that the key is shown only once and is a credential to be saved. That is exactly the kind of one-shot, unrecoverable-output warning an agent needs before calling.

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 compact sentences, front-loaded with what is returned, followed by limits and the one-time-display warning. No filler; each sentence carries a constraint or a warning the caller must act on.

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 fully covers what comes back (the key, displayed once), the quotas, the eligibility limits, and the credential handling requirement. An agent has everything needed to invoke this correctly and to warn the user.

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 no parameters, so the schema has nothing to document and the baseline is 4. The description's mention of 'one user-chosen watched GOV.UK page' hints at a downstream choice but does not introduce parameters that do not exist.

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: request an instant 3-day trial API key, with the exact scope (10 requests per UTC day, one watched page). This is clearly distinguishable from siblings like watch_govuk_page or fixed_monitored_pages, which operate on existing keys/watches.

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-not guidance ('Do not request repeated trials', 'One trial per client network address, subject to daily capacity'), which is stronger than most. It stops short of naming an alternative for users who already have a key (e.g., watch_govuk_page), so it is clear context without 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?

Only readOnlyHint=false is annotated, so the description carries most of the burden and does so well: it discloses that registration is quota-limited by tier, that snapshots are not immediate, and that checks run through a shared queue. It omits what happens on rejection (e.g., quota-exceeded error) or whether registration is reversible.

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 terse sentences, front-loaded with verb+resource, followed by the quota, latency, and auth facts in descending order of importance. Nothing is redundant or padding.

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 two-parameter mutation with no output schema and minimal annotations, it covers the operational essentials: quota, asynchronous snapshots, queueing, and auth. The remaining gap is what the call returns (e.g., a watch identifier) and how to verify success via list_my_watches or service_status.

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

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

Schema coverage is 100%, so both parameters are already documented, including the guidance to prefer a Bearer header over api_key. The description's 'Requires key' and 'supported Content API page' merely echo the schema, adding no syntax or format detail beyond it.

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

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

States a specific verb+resource: 'Register a supported GOV.UK Content API page for scheduled monitoring.' This clearly separates it from read-side siblings like list_my_watches, page_changes, and inspect_govuk_page, 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?

Adds quota context ('Trial permits one, paid permits three') and auth ('Requires key'), which help decide whether the call can succeed. However, it never says when to prefer this over inspect_govuk_page or fixed_monitored_pages, nor what to do once the limit is reached.

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