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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds the behavioral fact that this returns 'full text' from heterogeneous source namespaces, but says nothing about truncation when max_tokens is hit, rate limits, or other runtime 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 front-loaded sentence with the verb and resource stated first, followed by a compact enumeration of id examples. Every element earns its place; there is no boilerplate or 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?

With an output schema present, return-value explanation is unnecessary, and annotations plus 100% schema coverage handle safety and parameters. The description supplies purpose and id format, leaving only minor gaps (truncation behavior for max_tokens, explicit routing versus 'search').

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 goes beyond the schema's generic '<source>:<key>' by giving four concrete id examples spanning different namespaces ('cso:', 'oireachtas:', 'legislation:', 'data-gov-ie:'), which materially helps the agent construct a valid id.

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?

Names a specific verb ('fetch') and resource ('the full text of a search result') and specifies the selector ('by its id'), so the agent knows this retrieves document content rather than finding documents. It implicitly distinguishes itself from the 'search' sibling by referencing 'a search result', but never names or contrasts that 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?

Usage is implied rather than stated: the phrase 'by its id' plus 'of a search result' signals the id must come from a prior search call. There is no explicit when-to-use, when-not-to-use, or named alternative among the siblings (search, ireland_describe, nearby).

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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered without the description. The description adds only a content inventory, disclosing nothing about the response shape or any side effects beyond what the annotations and output schema carry.

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 fragment with no filler, and the most decision-relevant item (licence, attribution) leads. It loses a point only for being an unanchored phrase rather than a complete sentence, which slightly weakens front-loading of intent.

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 zero parameters and an output schema present, there is little the agent needs beyond knowing this is a static informational endpoint. The description is sufficient for that, though it never explicitly states that no arguments are needed or that the output is documentation-style prose.

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 is no parameter syntax for the description to clarify, and it correctly says nothing about inputs.

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 is a noun phrase listing the payload's contents (licence, attribution, status URL, how to enable typed toolsets) rather than a verb+resource statement of what the tool does. It is distinguishable from siblings like ireland_describe or ireland_catalogue, but an agent must infer that this is a server-metadata/introspection tool from the title alone.

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

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

No explicit when-to-use or when-not-to-use guidance is given, and no sibling alternative is named. The enumerated content does imply the triggering conditions (need licence/attribution/status info or help enabling typed toolsets), which is enough for implied but not stated usage 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), lowering the bar. The description adds one genuine behavioral trait beyond the annotations: bad arguments return the expected schema plus an example, which tells the agent errors are self-documenting. It still says nothing about rate limits, external-service latency, or how operations map to side effects.

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 first two sentences are tight and front-loaded (action + error behavior) before the reference material. The long operation catalogue is heavy but arguably earns its place, since the schema declares zero enums and provides no other enumeration of valid operation values.

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 need no explanation, and the operation catalogue supplies the missing enum-like values for operation/source. The bad-args contract is stated. It is largely complete for a dispatcher, with only cross-tool routing left implicit.

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

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

Schema description coverage is 100%, so the schema already documents source, operation, args, arguments, and max_tokens. The description reinforces the source+operation+args pattern but adds no syntax or format detail beyond what is already structured. Baseline 3 is 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 verb and resource ("Run a source operation with args") and enumerates the valid source/operation pairs, so an agent knows exactly what this dispatcher does. It does not, however, differentiate itself from siblings like fetch, search, or ireland_describe, which are also generic entry points.

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 by the operation catalogue (each operation name signals its purpose), and "Bad args return the expected schema and an example" hints at the calling workflow. But there is no explicit guidance on when to use ireland_call versus fetch, search, or the catalogue/describe tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that results are grouped by domain and include operations, but says nothing about result size, pagination, or freshness — useful but modest added 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?

Two short sentences, zero filler, with the resource and grouping stated first and the call-to-action last. 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?

An output schema exists, so return-value explanation is not required, and the description covers purpose plus entry-point role. The only gap is guidance on what to do with the catalogue once retrieved (i.e., which siblings to call next), which would make it fully self-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?

