Ireland MCP

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 without the description. The description adds only the 'full text' nature of the response and id-format examples, saying nothing about truncation against max_tokens, rate limits, or missing-id 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 action first and the id examples trailing; every element earns its place and there is 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?

With an output schema present, return values need no explanation, and the rich annotations cover safety. The description plus schema cover both parameters, though a brief note on what happens when the id is unknown or when output is truncated would make it fully complete.

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 description exceeds it by supplying four concrete id examples across different sources ('cso:F1001', 'oireachtas:bill/2024/12', 'legislation:2018/7/s2', 'data-gov-ie:moby-bikes'), which makes the '<source>:<key>' pattern tangible in a way the schema alone does not.

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 (fetch) plus resource (full text of a search result) and the keying mechanism (by its id). The phrase 'of a search result' cleanly separates it from the sibling 'search' tool and from metadata-oriented siblings like ireland_describe.

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 makes the usage context clear: this is the follow-up step that retrieves a document identified by a prior search. It does not, however, name when-not to use it or point to alternatives such as ireland_describe, so it stops short of explicit routing 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered elsewhere. The description adds useful context about the returned metadata (licence, attribution, status URL, typed toolset enabling), but discloses no behavioral traits beyond what annotations and the output schema provide.

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 no redundant content, and the key contents are front-loaded. The fragmentary style (no verb) costs a little structure but nothing is 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 zero-parameter metadata endpoint with an output schema present, the description needn't explain return values or field formats. Annotations carry the safety profile and the description names the payload's contents, leaving only usage guidance thin.

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 description to document at the parameter level; baseline 4 applies. The empty schema leaves no ambiguity to compensate for.

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 the tool returns — licence, attribution, status URL, and how to enable typed toolsets — which is specific enough to distinguish it from the sibling action tools (fetch, search, ireland_call). It is not phrased as a verb+resource, but the content is concrete and unambiguous for a metadata endpoint.

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 explicit when-to-use or when-not-to-use guidance, and no alternative is named. The only signal is the implicit 'about/metadata' framing, which the agent must infer from the title rather than the description.

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 one genuinely useful behavioral fact beyond that - invalid args return the expected schema plus an example - but says nothing about auth, rate limits, or per-source failure modes.

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 sentence is front-loaded and the error-behavior note follows logically. The remaining bulk is a dense, unbroken wall of source:operation pairs that is necessary given the enum-free schema but is hard to scan and would be better structured.

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 enumeration plus error-recovery note make the tool callable. For a dispatcher this complex, the one real gap is not telling the agent how to discover the per-operation args it must pass.

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%, but the schema is effectively empty of meaning: source and operation are free-form strings with no enums and args is an untyped object. The description compensates substantially by enumerating every valid source and its operation names, which is the real semantic content. It still does not explain what args each operation accepts.

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

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

States a specific action (run a source operation with args) and enumerates every source/operation pair, so an agent can see exactly what is invokable. It does not, however, distinguish this dispatcher from siblings like ireland_describe or fetch, leaving the routing decision partly to inference.

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 source/operation list tells the agent what can be called, and 'bad args return the expected schema and an example' hints at a discovery-and-retry workflow. There is no explicit when-to-use-this-vs-siblings statement and no pointer to a describe/catalogue tool for learning each operation's args.

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, open-world and non-destructive, so the safety profile is fully covered. The description adds that results are grouped by domain and include operations, which is mild context on the return shape but nothing about result size, pagination, or freshness; with output schema present and annotations carrying safety, a 3 fits.

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, purpose and scope front-loaded, no filler. The trailing 'Start here' earns its place as a routing cue.

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 values need not be explained, and the description covers what is listed and how it is grouped. It could be more complete by pointing to the natural next tools (ireland_describe/ireland_call), but nothing essential for calling 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% and the single 'domain' parameter is fully documented with its enum. The description merely restates the same seven domain values in prose, adding no syntax, semantics, or default behavior beyond what the schema already provides.

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 resource ('sources and their operations'), plus the grouping axis (domain). It implicitly distinguishes itself from siblings via 'Start here', signaling it is the discovery entry point rather than an invocation tool like ireland_call, though it never names a sibling 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?

