imf-mcp-server
Server Details
Query IMF SDMX 3.0 macroeconomic dataflows — WEO, BOP, CPI, exchange rates, 190 countries.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/imf-mcp-server
- GitHub Stars
- 1
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.6/5 across 5 of 5 tools scored.
Each tool serves a distinct, non-overlapping purpose in a clear sequential workflow: listing dataflows, retrieving dimension/codelist details, querying SDMX datasets, and handling large result sets via DataCanvas. There is no ambiguity about which tool to use at each step.
All tools follow the imf_verb_noun pattern (e.g., imf_list_databases, imf_query_dataset, imf_dataframe_describe). The naming is uniform and predictable, making it easy for an agent to infer functionality from names alone.
With exactly 5 tools, the set is neither sparse nor bloated. Each tool is essential for the full data access workflow. The count is well-scoped for the IMF SDMX domain.
The tool surface provides a complete lifecycle for querying IMF data: discover dataflows (list), get metadata (get database), formulate queries (query dataset), and analyze large results (dataframe describe/query). No obvious gaps exist for the stated read-only purpose.
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. |
| dsd_version | No | Version of the underlying data structure definition (DSD) that backs this dataflow. Differs from version when the dataflow references a shared DSD (e.g. IIP → DSD_BOP at 24.0.0). |
| structure_ref | No | Identifier of the underlying DSD, e.g. DSD_BOP. Several dataflows can share one DSD. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds beyond annotations: codelists enumerate universe not coverage, ISO 3-letter codes, and no_data possibility.
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?
Concise at ~100 words, front-loaded, every sentence adds value.
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?
Covers purpose, prerequisites, important notes, parameter usage; output schema handles return values.
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?
With 100% schema coverage, baseline 3; adds examples and auto-detection context, enhancing meaning.
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 it fetches dimension list and codelist, distinguishes from siblings by being a prerequisite for 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 says 'Required before imf_query_dataset' and explains why, plus examples for parameter usage.
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 IMF SDMX dataflows available on the portal. 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. The returned total_count reflects the current live catalog size.
| 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 indicate readOnly and idempotent. Description adds that vintages are excluded by default and total_count reflects current catalog. 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?
Four sentences, each earning its place: purpose, dependencies, default behavior, return value. No redundant 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, the description covers entry point behavior, dependencies, default filtering, and output count. Output schema exists, so return structure is not needed. Complete for agent decision.
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 baseline is 3. Description adds an example for filter and rationale for include_vintages default, enhancing clarity beyond 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 verb 'List' and resource 'IMF SDMX dataflows', and distinguishes itself from siblings by noting that imf_get_database and imf_query_dataset require a dataflow id obtained here.
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?
It identifies itself as the entry point, specifies that siblings depend on its output, and explains default vintage exclusion. Lacks explicit when-not-to-use guidance but provides clear context.
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. start_period and end_period must be valid period strings (YYYY, YYYY-QN, or YYYY-MM) with start_period no later than end_period; malformed or reversed ranges are rejected. 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, and must be greater than or equal to 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?
Beyond annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds significant context: return attributes, key format with multiple code syntax, codelist coverage warning, period validation, error handling, and spill behavior. No contradiction 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, well-structured paragraph of about 8 sentences. It starts with the core purpose, then sequentially covers prerequisites, formatting, warnings, and spill behavior. Every sentence adds value; no wasted words.
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 (7 parameters, SDMX dataflow), the description covers prerequisites, key syntax, codelist limitations, period validation, error cases, and spill behavior with an alternative tool. It is complete for a query tool with rich 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%, but the description adds crucial details like key format (dot-separated, ISO 3-letter codes, + for multiple), period formats and constraints, and canvas_id usage. This adds meaning beyond the schema entries.
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 explicitly states 'Query an IMF SDMX dataflow by dimension key over a time range', clearly identifying the action (query) and resource (SDMX dataflow). It distinguishes from siblings by referencing imf_dataframe_query for spilled results, providing differentiation.
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 states the prerequisite: 'Requires imf_get_database first to obtain the correct key_format and valid dimension codes.' It also advises when to use an alternative: 'Large analytical result sets...spill to DataCanvas; imf_dataframe_query provides SQL analysis of spilled results.'
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!