Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@OECD MCP Server Compare GDP growth between US and Germany"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server providing AI assistants access to OECD's 5,000+ economic and statistical datasets via SDMX API. By connecting to the MCP server, you can use AI to search, analyze, and compare data from 38 OECD countries across economy, health, education, environment, and more.
En Model Context Protocol (MCP) server som ger AI-assistenter tillgång till OECD:s 5,000+ ekonomiska och statistiska dataset via SDMX API. Genom att ansluta till MCP-servern kan du med hjälp av AI söka, analysera och jämföra data från 38 OECD-länder inom ekonomi, hälsa, utbildning, miljö och mer.
Det är enkelt att ansluta en LLM / AI-chatbot till MCP-servern. Det enklaste sättet är att använda npm-paketet oecd-mcp via npx. Nedan finner du guider för olika klienter.
The easiest way to connect an LLM / AI chatbot to the MCP server is via the published npm package oecd-mcp using npx. Below you'll find guides for different clients.
1. Open Claude Desktop settings → Developer → "Edit Config"
2. Add to the JSON file:
{
"mcpServers": {
"oecd": {
"command": "npx",
"args": ["-y", "oecd-mcp"]
}
}
}3. Save and restart Claude Desktop
claude mcp add oecd npx -y oecd-mcpVerify: claude mcp list
~/.codex/config.toml:
[mcp.oecd]
command = "npx"
args = ["-y", "oecd-mcp"]
transport = "stdio"git clone https://github.com/isakskogstad/OECD-MCP.git
cd OECD-MCP
npm install
npm run buildThen point your client at node /absolute/path/to/OECD-MCP/dist/index.js, e.g.:
{
"mcpServers": {
"oecd": {
"command": "node",
"args": ["/absolute/path/to/OECD-MCP/dist/index.js"]
}
}
}Related MCP server: WHO MCP Server
Servern ansluter till OECD SDMX API och ger tillgång till 5,000+ dataset i 17 kategorier.
OECD SDMX API Tillgång till kvartalsvis nationalräkenskaper (QNA), huvudsakliga ekonomiska indikatorer (MEI), hälsostatistik, utbildningsdata, miljöindikatorer och mer från 38 OECD-medlemsländer plus partnerekonomier.
MCP-servern implementerar MCP-protokollet med stöd för:
9 verktyg — Dataset-upptäckt (5) och dataåtkomst (4)
7 resurser — Kategorier, länder, filterguide, ordlista, LLM-instruktioner
7 promptmallar — Ekonomisk analys, landsjämförelser, nordiskt fokus
The server connects to the OECD SDMX API providing access to 5,000+ datasets across 17 categories:
OECD SDMX API Access to quarterly national accounts (QNA), main economic indicators (MEI), health statistics, education data, environmental indicators, and more from 38 OECD member countries plus partner economies.
The MCP server implements the MCP protocol with support for:
9 tools — Dataset discovery (5) and data access (4)
7 resources — Categories, countries, filter guide, glossary, LLM instructions
7 prompt templates — Economic analysis, country comparisons, Nordic focus
Tool | Description |
| Search for datasets by keyword |
| List datasets by category |
| List all 17 data categories |
| Get commonly used datasets |
| Search for specific indicators |
| Get metadata for a dataset |
| Query statistical data |
| Generate OECD Data Explorer link |
| Detailed category information |
Resource | Description |
| 17 data categories with descriptions |
| Curated popular datasets |
| ISO 3166-1 alpha-3 country codes |
| SDMX filter syntax guide |
| Definitions of OECD terms |
| Instructions for AI assistants |
| API information |
Prompt | Description |
| Analyze economic trends over time |
| Compare data between countries |
| Get latest statistics |
| Guided dataset exploration |
| Find the right dataset for a question |
| Help building SDMX filters |
| Compare Nordic countries |
Verktyg:
Verktyg | Beskrivning |
| Fråga BNP, inflation, arbetslöshetsdata |
| Hitta dataset för forskningsfrågor |
| Förstå dataset-dimensioner |
Exempel:
"Jämför BNP-tillväxt mellan G7-länderna 2020-2024"
"Analysera inflationstrender i eurozonen"
"Hitta data om arbetsproduktivitet per sektor"
App-exempel: Mobil ekonomisk brief med BNP-trender och jämförelsediagram.
Verktyg:
Verktyg | Beskrivning |
| Bläddra i 17 policyområden |
| Hitta relevanta policy-dataset |
| Generera länkar för rapporter |
Exempel:
"Vilken sjukvårdsutgiftsdata finns för Sverige?"
"Hitta utbildningsresultatindikatorer för PISA-analys"
"Jämför miljöpolicyer i nordiska länder"
App-exempel: Hälsostatistik-dashboard med donutdiagram och landjämförelser.
Verktyg:
Verktyg | Beskrivning |
| Hitta specifika mätvärden |
| Få tillgång till ofta citerad data |
| Hämta siffror för artiklar |
Exempel:
"Hämta senaste arbetslöshetssiffror för EU-länder"
"Hitta inkomstojämlikhetsdata (Gini-koefficient)"
"Jämför skatteintäkter som % av BNP"
App-exempel: Produktivitetsjämförelse med stapeldiagram och trendlinjer.
Tools:
Tool | Description |
| Query GDP, inflation, unemployment data |
| Find datasets for research questions |
| Understand dataset dimensions |
Examples:
"Compare GDP growth between G7 countries 2020-2024"
"Analyze inflation trends in the Eurozone"
"Find data on labor productivity by sector"
App Example:
Mobile economic brief with GDP trends, G7 comparison charts, and sparkline visualizations from the QNA dataset.
Tools:
Tool | Description |
| Browse 17 policy areas |
| Find relevant policy datasets |
| Generate links for reports |
Examples:
"What healthcare spending data is available for Sweden?"
"Find education outcome indicators for PISA analysis"
"Compare environmental policies across Nordic countries"
App Example:
Health statistics dashboard with donut chart overview and country comparison from the HEALTH_STAT dataset.
Tools:
Tool | Description |
| Find specific metrics |
| Access commonly cited data |
| Get numbers for stories |
Examples:
"Get latest unemployment figures for EU countries"
"Find income inequality data (Gini coefficient)"
"Compare tax revenues as % of GDP"
Category | Code | Description | Datasets |
Economy | ECO | GDP, growth, inflation, interest rates | 500+ |
Employment | JOB | Labor market, wages | 300+ |
Trade | TRD | International trade | 250+ |
Health | HEA | Healthcare, life expectancy | 200+ |
Education | EDU | PISA, outcomes | 180+ |
Environment | ENV | Climate, emissions | 150+ |
Innovation | STI | R&D, patents, AI | 140+ |
Energy | NRG | Production, renewables | 120+ |
Taxation | TAX | Tax revenues, tax rates | 100+ |
Finance | FIN | Markets, banking | 95+ |
Government | GOV | Governance, public sector | 90+ |
Social | SOC | Inequality, quality of life | 85+ |
Agriculture | AGR | Production, food security | 75+ |
Industry | IND | Industrial production | 70+ |
Development | DEV | Development aid | 60+ |
Transport | TRA | Infrastructure, mobility | 50+ |
Regional | REG | Subnational data | 45+ |
Skapad av: Isak Skogstad
Kontakt: isak.skogstad@me.com
Fristående: Detta projekt är fristående och är inte anslutet till, godkänt av eller officiellt kopplat till OECD (Organisationen för ekonomiskt samarbete och utveckling).
Användarvillkor: Data tillhandahålls via OECD:s öppna SDMX API. Se OECD:s användarvillkor för användningsvillkor.
Created by: Isak Skogstad
Contact: isak.skogstad@me.com
Disclaimer: This project is independent and not affiliated with, endorsed by, or officially connected to the OECD (Organisation for Economic Co-operation and Development).
Terms of use: Data is provided via OECD's open SDMX API. See OECD Terms and Conditions for usage conditions.
OECD Data Portal: https://data.oecd.org/
SDMX Standard: https://sdmx.org/
MCP Documentation: https://modelcontextprotocol.io/
npm Package: https://www.npmjs.com/package/oecd-mcp
Issues: GitHub Issues
Built with Model Context Protocol SDK | Version 4.0.0
Get all available OECD data categories (17 categories covering all topics: Economy, Health, Education, Environment, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the scope and content of the output (17 categories covering all topics) but does not mention any behavioral nuances like caching, pagination, or authorization requirements. Without annotations, the description carries the full burden; it is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It efficiently communicates the tool's function, scope, and examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with no output schema, the description provides the essential information: what it returns (all categories) and a preview of the data (17 examples). However, it could be enhanced by noting the output format or if any filtering is supported.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since there are no parameters and the schema coverage is 100% (empty schema), the description adds relevant context about what the tool returns, which goes beyond the schema. According to guidelines, baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves all available OECD data categories, specifies the exact number (17), and provides a representative list of topics. This distinguishes it from siblings like list_categories_detailed, which likely returns more detailed information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as list_categories_detailed or search tools. The agent must infer usage based on the name and brief description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an OECD Data Explorer URL for a dataset. Use this to provide users with a direct link to explore data visually in their browser.
| Name | Required | Description | Default |
|---|---|---|---|
| dataflow_id | Yes | Dataflow ID | |
| filter | No | Optional dimension filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to state that the tool is read-only, non-destructive, or what happens on invalid input. It also does not describe the return value (a URL string) beyond the implication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with the verb and resource front-loaded. Every word serves a purpose, with no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits the return value format (a URL string). Since there is no output schema, mentioning the return type would enhance completeness. The schema coverage for parameters is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as both parameters have descriptions in the schema. The description adds no extra detail beyond the schema's 'Dataflow ID' and 'Optional dimension filter', so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generate') and the resource ('OECD Data Explorer URL for a dataset'). It distinguishes this tool from sibling tools (e.g., get_categories, list_dataflows) which focus on listing or querying data, not generating URLs for visual exploration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the use case: 'to provide users with a direct link to explore data visually in their browser.' While it doesn't explicitly mention when not to use it, the sibling tools are sufficiently different, making the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the metadata and structure of a specific OECD dataset. Returns dimensions, attributes, and valid values for querying data.
| Name | Required | Description | Default |
|---|---|---|---|
| dataflow_id | Yes | Dataflow ID (e.g., "QNA", "MEI", "HEALTH_STAT") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations exist, the description carries the full burden. It states the tool returns metadata and structure, implying a read-only operation. However, it does not explicitly mention side effects or safety considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear sentences with no unnecessary words. Front-loaded with purpose and includes return information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description adequately covers purpose and return content. Could hint at output format but not strictly necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no additional meaning beyond the schema's description of 'dataflow_id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool gets the metadata and structure of a specific OECD dataset, including dimensions, attributes, and valid values. This distinguishes it from siblings like 'list_dataflows' (list all dataflows) and 'query_data' (retrieve data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage before querying to understand dataset structure, but no explicit guidance on when to use vs. alternatives, or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a curated list of commonly used OECD datasets across all categories.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, rate limits, or return format. For a get operation, basic transparency is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that front-loads the action and object. Every word adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with no output schema, the description provides sufficient context: it returns a curated list of commonly used datasets across all categories. No major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (schema coverage 100%), so baseline is 4. The description adds no parameter info, but none is needed. It correctly indicates the tool takes no input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get' and specifies 'curated list of commonly used OECD datasets across all categories'. This distinguishes it from sibling tools like search_dataflows or list_dataflows which are not specifically curated or limited to popular ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly signals use when seeking popular datasets, but does not explicitly state when to avoid it or mention alternatives. Given the simplicity, it provides reasonable implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all OECD data categories with example datasets for each category. Returns comprehensive information about all 19 categories.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states it returns comprehensive information about 19 categories, but does not mention potential performance implications, rate limits, or the exact structure of the response. While adequate, more detail would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action ('Get all OECD data categories'), and contains no unnecessary words. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description is fairly complete. It clearly defines the tool's purpose and output. However, it could mention if there are any prerequisites or if the operation is resource-intensive, but overall it is sufficient for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and schema coverage is 100%. The description adds value by specifying the return content (example datasets, all 19 categories) beyond the empty schema. Baseline for zero parameters is 4, and description meets it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'all OECD data categories with example datasets', and specifies the scope as all 19 categories. This effectively distinguishes the tool from siblings like 'get_categories' (likely simpler) and other data tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool retrieves all categories with examples, but provides no guidance on when to use it versus alternatives like 'get_categories' or when not to use it. The context is implied 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.
List available OECD dataflows (datasets), optionally filtered by category. Use this to browse datasets by topic area.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional category filter: ECO, HEA, EDU, ENV, TRD, JOB, NRG, AGR, GOV, SOC, DEV, STI, TAX, FIN, TRA, IND, REG, HOU, MIG | |
| limit | No | Maximum number of results (default: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states basic list/filter functionality. It does not disclose behavioral traits such as pagination, sorting, rate limits, or what happens with no results. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The purpose and optional filter are stated upfront, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters and no output schema, the description is fairly complete. It provides enough context for browsing, though it could mention the return format (e.g., list of names/IDs).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds marginal meaning by linking category filtering to browsing by topic area. However, it does not provide new syntax or format details beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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)', and clarifies optional filtering by category. It effectively distinguishes from siblings like 'get_categories' and 'search_dataflows' by focusing on browsing datasets by topic area.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 but does not provide explicit guidance on when to use this tool versus alternatives like 'search_dataflows' or conditions to avoid. No exclusion criteria or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query actual statistical data from an OECD dataset. ⚠️ IMPORTANT: Defaults to last 100 observations (max 1000) to protect context window. Use filters, time periods, or last_n_observations to control data size. Large datasets (e.g. SOCX_AGG) can have 70,000+ observations - always specify limits!
| Name | Required | Description | Default |
|---|---|---|---|
| dataflow_id | Yes | Dataflow ID to query | |
| filter | No | Dimension filter (e.g., "USA.GDP.." for US GDP). Use "*" or "all" for all values. Get structure first to see valid dimensions. | |
| start_period | No | Start period (e.g., "2020-Q1", "2020-01") | |
| end_period | No | End period (e.g., "2023-Q4", "2023-12") | |
| last_n_observations | No | Get only the last N observations (default: 100, max: 1000 to protect against context overflow) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses default behavior (last 100 observations, max 1000) and context protection. However, it does not state whether the operation is read-only or mention any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, one bold warning, no fluff. Key information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers the critical behavioral trait (data size limits). It does not explain return format, but that is acceptable for a query tool where the data structure is likely known from get_data_structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds context beyond the schema: it explains the purpose of last_n_observations, its default and max, and warns about large datasets. This adds value for an agent deciding how to parameterize the call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query actual statistical data from an OECD dataset,' specifying the verb and resource. It distinguishes from siblings like list_dataflows or get_data_structure by focusing on data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on controlling data size with filters, time periods, or last_n_observations, including a concrete example (SOCX_AGG). Warns about defaults and limits, but does not explicitly state when not to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for OECD datasets (dataflows) by keyword. Returns matching datasets with their IDs, names, and descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query to find relevant datasets | |
| limit | No | Maximum number of results to return (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States it returns matching datasets with fields, but does not disclose auth needs, rate limits, pagination, or error behavior. Adequate for a simple search, but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence with no wasted words. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with 2 parameters and no output schema, the description covers the essentials: what it searches, how (keyword), and what is returned. Could mention pagination or sorting, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (query, limit). Description adds little beyond schema, as the schema already explains each parameter. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Search for OECD datasets (dataflows) by keyword', specifying the verb (search), resource (datasets), and output (IDs, names, descriptions). Distinguishes from sibling 'list_dataflows' which would list all, while this searches by keyword.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when keyword-based search is needed, and sibling 'list_dataflows' suggests alternative for browsing all. However, no explicit when-not-to-use or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for specific economic or social indicators by keyword (e.g., "inflation", "unemployment", "GDP").
| Name | Required | Description | Default |
|---|---|---|---|
| indicator | Yes | Indicator to search for | |
| category | No | Optional category filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the basic search functionality without disclosing behavioral traits such as pagination, rate limits, error handling, or whether results are limited. The implied read-only nature of 'search' is not explicitly confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with 12 words. It is front-loaded with the verb and resource. However, it could include slightly more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema or annotations, the description is minimally adequate. It tells the basic purpose and gives examples, but lacks details about the return format, result limits, or how it differs from sibling tools like list_categories_detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters having descriptions. The description adds no additional meaning beyond the schema; it rephrases the search parameter as 'by keyword' but does not provide syntax, format, or examples for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb-resource combination 'Search for specific economic or social indicators' and provides concrete keyword examples ('inflation', 'unemployment', 'GDP'). This distinguishes it from sibling tools like query_data (which queries data values) and search_dataflows (which searches for dataflows).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies using this tool when searching for indicators by keyword, but does not explicitly state when to use it versus alternatives or provide any exclusions. The examples help, but there is no guidance on 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v4.0.0get_categoriesget_data_structureget_dataflow_urlget_popular_datasetslist_categories_detailedlist_dataflowsquery_datasearch_dataflowssearch_indicatorsMost tools have distinct purposes, but get_categories and list_categories_detailed overlap in returning category info, though descriptions differentiate by detail level. search_dataflows and list_dataflows both return datasets but use different filters.
Tools follow a consistent verb_noun pattern (e.g., get_categories, search_dataflows). Minor deviations like list_categories_detailed and get_popular_datasets include adjectives, but overall pattern is clear.
9 tools cover the full workflow of browsing, searching, getting metadata, and querying data without being excessive. Each tool serves a clear role.
The set covers all necessary operations for exploring OECD data: listing/searching datasets, retrieving metadata, querying data, and generating visualization URLs. No obvious gaps for the read-only domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search and query 1,500+ OECD statistical datasets via SDMX. Keyless.
Give your agent web search and authoritative datasets: S&P Global, FRED, OECD, SimilarWeb & more.
Global economic data from World Bank and OECD
Macro data for AI agents: GDP, inflation, unemployment and more (World Bank, US BLS). No keys.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/isakskogstad/OECD-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