'Start here' is a genuine, if terse, usage cue telling the agent to reach for this before other Ireland tools. However, it gives no explicit when-not condition, no mention that fetch/ireland_describe/ireland_call are the follow-on steps, and no guidance on when to supply a domain versus listing everything.

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, covering the safety profile. The description adds only that the response contains schema/description/example — which the output schema already carries — and says nothing about auth, rate limits, or caveats.

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 that front-loads what the tool returns. Appropriately sized for a metadata lookup, though its brevity borders on under-specification of the tool's workflow role.

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 simple two-parameter metadata tool with full schema coverage, an output schema, and complete annotations, the definition is adequate but leaves the agent to infer how it fits with ireland_call/ireland_catalogue and when to prefer it.

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 with examples ('cso', 'cso_get_data') in the schema itself. The description adds no syntax, format, or relationship detail beyond the schema, 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 specific verb ('describe') and resource ('one source operation') and enumerates what is returned (argument JSON schema, description, example). It implicitly distinguishes from ireland_call (which invokes an operation) but never names or contrasts siblings 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 when-to-use statement, no prerequisites, and no alternatives named. The agent must infer that this is the inspection step preceding ireland_call or ireland_catalogue.

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 safety is covered. The description adds genuine scope context beyond them: the 500 m radius for monuments, that this is a point-in-Ireland lookup, and which data providers (GeoHive, SMR, NPWS) are consulted. It stops short of noting rate limits, latency, or partial-coverage behavior for points outside Ireland's datasets.

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 operation condition ('For a WGS84 point in Ireland'), with no filler. The first sentence is a dense enumeration that is long but each item earns its place; the second sentence cleanly handles the exclusion and hand-off.

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-format explanation is not required, and the description still supplies everything else an agent needs: coordinate system, country scope, the full set of returned sections, spatial limits, and explicit out-of-scope topics with an alternative. Nothing needed 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 schema already documents lat, lon, hours and max_tokens, making 3 the baseline. The description adds marginal meaning only — the 500 m monument radius and the notion that forecast hours feed the Met Éireann station result — but does not explain the interaction between max_tokens and the breadth of returned sections.

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 (returns what is at a point) and enumerates the exact resources returned: county, local authority, constituency, electoral division, small area, settlement, nearest Met Éireann station/forecast, SMR monuments within 500 m, and NPWS protected sites. It also names the sibling (ireland_call) that covers the excluded data, so an agent can distinguish it without opening another 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 an explicit negative condition — 'Not live observations, river levels, buoys, bikes or populations' — and routes those cases to ireland_call by name. That covers both the when-not and a concrete alternative, which is the strongest form of routing 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 declare readOnly, openWorld, idempotent and non-destructive, so the safety profile is covered. The description adds real value beyond that by disclosing the federated scope and the ID-format return that enables chaining to fetch. No auth/rate-limit detail, but the bar is lower with annotations present.

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 'Search across' and ends with the actionable return-format hint, but the middle is a 13-item source dump that reads as padding. Some entries earn their place by signaling coverage; the sheer enumeration dilutes the key signals.

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 an output schema exists, the description need not explain return values, and it correctly focuses on purpose, source coverage and the fetch handoff. The main gap is sibling differentiation against ireland_catalogue/ireland_describe, but for a two-param search tool this is largely complete.

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%: both 'query' and 'max_tokens' are fully documented in the schema with examples and defaults. The description adds no parameter-level 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?

States a specific verb ('Search') and enumerates the federated resources it queries, so the agent knows it is a broad multi-source search rather than a single-dataset lookup. However, it never explicitly differentiates itself from siblings like ireland_catalogue or ireland_call, leaving that to inference.

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 'Returns ids like cso:F1001 to pass to fetch' clause implies the intended workflow (search then fetch), which is useful routing. But there is no explicit when-to-use/when-not guidance relative to the other lookup tools (catalogue, describe, call).

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