Ireland MCP

Query tables on the server

ireland_query

Read-onlyIdempotent

Filter, join, aggregate, rank and sort whole tables on the server; returns only the answer rows, each input's provenance and the query echo. tables: {alias, table_id} (from an ireland_call result) or {alias, source, operation, args}, each with optional own steps (no joins); put source filters (council, dates, codes) in args. No steps: columns, row count and preview per table. Steps run in order: {"filter": ["col", ">", 0]} (= != > >= < <= in not_in contains starts_with is_null not_null; {"and"|"or": [..]}, {"not": ..}); {"join": "alias", "on": "col"|["l","r"], "type": "left", "normalize": true}; {"union": "alias"}; {"derive": {"rate": "a / [Col B] * 1000"}} (round abs min max coalesce if lower norm concat substr split_part replace number year pct_change …); {"aggregate": {"n": "count", "u": "sum:units", "d": "weighted_avg:score:pop"}, "group_by": ["county"]} (count count_distinct sum avg min max median weighted_avg first); {"select": [..]|{"new": "old"}}; {"sort": "-n"}; {"limit": 10}; {"rank": {"by": "n"}}; {"pct_of_total": {"col": "n"}}; {"distinct": [..]}. Limits: 4 tables, 10,000 rows each, 50,000 rows after a join, 20 steps. Partial tables are an error, never computed.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "tables": "<tables>"
    },
    "name": "ireland_query"
  }
}

Input Schema

Name	Required	Description
`from`	No	Start alias (default first).
`limit`	No	Rows out (default 50).
`steps`	No	Steps, in order.
`tables`	Yes
`max_tokens`	No	Token budget (default 3000).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 29, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, but the description adds substantive details: the return payload includes answer rows, provenance, and query echo, and it specifies preview behavior, limits, and that partial tables error out instead of being computed.

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

Conciseness4/5

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

The description is dense but front-loaded with the core purpose and necessary DSL details. Given the complexity, almost every clause carries invocation-critical information, though the compact punctuation makes it less scannable than it could be.

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

Completeness5/5

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

For a complex table-query tool with an output schema, it covers source inputs, step ordering, no-step preview mode, operational limits, and partial-table error behavior. Only explicit sibling routing is thin, which is minor against the structured schema and annotations.

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

Parameters5/5

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

Schema coverage is 80%, and the schema only generically describes steps, so the description carries the real semantic burden by documenting the steps DSL, operators, aggregate functions, derive expressions, table alias structure, args placement, and limits. This adds far more meaning than the schema alone.

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

Purpose5/5

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

States specific verbs (filter, join, aggregate, rank, sort) and the resource (whole tables on the server), plus the return shape. The reference to table_id coming from an ireland_call result helps distinguish this table-query tool from catalog/search siblings.

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

Usage Guidelines3/5

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

Provides workflow context: tables can come from an ireland_call result or from source/operation/args, and running with no steps previews each table. It does not explicitly say when to prefer this over search, nearby, or other siblings, nor when not to use it.

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

All Ireland MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.