imf-mcp-server
Server Details
Query IMF SDMX 3.0 macroeconomic data — 193 dataflows, WEO, BOP, CPI, exchange rates, 190 countries.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 5 of 5 tools scored.
Each tool has a clear, distinct purpose: listing dataflows, retrieving dimension codes, querying data, describing staged tables, and running SQL on results. Prerequisites are explicitly stated, eliminating ambiguity.
All tools follow a consistent 'imf_verb_noun' pattern in snake_case (e.g., imf_list_databases, imf_get_database). The slight variance in imf_dataframe_describe/query still fits the pattern with a qualifier prefix.
With 5 tools, the server covers the entire workflow from discovery to analysis without unnecessary duplication. The count is well-scoped for a specialized data query domain.
The tool set provides a complete lifecycle: list (imf_list_databases), describe (imf_get_database), query (imf_query_dataset), and post-query analysis via DataFrame tools. No obvious gaps for read-only SDMX data access.
Available Tools
5 toolsimf_dataframe_describeImf Dataframe DescribeARead-onlyIdempotentInspect
List DataCanvas tables and columns staged by a prior imf_query_dataset call. Returns each table's name, row count, and column schema (name + DuckDB type). Required before imf_dataframe_query to discover the table and column names for SQL.
| Name | Required | Description | Default |
|---|---|---|---|
| canvas_id | Yes | Canvas ID returned by imf_query_dataset when results were too large for inline delivery. |
Output Schema
| Name | Required | Description |
|---|---|---|
| tables | Yes | All tables registered on this canvas. |
| canvas_id | Yes | Canvas session ID that was introspected. |
| table_count | Yes | Total number of tables on the canvas. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral context beyond annotations: it requires a prior imf_query_dataset call and stages data. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences with no wasted words. The key information (purpose, prerequisite, output) is front-loaded and efficient.
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 has an output schema, so the description need not detail return values. It covers the input parameter and prerequisite call. Completeness is high for a simple listing tool with clear annotations.
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 the single parameter canvas_id. The description in the schema matches the tool description. Baseline of 3 is appropriate as the description adds no extra meaning beyond the schema.
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 tool lists DataCanvas tables and columns from a prior call, specifying return fields (name, row count, column schema). It distinguishes from sibling tools like imf_dataframe_query by noting it's a prerequisite.
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 explicitly says 'Required before imf_dataframe_query to discover the table and column names for SQL', providing clear when-to-use guidance. It does not explicitly state when not to use it, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
imf_dataframe_queryImf Dataframe QueryARead-onlyIdempotentInspect
Run a read-only SQL SELECT against a DataCanvas table staged by imf_query_dataset. Supports multi-country comparisons, time-series aggregation, and cross-indicator joins. Requires imf_dataframe_describe first to discover table and column names. Only SELECT statements are accepted — DML and DDL are rejected.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | Read-only SQL SELECT statement. Must start with SELECT. Reference tables by the names returned by imf_dataframe_describe. Example: SELECT time_period, value FROM spilled_abc123 WHERE time_period >= '2010' ORDER BY time_period. | |
| canvas_id | Yes | Canvas ID returned by imf_query_dataset when results were too large for inline delivery. |
Output Schema
| Name | Required | Description |
|---|---|---|
| rows | Yes | Query result rows, capped at the canvas row limit (default 10,000). |
| row_count | Yes | Total matching rows before the cap — may exceed rows.length. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint as true; description adds that DML/DDL are rejected, which is consistent but does not provide significant additional behavioral context beyond what annotations indicate.
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 efficiently convey purpose, prerequisites, and constraints with no unnecessary words, and the key information is front-loaded.
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 complexity, annotations, and that an output schema exists, the description covers prerequisites, supported operations, and constraints, making it fully adequate for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions; the description further enhances understanding by requiring SQL to start with SELECT, referencing tables from describe, and providing a concrete example, adding value beyond the schema alone.
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?
Description clearly states it runs read-only SQL SELECT against a DataCanvas table staged by imf_query_dataset, and lists supported operations (multi-country comparisons, time-series aggregation, cross-indicator joins), distinguishing it from siblings like imf_dataframe_describe and imf_query_dataset.
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?
Explicitly requires imf_dataframe_describe first to discover table/column names, and states that only SELECT is accepted while DML/DDL are rejected, providing clear context for when the tool should be used and its limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
imf_get_databaseImf Get DatabaseARead-onlyIdempotentInspect
Fetch a dataflow's dimension list and complete codelist for each dimension. Resolves human-readable terms to SDMX codes (e.g. "United States" → USA, "real GDP growth" → NGDP_RPCH). Required before imf_query_dataset — SDMX keys are opaque without codelist lookups. Country codes are ISO 3-letter (USA, GBR, DEU), not ISO 2-letter (US, GB, DE). The key_format field shows the exact dimension order required by imf_query_dataset. Note: codelists enumerate the code universe, not actual coverage — valid codes can still return no_data if the combination has no series in this dataflow.
| Name | Required | Description | Default |
|---|---|---|---|
| version | No | Dataflow version, e.g. 9.0.0. Auto-detected from the dataflow list when omitted. | |
| agency_id | No | Agency ID that publishes this dataflow, e.g. IMF.RES or IMF.STA. Auto-detected from the dataflow list when omitted. | |
| dataflow_id | Yes | Dataflow identifier from imf_list_databases, e.g. WEO, BOP, CPI. Case-sensitive. | |
| codelist_filter | No | Optional case-insensitive substring to search within each dimension's codelist (code ID and name). When set, returns all matching entries per dimension instead of the first-50 window — useful for large codelists like WEO INDICATOR (145 entries). Example: "CPI" or "PCPIPCH" surfaces consumer price index codes without hitting the 50-entry cap. |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | Human-readable dataflow name. |
| source | Yes | Attribution string required by IMF data terms: "Source: International Monetary Fund, <dataflow name>, <link>". |
| version | Yes | Dataflow version string, e.g. 9.0.0. |
| agency_id | Yes | Agency that publishes this dataflow, e.g. IMF.RES, IMF.STA. |
| dimensions | Yes | All dimensions of this dataflow with their codelists. |
| key_format | Yes | Dimension names in dot-separated keyPosition order, e.g. COUNTRY.INDICATOR.FREQUENCY. Use this exact format when constructing the key for imf_query_dataset. |
| dataflow_id | Yes | Dataflow identifier, e.g. WEO, BOP, CPI. |
| description | No | Extended description, if available. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by explaining that codelists enumerate the code universe, not actual coverage, and that valid codes can still return no_data. It also notes the key_format field and the behavior of the codelist_filter parameter for large lists. No contradictions with annotations.
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 paragraph that is relatively concise and front-loaded with the purpose. It contains multiple pieces of information without wasted words. Could be slightly improved by using bullet points for clarity, but it remains effective.
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 complexity (4 parameters, 1 required, output schema exists), the description is thorough. It covers purpose, usage context, parameter details, behavioral caveats, and expected outputs. No gaps are evident for an agent to use this tool correctly.
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?
Despite 100% schema coverage, the description adds significant value by explaining the resolution of human-readable terms to SDMX codes, the ISO 3-letter country code format, the key_format's role for imf_query_dataset, and the codelist_filter's ability to bypass the 50-entry cap. This goes well beyond the schema descriptions.
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 tool's purpose: fetching a dataflow's dimension list and complete codelist for each dimension, including resolving codes. It distinguishes from siblings by explicitly noting it's required before imf_query_dataset.
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 provides clear context on when to use the tool, specifically as a prerequisite for imf_query_dataset. It explains why SDMX keys are opaque without this step. However, it does not explicitly state when not to use it or discuss alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
imf_list_databasesImf List DatabasesARead-onlyIdempotentInspect
List all IMF SDMX dataflows available on the portal (193 total). Entry point for every query: imf_get_database and imf_query_dataset both require a dataflow id obtained here. Vintage (historical snapshot) dataflows such as WEO_2025_OCT_VINTAGE are excluded by default; set include_vintages=true to include them.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Optional name, ID, or description substring to filter results. Case-insensitive. Example: "exchange rate" returns ER and related dataflows. | |
| include_vintages | No | Include vintage (historical snapshot) dataflows such as WEO_2025_OCT_VINTAGE. Default false — vintages are excluded to keep the discovery surface clean. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Populated when the filter matches nothing — explains why and suggests next steps. |
| dataflows | Yes | Matching dataflows; pass the id to imf_get_database to resolve dimension codelists. |
| total_count | Yes | Total number of matching dataflows returned. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds the total count of dataflows and the default behavior regarding vintage exclusions, which provides additional behavioral context beyond annotations.
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?
Three sentences that front-load the core purpose, then provide usage context and a specific detail. No unnecessary words; 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 the presence of an output schema, the description adequately covers purpose, usage, parameter details, and default behavior. Slight gap on potential pagination or limits, but the total count suggests no pagination needed.
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?
Both parameters have full schema descriptions (100% coverage). The description enriches the filter parameter with an example and case-insensitivity note, and for include_vintages repeats the default with an example name, adding value beyond the schema.
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 tool lists all IMF SDMX dataflows with a specific count (193). It distinguishes itself from siblings by noting it provides dataflow IDs needed for other tools like imf_get_database and imf_query_dataset.
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?
Positions itself as the entry point for queries, explicitly mentioning that sibling tools require IDs obtained here. Also explains the default exclusion of vintages and how to include them. Could be more explicit about when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
imf_query_datasetImf Query DatasetARead-onlyIdempotentInspect
Query an IMF SDMX dataflow by dimension key over a time range. Returns observations with time_period, value, unit, scale, and status attributes. Requires imf_get_database first to obtain the correct key_format and valid dimension codes. Country codes are ISO 3-letter (USA, GBR, DEU — not US, GB, DE). Key format: dot-separated codes in DSD keyPosition order (e.g. USA.NGDP_RPCH.A for WEO). Use + to specify multiple codes per position (e.g. USA+GBR.NGDP_RPCH.A). Codelists from imf_get_database enumerate the code universe, not actual coverage — valid codes can still return no_data if the combination has no series. Large analytical result sets (multi-country, long time range) spill to DataCanvas; imf_dataframe_query provides SQL analysis of spilled results.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Dot-separated dimension codes in DSD keyPosition order. Call imf_get_database to get key_format and valid codes first. Use + to specify multiple codes (e.g. USA+GBR.NGDP_RPCH.A). Country codes are ISO 3-letter: USA not US, GBR not GB, DEU not DE. | |
| version | No | Dataflow version. Auto-detected from dataflow list when omitted. | |
| agency_id | No | Agency ID, e.g. IMF.RES or IMF.STA. Auto-detected from dataflow list when omitted. | |
| canvas_id | No | Existing canvas ID to accumulate results into across multiple queries. Omit to allocate a fresh canvas; the response includes a canvas_id when results spill to DataCanvas. | |
| end_period | No | End of time range (inclusive). Same format as start_period. Observations after this period are excluded from the result. | |
| dataflow_id | Yes | Dataflow identifier from imf_list_databases, e.g. WEO, BOP, CPI. | |
| start_period | No | Start of time range (inclusive). Format matches the dataflow frequency: YYYY (annual), YYYY-QN (quarterly, e.g. 2023-Q1), YYYY-MM (monthly). Observations before this period are excluded from the result. |
Output Schema
| Name | Required | Description |
|---|---|---|
| key | Yes | Dimension key used in the query, e.g. USA.NGDP_RPCH.A. |
| source | Yes | Attribution string required by IMF data terms: "Source: International Monetary Fund, <dataflow name>, <link>". |
| canvas_id | No | DataCanvas session ID — present when truncated=true. Pass to imf_dataframe_query or imf_dataframe_describe to query the full result. |
| truncated | Yes | True when the result exceeded the inline limit and was staged on a DataCanvas table; canvas_id and table_name are populated and imf_dataframe_query provides SQL access to the full set. |
| end_period | No | Latest period covered; absent when the full available range was used. |
| table_name | No | DuckDB table name on the canvas — present when truncated=true; reference in SQL via FROM <table_name>. |
| dataflow_id | Yes | Dataflow identifier that was queried, e.g. WEO. |
| observations | Yes | Inline observations. Empty when results spilled to canvas (see canvas_id / table_name). |
| start_period | No | Earliest period covered; absent when the full available range was used. |
| observation_count | Yes | Total observations in the result. |
| series_attributes | Yes | Series-level attributes (unit, scale, decimals). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint, idempotentHint) already indicate safety. Description adds behavioral detail: codelists enumerate universe not coverage, valid codes can return no_data, and large results spill to DataCanvas. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is lengthy but well-structured, front-loading purpose then detailing constraints. Each sentence provides necessary information; minimal fluff. Could be slightly compressed but effective.
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 complexity (7 params, output schema exists), description covers prerequisites, key format, country code nuance, codelist interpretation, and spill behavior. Output schema handles return values, so no missing info.
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 covers all 7 parameters (100%). Description adds significant meaning: key format examples (dot-separated, + for multiple), ISO 3-letter country codes, period format examples. Baseline 3, extra value justifies 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?
Description specifies the action (query an IMF SDMX dataflow by dimension key over time range) and the resource (dataflow, with returns listed). It distinguishes from sibling tools by mentioning imf_get_database as prerequisite and imf_dataframe_query for spilled results.
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?
Explicitly states when to use: requires imf_get_database first to obtain key_format and valid dimension codes. Provides alternative for SQL analysis of spilled results (imf_dataframe_query). Also clarifies code format requirements and codelist coverage limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!