Schema description coverage is 100% and the single domain parameter has a fully enumerated schema description. The description's domain list mirrors the enum rather than adding new semantics such as interaction with grouping or whether omitting it returns everything, so 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 concrete verb and resource (lists sources and their operations) plus the grouping dimension (domain), so the agent knows exactly what comes back. It does not explicitly distinguish itself from siblings like ireland_about or ireland_describe, but the catalogue framing 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" is an explicit entry-point directive, which is the most important usage signal for a discovery tool. It gives no explicit when-not or named alternative, 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description's only added content is the return payload (schema, description, example), which overlaps with the existing output schema, and it says nothing about auth, rate limits, or failure behavior.

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

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

It is a single short sentence with no waste, but it is an incomplete fragment whose key information (the action) must be inferred, so brevity here shades into under-specification rather than concision.

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 need not be explained, and annotations cover safety, leaving purpose and routing as the description's job — both are underdeveloped for a tool that must be chosen over three other ireland_* siblings.

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 both parameters are documented in-schema with concrete examples ('cso', 'cso_get_data'). The phrase 'one source operation' is consistent with source+operation but adds no syntax or format 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?

The description names the resource (one source operation) and what it yields (argument JSON schema, description, example), so the intent is inferable, but it is a noun-phrase fragment with no verb for the action. It does not distinguish itself from near siblings like ireland_catalogue or ireland_call, which also deal with source operations.

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 statement of when to use this tool versus ireland_call, ireland_catalogue, or ireland_about. The agent must infer that this is the introspection step preceding a call, with no explicit guidance or 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-derivable context: the geographic constraint (Ireland-only, WGS84), the data provenance (GeoHive, SMR, NPWS), the 500 m search radius for monuments, and the warning that results are not live observations. It does not mention caching, freshness windows, or behavior for points outside Ireland, which keeps this at 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?

Two sentences, front-loaded with the result scope, then the exclusion/routing clause. The long enumeration is dense but each item is decision-relevant, so little is wasted; the only minor cost is that it reads as a catalogue rather than a terse directive.

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 formatting need not be described, and the description covers the dataset union, coordinate frame and scope well. The residual gap is what happens for coordinates outside Ireland and whether output is truncated by the token budget — relevant given the max_tokens parameter, though hinted at.

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. The description lifts it by specifying the coordinate reference frame (WGS84) and the Irish coverage area, which the schema's bare lat/lon numbers and bounds do not convey. Forecast hours and token budget are already fully documented in the schema.

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

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

The description enumerates exactly what is returned for a WGS84 point in Ireland: administrative units (county, local authority, constituency, electoral division, small area, settlement via GeoHive), the nearest Met Éireann station and forecast, SMR monuments within 500 m, and NPWS protected sites. An agent can tell precisely what this tool produces without opening the schema, and the sibling ireland_call is explicitly named for other data types.

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 both sides of the routing decision: what is in scope, and an explicit exclusion list ("Not live observations, river levels, buoys, bikes or populations") paired with the alternative to use instead (ireland_call). This is exactly the when/when-not/alternative structure that lets an agent pick the right sibling.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the set of upstream data sources queried (open-world scope made concrete) and the return shape ('ids like cso:F1001'). It does not mention pagination, result limits beyond max_tokens, or empty-result 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?

The handoff sentence ('Returns ids ... to pass to fetch') is well placed at the end and earns its keep. The bulk of the text is a 14-item comma-separated source list that is informative for scope but reads as a run-on enumeration rather than front-loaded, prioritized description.

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 2-parameter federated search tool with an output schema present, the description covers scope, sources, and the id format needed to chain into fetch, which is the key integration detail. Missing pieces are minor: no result-count expectations or behavior when a provider is unavailable.

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 both parameters (query, max_tokens) are documented in the schema with examples and ranges. The description adds no parameter-level meaning beyond the schema – it does not explain query syntax, provider scoping, or how max_tokens interacts with multi-source results. Baseline 3 is appropriate when the schema carries the load.

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 clear verb ('Search') and resource (Irish public data) and enumerates the 14 federated sources, which pins down scope precisely. It also distinguishes itself from the sibling 'fetch' by stating it returns ids 'like cso:F1001' that are then passed to fetch. However, the enumeration substitutes for a description of what the search actually does (keyword matching? full text?), so it is clear but slightly thin on capability.

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

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

The description implies the correct workflow by saying ids are 'to pass to fetch', which is a useful chaining hint. It gives no explicit when-to-use guidance relative to siblings such as ireland_call, ireland_catalogue, or nearby, nor any when-not-to-use or scoping conditions. Usage is therefore implied rather than instructed.

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