ONS + Nomis MCP server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Tools are clearly segmented into ONS and Nomis groups by prefix, and within each group the purposes are distinct: metadata retrieval, dimension listing, data fetching, etc. The only slight overlap is between get_timeseries and get_observations, but they are explicitly documented for different use cases.
Naming Consistency4/5
ONS tools follow a consistent verb_noun pattern (get_, list_, search_), while Nomis tools use a consistent nomis_verb pattern. However, 'nomis_data_url' breaks the verb pattern, and mixed verb initiatives (get vs list) across the server are minor inconsistencies.
Tool Count5/5
18 tools is a reasonable count for covering two distinct APIs (ONS and Nomis) without being overwhelming. Each tool serves a clear purpose, and the number aligns well with the server's scope of data query and exploration.
Completeness4/5
The tool surface covers core operations for both APIs: browse, search, metadata, dimension options, data retrieval, and even a download URL builder. Minor gaps exist, such as lacking a tool to list all Nomis datasets without a search query, but this does not critically hinder functionality.
Average 4.1/5 across 18 of 18 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the output structure (type, title, timeseries_uri) but does not mention behavioral traits like read-only status, error handling, required permissions, or side effects. For a read-like tool, the lack of transparency is a significant gap.
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 concise, with two sentences that front-load the action and purpose. It efficiently explains the main behavior and a key output detail without unnecessary words. Minor downside: lack of parameter descriptions consumes a bit of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (context: true), the description appropriately avoids detailing return values. It covers the core purpose and the most important parameter. However, it omits discussion of pagination (limit/offset) and usage boundaries, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning for topic_id (numeric id from list_topics with an example) and mentions timeseries_uri as a bridge. However, limit and offset parameters are not explained, leaving them to be inferred as pagination defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists content under a topic, specifying content types (bulletins, articles, key time series, dataset pages). It explains the topic_id parameter and the output fields (type, title, timeseries_uri). However, it does not explicitly distinguish itself from sibling tools like get_timeseries or list_topics, missing a clear differentiation.
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?
The description provides some context: topic_id comes from list_topics, and the tool is a bridge to get_timeseries via timeseries_uri. But it lacks explicit guidance on when to use this tool versus alternatives (e.g., searching content by other criteria) and does not state 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool follows the latest_version link internally and provides edition/version details and download formats. However, with no annotations, it lacks information on authentication requirements, error handling, or potential 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the main purpose and add necessary behavioral detail. Every sentence provides value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers the core functionality and output. It misses potential information about error scenarios or prerequisites, but overall it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter dataset_id is not described in the schema or the tool description beyond its name. With 0% schema coverage, the description adds no meaningful semantics about the parameter's format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves metadata and the latest edition/version of a dataset. The mention of following the latest_version link and providing download formats distinguishes it from some siblings like get_metadata, though it does not explicitly differentiate from all.
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?
The description implies the tool is used to obtain concrete edition/version numbers for downstream tools, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It explains that the tool returns name, description, and dimensions with conceptref, and notes that every dataset has geography and time dimensions. However, it does not disclose that the tool is read-only, any required permissions, or potential side effects. The addition that conceptref is used in nomis_get_data is useful but not comprehensive.
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 brief (two paragraphs) and front-loads the purpose in the first sentence. The second paragraph provides examples and a link to another tool. Every sentence adds value, but the structure could be slightly improved by combining the two paragraphs into one or adding more whitespace for readability. No redundancy or tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has only one parameter and an output schema exists (as indicated in context signals), the description is relatively complete. It explains what the tool returns and provides an essential relationship to nomis_get_data. It does not detail the output schema structure, but that is not required since an output schema is available. The description is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one parameter (dataset_id) with zero description coverage. The description compensates by explaining that dataset_id is a Nomis table id like NM_1_1 or NM_2021_1, and that it is used to get the overview. This adds significant meaning beyond the bare schema. However, it does not specify additional constraints like required format (e.g., string length) or list valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves an overview and dimensions of a Nomis dataset, specifying the resource and output. It provides examples of dataset_id (NM_1_1, NM_2021_1) and distinguishes from the sibling nomis_get_data by noting the conceptref link. However, it could be more explicit about being a metadata retrieval tool to differentiate further from get_dataset.
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?
The description implies usage by showing the dataset_id format and connecting to nomis_get_data via conceptref. No explicit guidance on when to use this tool vs. alternatives like get_dataset or list_datasets. The context of siblings suggests differentiation is needed, but the description does not provide exclusions or when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns download hrefs, dimension descriptions, release date, and usage notes, but does not explicitly state that it is read-only or discuss prerequisites, rate limits, or error conditions. Given the absence of annotations, this is moderately transparent but could be more thorough.
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 three sentences, front-loading the core purpose and proceeding to list contents and usage guidance. Every sentence contributes value, and there is no fluff. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has three required parameters and no schema descriptions, the description covers the what but not the how (parameter details) or edge cases (e.g., error handling). An output schema exists but is not shown, so the description's list of return items is helpful but incomplete for full understanding. The context of sibling tools suggests this is a metadata retrieval tool, and the description adequately distinguishes it from per-observation queries but not from other metadata-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters (dataset_id, edition, version) with no descriptions. The description does not elaborate on them beyond implicating a 'dataset version', so it adds minimal meaning beyond the schema property names. With 0% schema description coverage, the agent may need to infer parameter formats or constraints.
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?
The description uses a specific verb ('get') and resource ('full metadata for a dataset version'), listing specific contents like download hrefs and dimension descriptions. It differentiates from sibling tools like get_observations by indicating this is for bulk download.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('when bulk download is more sensible than per-observation queries'), which contrasts with get_observations. However, it does not mention other siblings like get_dataset or get_dimensions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description covers key behavioral traits: returns internal integer codes differing per dataset, supports wildcards, and is a read-only lookup. No mention of rate limits or permissions, but adequate for a search tool.
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?
Two concise paragraphs with clear first sentence. Information is well-organized, but could be more front-loaded with key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description explains return format ({value, name} pairs) and usage context. Covers essential details, though could elaborate on error handling or empty results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description explains 'search' as a place name and implies 'dataset_id' as required, but does not describe 'limit' parameter. Adds partial meaning but not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it resolves place names to Nomis geography codes for a dataset. It specifies the output format and connection to nomis_get_data, but does not explicitly distinguish from sibling tools like nomis_dimension_options.
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 context on when to use (getting geography codes) and mentions wildcard support, but lacks explicit guidance on when not to use or alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Discloses that dimensions can be large and suggests paging with offset/limit. However, does not describe pagination behavior, rate limits, authentication needs, or what happens on empty results. Adequate but could be more detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose concisely, second adds contextual details and paging advice. Front-loaded with critical information, no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, 4 required, and no schema descriptions, the description is incomplete. It explains the paging parameters (offset/limit) but omits explanation of dataset_id, edition, version, dimension. Leaves significant gaps for an agent to use correctly without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description only hints at limit/offset parameters for paging. Does not explain the required parameters (dataset_id, edition, version, dimension) or their semantics. The advice to page is helpful but insufficient to compensate for lack of parameter documentation.
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?
Clearly states verb 'List' and resource 'valid option codes for one dimension of a dataset version'. Distinguishes from siblings like get_dimensions (lists dimensions) and get_observations (uses option codes). No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context by explaining option codes are used for get_observations, implying when to use. Does not explicitly state when not to use or name alternatives, but the relationship to siblings is clear enough for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It explains the return fields and pagination, but does not mention authentication, rate limits, or that it is a safe read operation. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences convey the tool's purpose and key details without unnecessary words. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema covers return structure, the description is mostly complete. It could mention pagination mechanism details, but overall it's sufficient for a simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains offset for pagination but does not describe limit or defaults, leaving half the parameters insufficiently documented.
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?
Description clearly states 'List available ONS datasets' and mentions pagination, making the action and resource explicit. It distinguishes itself from siblings like search_datasets by being a general listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on using offset for pagination, implying the tool lists all datasets. However, it lacks explicit when-not-to-use or alternatives, though sibling names suggest search functions for specific queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains it returns a URL (read-only) and supports specific formats and dimensions syntax, but lacks details on authentication, rate limits, or whether the URL is temporary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, every sentence adds value with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 covers the main return type (URL) and key behaviors (format, dimensions), but could be more complete about parameter details and URL lifetime.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description partially compensates by mentioning formats for 'fmt', implying 'dataset_id', and explaining 'dimensions' supports time and list syntax, but doesn't fully detail each parameter's meaning or constraints.
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?
The description clearly states the tool builds a Nomis download URL for bulk retrieval, listing supported formats (csv, xls, data.json) and syntax support, distinguishing it from siblings that stream data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives guidance to use this tool for large pulls to avoid streaming, but doesn't explicitly mention when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It explains that every dataset has 'time' and 'geography' dimensions, and that 'number_of_options' indicates code counts. This gives insight into the return structure without needing to guess, though it doesn't address limitations or side effects (which are likely absent).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three sentences, each with a clear purpose: state the main function, provide additional context about dimensions, and guide to a sibling tool. No unnecessary words or redundancy, making it succinct and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential purpose and key outputs (mentioning time, geography, and number_of_options). An output schema exists but is not shown; the description complements it well. It could be slightly richer (e.g., noting that it returns a list), but overall it is sufficient for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three required parameters with zero description coverage. The tool description does not explain these parameters (e.g., what dataset_id, edition, version represent or their expected formats). Given the low schema coverage, the description fails to compensate, providing no semantic help for parameter usage.
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?
The description explicitly states 'List the dimensions (variables) of a dataset version', which clearly defines the action and resource. It distinguishes from siblings by mentioning get_options as a follow-up, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides good context on when to use the tool (to explore dataset dimensions) and what to do next (use get_options). However, it lacks explicit guidance on when not to use it or alternatives among the many sibling tools, so it doesn't fully satisfy this dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source for behavioral information. It lists what the tool returns (release date, confirmed status, cancellation notice, contact, links) but does not explicitly state that the operation is read-only or if there are any side effects. The tone implies a safe read operation, but the lack of explicit disclosure on safety or destructive potential limits transparency.
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 front-loaded with the core purpose in the first sentence and provides necessary details in the following sentences. It is slightly verbose but information-dense. Every sentence adds value, so the length is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description enumerates key return fields (release date, confirmed status, cancellation notice, contact, links), making it easy for the agent to understand what the tool provides. Given the tool's simplicity (one parameter), the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only specifies `uri` as a required string with no description or example. The description compensates by explaining that `uri` is the release path and gives an example ('/releases/consumerpriceinflationjuly2026'), adding significant meaning beyond the schema.
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?
The description starts with 'Full detail for one release-calendar entry by its `uri`', specifying the verb 'get' and the resource 'release-calendar entry'. It clearly distinguishes from sibling tool `list_releases` by emphasizing it returns a single detailed entry rather than a list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the `uri` parameter is obtained from `list_releases`, providing context for when to use this tool. It implicitly tells when to use (after listing) but does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the burden. It discloses that the tool returns observations plus the unit of measure, and explains the wildcard behavior. It does not mention any destructive actions, which is appropriate for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with only three sentences, each serving a clear purpose: stating what the tool does, explaining usage of dimensions, and noting return value. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return values are covered. The description adequately explains the main behavior and the critical dimensions parameter. With 4 required params and no annotations, it is fairly complete but could briefly mention the other parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must add meaning. It explains the dimensions parameter thoroughly (exactly one code per dimension, wildcard allowed). However, dataset_id, edition, and version are not described beyond their names, leaving some ambiguity for new users.
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?
The description clearly states the tool retrieves observations for a dataset version, with specific verb 'Retrieve' and resource 'observation(s) for a dataset version'. It distinguishes from siblings by focusing on the observation retrieval and wildcard usage, which is unique among the listed siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on how to use the dimensions parameter, including the wildcard '*' for fetching entire time series. It implies when to use (retrieving observations) but does not explicitly state when not to use or compare to alternatives like get_timeseries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the tool lists codes and describes the search parameter, but does not explicitly state it is a read operation, mention error handling, or discuss rate limits. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with only a few sentences, uses backticks for parameter names, and presents key information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 detail return format, but it already mentions value and human name. It covers main purpose, parameters, and an alternative tool. Could mention pagination or limit behavior, but overall very informative for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the 'dimension' parameter as the conceptref from nomis_get_dataset with examples, and the 'search' parameter as an optional substring filter. However, it does not explain 'dataset_id' or 'limit' (limit is self-explanatory but not described). Adds value for two out of four parameters.
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?
The description clearly states the tool lists valid codes for one dimension of a Nomis dataset, specifying it returns a value and human name. It distinguishes from the sibling tool nomis_geography_search for geography use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool (listing valid codes for a dimension) and provides an alternative (nomis_geography_search for geography). It also notes the search parameter is useful for large codelists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the beta API limitation, client-side paging, and case-insensitive substring matching, providing essential 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three front-loaded sentences, each adding value: purpose, limitation, and usage example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema covers return values, the description omits the 'limit' parameter; given the simplicity of the tool, this is a minor gap but still leaves the tool's full interface undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description only explains the 'query' parameter; the 'limit' parameter is not mentioned, leaving its purpose unclear.
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?
The description clearly states the tool finds datasets matching a query by title, description, or keywords, and distinguishes it from siblings by mentioning the client-side limitation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case ('turning a topic into a dataset id') and explains the client-side filtering caveat, but does not explicitly mention when not to use or alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully covers behavioral traits: read-only search, case-insensitive substring matching, returns dataset details and dimensions with conceptref, and mentions catalogue-wide scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: first sentence states purpose, then explains matching, return format, and context. No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes input (query) and output (dataset id, name, description, dimensions with conceptref) adequately, and provides coverage context. Missing explanation of limit, but output schema likely covers return details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description explains the `query` parameter (case-insensitive substring) but does not mention the `limit` parameter or its default, despite 0% schema description coverage requiring compensation.
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?
Clearly states the tool searches Nomis datasets by keyword, specifies matching across id, name, and description, and distinguishes from siblings by targeting Nomis coverage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use (searching Nomis datasets) and contrasts with ONS beta API, but lacks explicit alternatives or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the read-only navigation behavior, including how to drill down and what information each item provides (has_subtopics, has_content). No destructive or mutating behavior is implied, and it is transparent about the hierarchy traversal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with efficient wording. It front-loads the core purpose and follows with actionable examples. Every sentence adds value without redundancy.
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?
Given the parameter count (1) and the existence of an output schema, the description is complete. It covers top-level browsing, drill-down, and navigation cues (has_subtopics, has_content) with a pointer to a related tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (parent_id) with 0% description coverage. The description adds meaning by explaining that passing a numeric topic id (e.g., '1245' for Economy) lists its subtopics, and that null gets top-level topics. This is valuable beyond the raw schema.
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?
The description clearly states the tool browses the ONS topic hierarchy, a taxonomy over the whole catalogue. It distinguishes from sibling tools (like list_datasets) by focusing on topics and provides examples of top-level topics (Economy, Employment, etc.) and drill-down behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to call with no argument for top-level topics and when to pass parent_id to list subtopics. It also mentions the has_subtopics and has_content flags and hints at using get_topic_content. While it doesn't explicitly exclude other uses, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully covers behavior: hits /v1/data, returns chronological order (last element latest), and warns that next_release is a snapshot from last publication, not live. Describes data source and limitations.
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?
Well-structured with front-loaded main action, examples, and caveats. Slightly long but every sentence adds value. Concise for the amount of crucial context provided.
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?
Given output schema exists (not shown but present), description doesn't need return format. Covers use case, usage context, parameter semantics, caveats, and alternatives. Complete for a single-param tool with good annotations (or lack thereof).
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?
Only one parameter 'uri' with 0% schema coverage, but description explains what the URI is, provides examples like '/economy/.../l55o/mm23', and tells how to find them via CDID and dataset. Adds significant meaning beyond raw schema.
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?
Explicitly states 'Get a PUBLISHED ONS time series by its website URI' and specifies it's for headline indicators like inflation rates, unemployment rate, GDP growth. Distinguishes from get_observations by highlighting dataset curation differences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'PREFER THIS for headline indicators' and advises when to avoid alternatives, e.g., 'Prefer this over get_observations for latest X rate'. Also provides caveat about next_release and suggests using list_releases/get_release for live release dates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It thoroughly explains the behavior of status filtering, query filtering, and default sort. It describes each return field (uri, title, summary, release_date, status) and notes that provisional dates may move and get_release shows finalization. No contradictions.
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 well-structured and concise, front-loading purpose and usage guidance. Every sentence adds value. Minor suggestion: could be slightly more compact, but it is already efficient and covers all necessary details.
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?
Given the tool has 5 optional parameters, no enums in schema, and an output schema, the description is complete. It covers purpose, parameter behavior, return values, and important caveats (provisional dates may move). The presence of an output schema reduces the need to explain return format, but the description still provides useful context.
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 description coverage is 0%, so the description must fully compensate. It explains each parameter: `status` with valid values ('upcoming', 'published', 'cancelled'), `query` for title/summary filtering, `sort` with allowed overrides, and implicit pagination via `limit` and `offset`. This adds significant meaning beyond the bare schema.
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?
The description clearly states the tool browses the ONS release calendar, the authoritative schedule of statistical publications. It explicitly distinguishes from using the `next_release` field on get_timeseries/get_dataset, which is a key differentiator from sibling tools. The verb 'browse' and resource 'release calendar' are specific and precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool: 'USE THIS to answer "when is the next X released"'. It provides a clear alternative not to use (the `next_release` field) and explains why it might be wrong. It also explains context-dependent default sorting behavior based on status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses behavior: returns flat records with named dimension values, numeric obs_value, and record count. It explains the dimensions mapping format and that measures is usually required. No hidden or contradictory information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one sentence for purpose, a focused block explaining the key parameter, and a final sentence on return format and prerequisite tools. No fluff, front-loaded with essential information.
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?
With an output schema present, the description does not need to detail return values, but it still mentions the flat records, dimension values, and obs_value. It also provides essential context on prerequisite tools, making it complete for a data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description thoroughly explains the `dimensions` parameter with a full example and syntax rules. The `dataset_id` is self-explanatory. However, the `select` parameter is not described, leaving a gap despite overall strong compensation.
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?
The description clearly states the tool retrieves observations from a Nomis dataset (simple JSON). It specifies the resource (observations) and action (retrieve), distinguishing it from siblings like nomis_get_dataset which retrieves dataset structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use nomis_get_dataset and nomis_dimension_options / nomis_geography_search first to find correct codes before calling this tool. This provides clear when-to-use and when-not-to-use guidance, effectively differentiating from related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ons-mcp MCP server](https://glama.ai/mcp/servers/brynmrgn/ons-mcp/badges/card.svg)](https://glama.ai/mcp/servers/brynmrgn/ons-mcp)

Score Badge

Copy to your README.md:

[![ons-mcp MCP server](https://glama.ai/mcp/servers/brynmrgn/ons-mcp/badges/score.svg)](https://glama.ai/mcp/servers/brynmrgn/ons-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/brynmrgn/ons-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server