CBS Open Data MCP Server

by Tdh25

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Tools generally target distinct resources, but there is clear overlap between get_dimensions and get_dimension_values (the latter is explicitly discouraged), and between get_observations and query_observations which both fetch observations with different options. Descriptions help clarify, but an agent could still be confused about which to use.
Naming Consistency4/5
Most tools follow a get_* verb_noun pattern (get_catalogs, get_metadata, get_dimensions). Two tools use query_* (query_datasets, query_observations), which is a minor deviation but still consistent in style. Names are readable and predictable.
Tool Count5/5
With 9 tools, the server is well-scoped for a statistical data API. Each tool serves a distinct aspect of data access: catalogs, metadata, dataset search, dimensions, observations, and measures, with no unnecessary bloat.
Completeness4/5
The core workflow is covered: discover catalogs, search datasets, get dataset info, fetch dimensions, observations, and measure codes. Minor gaps include the non-functional get_dimension_values (mitigated by get_dimensions) and no explicit way to download a full dataset in one call, but agents can compose queries to achieve this.
Average 4/5 across 9 of 9 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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?
With no annotations provided, the description must carry full behavioral disclosure. It only states that the tool queries observations and returns a dict, lacking details about auth requirements, rate limits, pagination, or safety. The read-only nature is implied by 'query' but not stated explicitly.
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 a well-structured docstring with Args and Returns sections, each parameter on its own line with a short explanation. It is concise and free of fluff, though the parameter list is inherently lengthy due to 10 parameters.
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?
The description covers all parameters and mentions the return type, which is adequate given the output schema exists. However, it lacks usage context relative to sibling tools, fails to explain what the 'query info' in the return value contains, and provides no behavioral details. The tool is complex (10 optional params), and the description could be more helpful by comparing with get_observations.
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 no descriptions for its 10 parameters (coverage 0%), but the description compensates by listing each parameter with a brief explanation. For example, it clarifies that 'select' refers to OData `$select` and 'filter' to OData `$filter`, adding meaning beyond the bare names and types in the schema.
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 queries observations with advanced OData options, naming a specific verb and resource. However, it does not explicitly distinguish this from the sibling tool get_observations, relying on the word 'advanced' to imply a difference rather than directly comparing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_observations. The description lists OData options but does not explain the intended use case, such as when advanced querying is needed, nor does it mention any exclusions or fallback 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 are provided, so the description carries the full transparency burden. It does explain the return shape ('Count and list of measure codes') and defines what a measure is, but it does not disclose error handling, defaults, or explicitly state that this is a read-only operation beyond the inferred 'fetch' semantics.
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 appropriately sized and well-structured: a one-sentence summary, a clarifying definition, and docstring-style Args/Returns sections. Every sentence adds value without redundancy or unnecessary detail.
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 two-parameter lookup with an output schema, the description covers the core return shape and domain concept. It lacks an example or explicit relationship to sibling tools like get_dimensions, but it is sufficient for an agent to understand the basic operation.
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%, but the description does include an Args section with 'catalog: Catalog identifier' and 'dataset: Dataset identifier.' These are minimal and do not mention optionality or defaults (e.g., catalog defaults to 'CBS'), so they add only marginal 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 opens with 'Fetch measure code definitions for a dataset,' which is a clear verb+resource statement. It further distinguishes this tool from siblings like get_dimensions and get_observations by defining measures as 'columns containing actual measurement values in observations.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus alternatives such as get_dimensions, get_observations, or query_observations. The description only gives a generic 'fetch' purpose and does not mention exclusions or prerequisites, leaving the agent to infer usage from the tool name and sibling list.
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 provided, the description carries the full burden of behavioral disclosure. It transparently explains automatic pagination via @odata.nextLink, the effect of resolve_labels, and the safety limit parameter. It does not cover error handling or potential side effects, but for a read-only fetch operation, this is substantial transparency.
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 well-structured and concise. It leads with a one-sentence summary, then details key behaviors in a short paragraph, followed by a bulleted Args list and Returns line. Every sentence serves a purpose, with no fluff or repetition.
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?
The description covers the main behaviors and all parameters, and an output schema exists, so return structure is not fully explained. However, it lacks important usage context, such as when to use this tool over query_observations, how filters are combined, and potential error conditions. For a tool with six optional parameters and no annotations, this is a notable gap.
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 0% description coverage, so the description must compensate. It successfully does so by providing explicit meaning for all six parameters: catalog/dataset as identifiers, filters as dimension-key/value pairs, paginate toggling all pages vs. one, resolve_labels for code/label switching, and limit as a safety cap. The descriptions are concise and add significant value beyond the raw schema.
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 fetches observations and highlights automatic pagination, which is a specific and useful function. However, it does not explicitly distinguish itself from the sibling tool query_observations, which likely also retrieves observations. Thus it is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like query_observations. It gives usage hints for parameters (e.g., resolve_labels behavior) but does not state the intended context, prerequisites, or exclusions. There is no mention of alternative tools or scenarios where this tool is preferred.
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 must disclose behavioral traits. It does mention the return type and contents (dict with count and list of catalogs), which is helpful. However, it does not explicitly state that the operation is read-only or safe, nor does it mention authentication or rate limits. The verb 'Fetch' implies read-only, but this is not explicit.
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 extremely concise, front-loaded with the action, and includes only the necessary return type information. Every sentence adds value with no redundancy or fluff.
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 simple no-parameter tool with no complexity, the description is complete. It states what the tool fetches (all catalogs) and what the output contains (count and list). The output schema is already described in the description, so no additional detail is needed.
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 tool has zero parameters, and the schema is empty with 100% coverage. The description does not need to explain parameters since there are none. Per rubric, a baseline of 4 is appropriate for zero-parameter tools.
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 'Fetch all available CBS catalogs' with a specific verb and resource. It distinguishes itself from sibling tools like get_metadata or query_datasets by focusing on catalogs specifically, which is not mentioned in any sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or typical workflows where catalogs are a necessary first step. While the purpose is clear, no usage context is given.
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 carries the burden of behavioral disclosure. It states the return type and lists some metadata fields, implying a read-only operation. Still, it does not clarify behavior when the dataset parameter is empty (it has a default), nor does it mention possible errors, permissions, or response structure beyond 'dict[str, Any]'.
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 with a front-loaded main statement, a use-case sentence, and an Args/Returns breakdown. However, the Returns section repeats the output type already visible in the output schema and 'and more' is vague, adding mild redundancy.
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?
For a simple two-parameter metadata tool, the description covers purpose, usage, and parameters. But it omits that both parameters are optional in schema (required: 0), leaving the impression that catalog and dataset are always needed. It also does not mention error conditions or how to obtain valid dataset identifiers, which is relevant given the sibling get_catalogs.
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%, so the description must compensate. It does provide a line for each parameter: catalog as 'Catalog identifier' and dataset as 'Dataset identifier' with an example ('85523NED'). This adds value beyond the bare schema property names, though it remains minimal.
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 and resource: 'Fetch metadata for a single specific dataset.' It clearly scopes the tool to one dataset and indicates the return includes title, description, status, and modification date. This differentiates it from broad query tools like query_datasets and the more general get_metadata.
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 phrase 'Use this to quickly check whether a dataset is relevant' gives clear context for when to apply the tool. However, it does not explicitly mention alternatives or exclusions, such as when to prefer get_metadata or query_datasets.
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 carries the full burden. It discloses the return type and structure ('dict[str, Any]: Table of dimensions and labels per dimension'), which is useful behavioral context beyond the schema. It clearly indicates a read-only operation, though it does not address error handling or the default empty dataset behavior.
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 a compact docstring with a one-line summary, an Args section, and a Returns section. No unnecessary words or repetition; it is well-structured and front-loaded.
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 two-parameter fetch tool with an output schema, the description covers the purpose, parameter roles, and return shape. It lacks explicit usage guidance and edge-case disclosure, but given the tool's simplicity, it is nearly complete.
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?
The schema lacks descriptions for both parameters (0% coverage). The description adds minimal semantics with 'catalog: Catalog identifier' and 'dataset: Dataset identifier,' but does not explain defaults, valid values, or how the parameters affect the returned dimensions. This partially compensates for the schema gap but remains thin.
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 opens with 'Fetch all dimensions for a dataset,' which is a specific verb+resource+scope statement. It clearly distinguishes from siblings like get_dimension_values (which fetches values of a single dimension) and get_metadata (which fetches metadata).
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 when a dataset's list of dimensions is needed, but it does not explicitly state when to prefer this tool over alternatives like get_dimension_values or query_datasets. No alternatives are mentioned, so guidance is only implied rather than explicit.
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 carries the burden and does disclose key behavioral traits: the 404 failure on most CBS datasets, and the fact that it does not resolve codes/labels (unlike get_dimensions). However, it omits other traits like pagination limits beyond the top parameter and does not explicitly state that it is a safe 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 well-organized: a one-sentence purpose, a prominent warning, a clear Args list, and a Returns line. Every section serves a purpose without unnecessary filler.
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 provides enough context for the tool's core function and major caveat (404 on most CBS datasets, prefer get_dimensions). The Returns line describes the output shape. It could be more complete by explaining why one would ever use this over get_dimensions, but given the output schema coverage and clear warning, it is adequate.
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. The Args section lists parameters but adds little beyond the schema: 'select: OData `$select`' is tautological, and 'catalog: Catalog identifier' just restates the name. No examples, defaults, or allowed values are provided.
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?
Opening sentence 'Fetch values for a specific dimension' clearly states the action and target. Distinguishes from sibling get_dimensions by explicitly warning that this endpoint 404s on most CBS datasets and recommending get_dimensions instead.
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 provides when-to-use guidance via the warning and alternative: 'Prefer get_dimensions(), which already resolves all dimension codes and labels via the reliable {dim}Codes endpoints.' This clearly tells the agent when not to use this tool.
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 provided, the description carries full responsibility. It discloses key behavioral traits: the unreliability of $search, the effect of exclude_discontinued, and the return type. It could additionally mention that this is a read-only operation, but the search/query phrasing implies non-destructive behavior.
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 with clear sections: purpose, recommendation, args, and returns. It is somewhat lengthy due to the example and detailed parameter notes, but every sentence adds value. The front-loaded first line immediately communicates what the tool does.
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?
The description is comprehensive for a tool with 10 parameters and an output schema. It explains the purpose, parameter semantics, a critical behavioral caveat (unreliable $search), and return type. It leaves no major gaps for the agent to guess.
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?
The schema has zero descriptions, so the description fully compensates. Every one of the 10 parameters is explained with meaningful context (e.g., 'filter: OData $filter -- use contains() for title search', 'exclude_discontinued: Prepend a default filter'). This goes far beyond restating parameter names.
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's purpose: 'Search datasets with OData filtering, sorting, and pagination.' This uses a specific verb ('search') and resource ('datasets'), and distinguishes it from sibling tools like get_observations or get_metadata, which serve different functions.
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 strong guidance on parameter usage, explicitly recommending to use 'filter' with contains() instead of 'search', and explaining why search is unreliable. It does not explicitly compare against sibling tools, but the context makes it clear this is for querying datasets, which is sufficient for most cases.
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 provided, the description carries the full burden of disclosing behavior. It reveals that this returns the catalog-wide schema, not dataset-specific metadata, and describes the return format as an XML string. This is strong transparency, though it could have hinted at read-only behavior or potential response size, but 'Fetch' already implies reading.
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 and front-loaded, beginning with the core action. The note about usage and the Returns line are each purposeful and add value without redundancy. It wastes no words and is easy to scan.
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 simple, zero-parameter tool, the description is fully complete. It states what the tool does, what it returns (XML string), and how it differs from a sibling. The output schema (dict[str,str]) is vague, but the description clarifies the actual content, so all necessary context is present.
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 tool has zero parameters, and the schema is empty. According to the guidance, 0 parameters merits a baseline of 4. The description adds no parameter-specific detail because none is needed; it focuses on the general behavior and return type.
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's function with an explicit verb and resource: 'Fetch the OData metadata document (EDM schema).' It immediately distinguishes itself from a sibling tool by stating it returns the catalog-wide schema and directing users to get_dataset_info() for dataset-specific metadata.
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 not to use this tool: 'Use get_dataset_info() for metadata of a single dataset.' It also clarifies the scope (catalog-wide schema), ensuring users know exactly when this tool is appropriate.
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:

[![cbs-open-data_mcp MCP server](https://glama.ai/mcp/servers/Tdh25/cbs-open-data_mcp/badges/card.svg)](https://glama.ai/mcp/servers/Tdh25/cbs-open-data_mcp)

Score Badge

Copy to your README.md:

[![cbs-open-data_mcp MCP server](https://glama.ai/mcp/servers/Tdh25/cbs-open-data_mcp/badges/score.svg)](https://glama.ai/mcp/servers/Tdh25/cbs-open-data_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/Tdh25/cbs-open-data_mcp'

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