OECD-Search

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, such as get_categories for category lists, query_data for data retrieval, and search_dataflows for dataset searches. However, get_categories and list_categories_detailed overlap significantly in purpose, both retrieving categories with only minor differences in detail level, which could cause confusion in selection.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, such as get_categories, query_data, and search_indicators. This uniformity makes the tool set predictable and easy to navigate, with no deviations in naming conventions.
Tool Count5/5
With 9 tools, the server is well-scoped for OECD data exploration, covering browsing, searching, querying, and metadata retrieval. Each tool serves a clear function, and the count aligns with typical server sizes, avoiding bloat or insufficiency.
Completeness4/5
The tool set provides comprehensive coverage for data discovery and access, including category listing, dataset browsing, searching, and data querying. A minor gap exists in update or management operations, but this is reasonable for a read-only data search server, and agents can work effectively with the available tools.
Average 3.2/5 across 9 of 9 tools scored.
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 Apache 2.0.
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 the full burden of behavioral disclosure. It mentions the search action but doesn't describe key behaviors such as whether the search is case-sensitive, how results are returned (e.g., pagination, format), potential rate limits, or error handling. For a search tool with zero annotation coverage, this is a significant gap in 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 concise and front-loaded, consisting of a single sentence that directly states the tool's purpose with relevant examples. There's no unnecessary verbiage, and it efficiently communicates the core functionality. However, the brevity contributes to gaps in other dimensions like guidelines and transparency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a search function with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover parameter details adequately, omits behavioral traits, and provides minimal usage guidance. This leaves the agent with insufficient context to effectively use the tool, especially compared to more comprehensive descriptions.
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 two parameters ('indicator' and 'category') with 0% schema description coverage, meaning no details are provided in the schema. The description only mentions the 'indicator' parameter ('by keyword') and gives examples, but it doesn't explain the 'category' parameter at all. This fails to compensate for the low coverage, leaving one parameter undocumented and the other only partially clarified.
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's purpose: 'Search for specific economic or social indicators by keyword' with examples like 'inflation', 'unemployment', and 'GDP'. It specifies the verb ('search') and resource ('economic or social indicators'), making the intent unambiguous. However, it doesn't explicitly differentiate this tool from sibling tools like 'search_dataflows' or 'query_data', which might have overlapping functionality.
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 minimal guidance on when to use this tool, only implying usage for keyword-based searches of indicators. It doesn't specify when to choose this over alternatives like 'search_dataflows' or 'query_data', nor does it mention any prerequisites or exclusions. This lack of comparative context leaves the agent with insufficient information to make an informed selection among similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states this is a search operation and describes the return format, but doesn't cover important aspects like whether results are paginated, if there are rate limits, authentication requirements, or error conditions. For a search tool with zero annotation coverage, this leaves significant gaps.
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 perfectly concise - two sentences that directly state the purpose and return format without any unnecessary words. It's front-loaded with the core functionality and efficiently communicates essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 2 parameters, 0% schema description coverage, no annotations, and no output schema, the description is insufficient. It covers the basic purpose and return format but misses parameter details, behavioral context, and differentiation from sibling tools. The agent would struggle to use this tool effectively without additional information.
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 schema has 0% description coverage, so the description must compensate for both parameters. It mentions 'by keyword' which implies the 'query' parameter, but doesn't explain what constitutes a valid query or search syntax. The 'limit' parameter isn't mentioned at all, leaving it completely undocumented. This partial coverage of 2 parameters with 0% schema support is inadequate.
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 verb ('Search for') and resource ('OECD datasets (dataflows)'), and specifies what information is returned ('IDs, names, and descriptions'). However, it doesn't explicitly distinguish this tool from sibling tools like 'list_dataflows' or 'search_indicators', which prevents a perfect score.
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 'list_dataflows' or 'search_indicators'. It mentions keyword-based searching but doesn't clarify if this is the primary search method or if there are specific scenarios where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions optional filtering by category but doesn't describe other behaviors such as pagination (implied by 'limit' parameter), rate limits, authentication needs, or what the output looks like (e.g., list format, fields included). This leaves significant gaps for a tool with parameters.
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 adds a usage hint in the second. Both sentences earn their place by clarifying scope and intent. It avoids redundancy and is appropriately sized for a simple listing tool, though it could be slightly more detailed without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, no output schema, and 2 parameters, the description is incomplete. It covers the basic purpose and hints at usage but misses key details like parameter semantics, behavioral traits (e.g., pagination), and output expectations. For a tool in this context, more information is needed to guide effective use.
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 for undocumented parameters. It only mentions 'category' filtering, ignoring the 'limit' parameter entirely. No details are provided on parameter formats, constraints, or effects, leaving both parameters poorly explained beyond what the bare schema indicates.
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 verb ('List') and resource ('OECD dataflows/datasets'), making the purpose understandable. It distinguishes the tool from siblings like 'search_dataflows' by emphasizing browsing rather than searching, though it doesn't explicitly contrast them. The description avoids tautology by adding context about filtering and topic areas.
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 for browsing datasets by topic area, suggesting it's for exploratory discovery rather than targeted queries. However, it doesn't explicitly state when to use this versus alternatives like 'search_dataflows' or 'get_popular_datasets', nor does it mention prerequisites or exclusions. The guidance is present but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the tool 'Returns comprehensive information' but doesn't disclose behavioral traits like whether it's read-only (implied by 'Get'), potential rate limits, authentication needs, or what 'comprehensive' entails (e.g., format, size). This is inadequate for a tool with no annotation coverage.
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 single, efficient sentence that front-loads the core action ('Get all OECD data categories with example datasets for each category') and adds clarifying context. There's no wasted text, though it could be slightly more structured for readability.
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 no annotations, no output schema, and 0 parameters, the description is minimally adequate. It explains what the tool does but lacks details on return values (e.g., format, structure) and behavioral context. For a tool that presumably returns complex data (17 categories with examples), more completeness would be helpful.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing on the tool's purpose. Baseline for 0 params is 4, as it avoids unnecessary details.
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 verb ('Get') and resource ('OECD data categories'), specifying it returns 'comprehensive information about all 17 categories' with 'example datasets for each category'. This distinguishes it from simpler sibling tools like 'get_categories' by indicating more detailed output. However, it doesn't explicitly contrast with all siblings like 'list_dataflows' or 'search_dataflows'.
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. It doesn't mention when this detailed view is preferable over 'get_categories' (presumably simpler) or other siblings like 'search_dataflows' for filtered results. There's no context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the tool retrieves a 'curated list' but doesn't explain what 'curated' means, whether it's static or dynamic, if there are rate limits, or what the output format looks like. This leaves significant gaps in understanding how the tool behaves.
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 single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it highly 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 the tool has no parameters and no output schema, the description is minimally adequate but incomplete. It explains what the tool does but lacks details on output format, curation criteria, or behavioral traits. For a tool with no annotations, this leaves room for improvement in providing a fuller context.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, but since there are no parameters, this is acceptable. A baseline of 4 is appropriate as the schema fully handles the lack of parameters.
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 verb ('Get') and resource ('curated list of commonly used OECD datasets'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_dataflows' or 'list_dataflows', which might also retrieve datasets, so it falls short of a perfect score.
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 'search_dataflows' or 'list_dataflows'. It mentions 'across all categories' but doesn't clarify if this is for general discovery, popular recommendations, or other contexts, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states it returns metadata and structure, implying a read-only operation, but doesn't disclose other traits like error handling, rate limits, authentication needs, or response format details. This leaves gaps for a tool with no annotation coverage.
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 front-loaded, with two clear sentences that efficiently convey purpose and output without waste. Every sentence adds value, making it 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 the tool's moderate complexity (1 parameter, no output schema, no annotations), the description is adequate but incomplete. It covers purpose and output types but lacks details on behavioral traits and parameter usage, which are needed for full contextual understanding in the absence of structured data.
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 description coverage is 0%, so the description must compensate. It adds meaning by explaining that the parameter 'dataflow_id' refers to 'a specific OECD dataset,' but doesn't provide details on format, examples, or how to obtain valid IDs. This partial compensation meets the baseline for low coverage.
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's purpose with specific verbs ('Get the metadata and structure') and resource ('a specific OECD dataset'), and distinguishes it from siblings by specifying it returns dimensions, attributes, and valid values for querying data. However, it doesn't explicitly differentiate from similar tools like 'list_dataflows' or 'search_dataflows' beyond the structural focus.
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 stating it returns 'valid values for querying data,' suggesting it's preparatory for data querying, but doesn't explicitly say when to use this tool versus alternatives like 'list_dataflows' or 'query_data.' No explicit when-not or alternative guidance is provided.
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 full burden. It implies a read-only operation ('Get') and specifies the data source (OECD) and scope (17 categories covering topics). However, it lacks details on response format, pagination, or potential errors, leaving behavioral gaps.
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 single, efficient sentence that front-loads the purpose ('Get all available OECD data categories') and adds useful context (number and examples of categories). Every word contributes meaning without waste.
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 read tool with 0 parameters and no output schema, the description is adequate but incomplete. It covers the what and scope but omits details like response format or error handling, which could help an agent use it correctly despite the low complexity.
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 0 parameters with 100% schema coverage, so the schema fully documents the lack of inputs. The description adds value by clarifying the resource (OECD data categories) and scope (all available, 17 categories), which isn't in the schema, justifying a score above baseline.
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 verb 'Get' and resource 'OECD data categories', specifying the scope as 'all available' and listing example topics. It distinguishes from siblings like 'list_categories_detailed' by implying a broader, less detailed list, but doesn't explicitly contrast them.
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?
Usage is implied by the description's scope ('all available OECD data categories') and example topics, suggesting it's for browsing categories rather than detailed metadata or data retrieval. However, it doesn't explicitly state when to use this versus alternatives like 'list_categories_detailed' or 'search_dataflows'.
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 provided, the description carries the full burden of behavioral disclosure. It states the tool generates a URL for visual exploration, implying a read-only, non-destructive action, but does not detail aspects like authentication needs, rate limits, or error handling. It adds some context but leaves behavioral traits under-specified.
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 front-loaded and efficiently structured in two sentences: the first states the core action and resource, and the second explains the user benefit. Every sentence earns its place with no wasted words, making it appropriately sized for the tool's complexity.
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's moderate complexity (2 parameters, no output schema, no annotations), the description is partially complete. It clarifies the purpose and usage but lacks details on parameters, return values, or behavioral constraints. Without annotations or output schema, more context on what the generated URL entails would improve completeness.
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 schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions generating a URL for a dataset but does not explain the meaning or usage of 'dataflow_id' and 'filter' parameters. This fails to add meaningful semantics beyond the bare schema, leaving parameters 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 specific action ('Generate an OECD Data Explorer URL') and the resource ('for a dataset'), distinguishing it from sibling tools like get_data_structure or query_data that handle different operations. It explicitly mentions the outcome ('direct link to explore data visually'), making the purpose unambiguous.
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 clear context for when to use this tool ('to provide users with a direct link to explore data visually in their browser'), but it does not explicitly mention when not to use it or name alternatives among the sibling tools. This gives good guidance but lacks explicit exclusions or comparisons.
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 effectively describes key traits: defaults to last 100 observations (max 1000) for context window protection, supports filters and time periods, and warns about large datasets (e.g., 70,000+ observations). This adds valuable context beyond the input schema, though it could mention response formats or error handling.
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 appropriately sized and front-loaded with the core purpose, followed by important usage warnings. Every sentence adds value, such as the default behavior and dataset size warnings, with no redundant information. It could be slightly more structured by separating guidelines into bullet points, but it remains efficient.
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 complexity (5 parameters, no output schema, no annotations), the description is moderately complete. It covers purpose, usage guidelines, and behavioral traits well, but lacks details on parameter semantics and output values. For a data query tool with multiple parameters, this leaves room for improvement in guiding the agent on expected results or error cases.
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 description coverage is 0%, so the description must compensate. It adds meaning by explaining that parameters like 'filter', 'start_period', 'end_period', and 'last_n_observations' are used to control data size, and 'dataflow_id' is implied as the dataset identifier. However, it doesn't detail the syntax or format of these parameters, leaving gaps in understanding how to use them effectively.
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 verb ('query') and resource ('actual statistical data from an OECD dataset'), making the purpose explicit. However, it doesn't explicitly distinguish this tool from sibling tools like 'search_dataflows' or 'get_data_structure', which might also involve data retrieval but with different scopes or formats.
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 clear context on when to use this tool by emphasizing the need to control data size with filters, time periods, or limits, especially for large datasets. It implicitly suggests alternatives by warning about defaults, but it doesn't explicitly name when to use this versus sibling tools like 'search_dataflows' or 'get_popular_datasets'.
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:

[![1777316659351555 MCP server](https://glama.ai/mcp/servers/xiaobenyang-com/1777316659351555/badges/card.svg)](https://glama.ai/mcp/servers/xiaobenyang-com/1777316659351555)

Score Badge

Copy to your README.md:

[![1777316659351555 MCP server](https://glama.ai/mcp/servers/xiaobenyang-com/1777316659351555/badges/score.svg)](https://glama.ai/mcp/servers/xiaobenyang-com/1777316659351555)

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/xiaobenyang-com/1777316659351555'

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