OECD Stats MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: listing indicators, fetching a single value, analyzing trends, comparing countries, ranking, searching dataflows, describing dimensions, and raw querying. No two tools overlap in function, and the descriptions clearly distinguish their use cases.
Naming Consistency3/5
All tool names share the 'oecd_' prefix and use snake_case, but the second part is inconsistent: some are verb_noun (list_indicators, search_dataflow, describe_flow), some are just nouns (stats, trend), and some are bare verbs (compare, rank). This mixed convention makes the set slightly less predictable despite the common prefix.
Tool Count5/5
The server has 8 tools, which is well within the ideal range. Each tool covers a distinct aspect of OECD data access: discovery, simple queries, trend analysis, cross-country comparison, ranking, broader search, metadata description, and raw querying. No tool feels redundant or excessive.
Completeness5/5
The toolset provides full lifecycle coverage for a read-only statistics server: discover available indicators, fetch specific values, analyze trends, compare countries, rank, search for unlisted data, understand data structure, and perform raw queries. There are no obvious gaps in the domain.
Average 3.8/5 across 8 of 8 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 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?
No annotations are provided, so the description must carry the full transparency burden. It discloses one behavioral detail: 'period... if empty, uses latest values per country.' However, it fails to mention return format, pagination, or any limitations. The default behavior for period is helpful but insufficient overall.
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: one sentence for purpose and one line for parameter hints. It is front-loaded and contains no fluff, making it easy to parse quickly.
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?
The tool has 3 parameters, 2 required, and an output schema. The description covers only two parameters and omits the essential indicator parameter. It also does not mention any caveats or limitations beyond the period default. Given the simplicity of the tool, the description is incomplete.
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 explains the countries parameter format (comma-separated) and the period default behavior, but it does not explain the indicator parameter at all, even though it is required. This is a significant gap.
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 core function: 'Compares the same indicator across multiple countries at once.' This is a specific verb (compare) with a specific resource (same indicator) and scope (multiple countries), which distinguishes it from sibling tools like oecd_trend or oecd_rank.
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 only gives parameter formatting examples and does not mention any exclusions, prerequisites, or alternative 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 must carry the full behavioral burden. It discloses that it calculates and returns trend metrics and explains the default time range behavior (recent 10 years if start/end empty). However, it does not mention limitations, data requirements, or output structure (though the output schema exists).
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 concise sentences that are front-loaded: the first states the tool's core purpose, and the second clarifies date parameters. No filler or 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?
The tool has 4 parameters, an output schema, and no annotations. The description gives the essential purpose, lists returned computations, and explains start/end default behavior. However, it omits guidance on valid indicator values and does not mention that indicator is required. Sibling tools like oecd_list_indicators would provide necessary context, but the description does not reference them.
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 start and end format ('2010', '2024' and default to recent 10 years) but does not explain the indicator parameter (required) or the country parameter (default '한국'). The description adds some value but leaves half the parameters undocumented.
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 analyzes OECD time series and computes specific trend metrics (rate of change, CAGR, high/low, trend direction). This distinguishes it from sibling tools like oecd_stats (raw data) and oecd_rank (rankings).
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. It does not mention sibling tools or exclusion criteria. The only usage info is the start/end format instruction, which relates to parameters, not tool selection.
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, the description bears full behavioral burden. It only explains the 'filters' parameter's list-to-'+' behavior, but does not disclose whether the tool is read-only, how errors are presented, pagination, or any other operational traits expected from a raw query tool.
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: one purpose sentence and one parameter example. It is front-loaded with the core purpose and contains no wasted words, making it easy to scan quickly.
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?
Despite having an output schema, the tool is a 7-parameter raw query with no annotations. The description only documents one parameter and gives minimal usage context, leaving significant gaps for an agent attempting to invoke it correctly.
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 adds meaning only for the 'filters' parameter via an example and list behavior, while the other 6 parameters (agency, flow, start, end, last_n, version) remain entirely undocumented.
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 states a specific verb and resource: '직접 조회한다' (directly queries) '등록되지 않은 OECD 통계' (unregistered OECD statistics). It clearly distinguishes this tool from siblings by framing it as an 'escape hatch' for data not covered by the registered/curated tools.
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 '등록되지 않은 OECD 통계' and '탈출구' (escape hatch) clearly imply use when other tools (like oecd_stats, oecd_trend) do not cover a given statistic. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of full exclusion guidance.
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 burden. It discloses that OECD definitions are included and explains max_codes limiting behavior. However, it does not mention read-only nature or error conditions, leaving gaps in behavioral expectations.
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 four sentences with the core purpose first, followed by context, usage timing, and a parameter hint. Every sentence adds value with no fluff.
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, return details are covered. The description provides purpose, usage timing, and max_codes guidance. It lacks an example but is sufficiently complete for a describe-style tool.
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 max_codes precisely ('차원당 표시할 코드 수(기본 40)') but leaves agency, flow, and version self-explanatory without further meaning. This is adequate but not fully compensating.
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 returns the dimension list and selectable codes for a specific dataflow, using a specific verb ('반환한다') and naming the resource. It also distinguishes itself from siblings by positioning as a precursor to oecd_raw_query, indicating it describes structure rather than retrieving 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 an explicit usage instruction: 'oecd_raw_query의 filters를 조립하기 전에 호출한다' (call before assembling filters). This provides clear contextual timing but does not mention alternatives or when not to use the tool.
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 disclosing behavior. It reveals a key trait: only same-time data are used for comparability. However, it does not mention edge cases (e.g., missing data, tie handling) or the read-only nature, leaving some 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 two concise sentences, front-loaded with the primary action and resource. Every word adds value, and it avoids repetition of the tool name or schema fields.
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 tool's moderate complexity and the presence of an output schema, the description covers the core function and an important constraint. It could mention how it interacts with sibling tools, but the current content is sufficient for basic invocation.
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%, and the description adds minimal parameter meaning. It implies 'country' refers to a specific nation, but 'indicator' is not elaborated—no examples, allowed values, or format hints are provided. The description only partially compensates for the schema's lack of detail.
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: calculating a country's rank, percentile, and average gap relative to all OECD member countries. This specific verb+resource combination ('계산한다... 순위·백분위·평균 격차') distinguishes it from siblings like oecd_trend or oecd_compare.
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 a clear usage context by noting it compares only same-time data, ensuring comparability. This implies when to use the tool (for cross-country ranking at a fixed point) but does not explicitly mention alternatives or exclusion cases.
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 full burden. It discloses that the tool returns a list of indicators and dataflow IDs, which is helpful, but it doesn't mention things like read-only behavior, auth requirements, or output size. For a simple list tool this is adequate but not rich.
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 short sentences, front-loads the purpose, and contains no fluff. Every word 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?
The tool is simple with 0 parameters and an output schema, so the description doesn't need to explain return values in depth. It mentions the key output (dataflow IDs) and use case. A bit more detail about how the list is ordered or filtered could help, but it's largely 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 tool has zero parameters, so the description doesn't need to explain parameter details. The baseline for 0 parameters is 4, and the description correctly focuses on the output rather than parameter semantics.
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 'list' and clearly identifies the resource: registered OECD employment/labor indicators. It also states the output (dataflow IDs), which clearly differentiates it from sibling tools like oecd_search_dataflow or oecd_raw_query.
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 says to call this tool first when you don't know which indicators can be requested. This provides clear usage context, though it doesn't name specific alternative tools for exclusion.
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 burden. It implies a safe read-only search but does not disclose return format, error behavior, or other behavioral details beyond the basic action.
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 with front-loaded purpose and illustrative examples. No redundant words.
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 one-parameter tool with an output schema, the description covers purpose, usage context, and keyword semantics. It lacks explicit output behavior, but the output schema likely fills that 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?
Schema coverage is 0%, but the description compensates by specifying the keyword must be English and by providing example values, adding meaningful semantics 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 searches the entire OECD dataset (dataflow) by English keyword, using a specific verb+resource. It also distinguishes from siblings by noting it's for finding statistics not in registered indicators.
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: use when looking for stats not in registered indicators, with concrete keyword examples. However, it does not explicitly name alternative tools or state 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the default behavior ('비우면 최신값' – empty period yields latest value) and gives input examples. However, it does not disclose error handling, exact return format, or potential limitations; the output schema mitigates the return format gap.
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 brief, front-loaded with purpose, and uses three short bullet-style lines for parameters. Every sentence serves a purpose, with no redundant repetition of schema fields.
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 lookup with an output schema, the description covers the essential aspects: purpose, parameters, formats, and a pointer to the indicator list. It lacks only minor details like behavior for invalid inputs, but is otherwise complete for typical use.
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 coverage is 0%, so the description compensates by providing concrete examples for each parameter (indicator names, country variants like '한국'/'KOR', period formats). It adds value beyond the bare schema by explaining formats and defaults.
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 it performs an 'OECD 단일 수치 조회' (single value lookup) and returns the latest or specified-period value for a given country and indicator. This specific verb+resource distinguishes it from siblings like oecd_trend (time series) and oecd_compare (comparison).
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 implies use when a single value is needed and explicitly advises referencing oecd_list_indicators for indicator names. It does not explicitly mention when not to use it or mention alternative siblings, but the single-value scope is clear and provides adequate context.
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:

[![oecd_mcp MCP server](https://glama.ai/mcp/servers/seongapark/oecd_mcp/badges/card.svg)](https://glama.ai/mcp/servers/seongapark/oecd_mcp)

Score Badge

Copy to your README.md:

[![oecd_mcp MCP server](https://glama.ai/mcp/servers/seongapark/oecd_mcp/badges/score.svg)](https://glama.ai/mcp/servers/seongapark/oecd_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/seongapark/oecd_mcp'

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