A
license-
qualityA
maintenanceEnables searching, exploring, and querying over 1,500 OECD statistical datasets via SDMX, covering national accounts, employment, trade, PISA, health, and more.
468
2
Apache 2.0
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
- Server Listing
- imf-mcp-server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
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.
100% free. Your data is private.
Tool Definition Quality
A4.6/5.0
Tool DescriptionsA
Average 4.7/5 across 5 of 5 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool has a distinct role in the workflow: listing dataflows, getting database schema, querying datasets, and analyzing staged results. The two query tools are clearly separated by their data source (SDMX vs DataCanvas). Descriptions explicitly state prerequisites, eliminating ambiguity.
Naming Consistency4/5
All tools share the 'imf_' prefix and use underscore separation, but the pattern mixes verb-noun (list_databases, get_database, query_dataset) with noun-verb (dataframe_describe, dataframe_query). This is a minor inconsistency; a uniform verb-first pattern would be clearer.
Tool Count5/5
Five tools is well-scoped for the server's purpose: it covers the full discovery-to-analysis pipeline without unnecessary redundancy. Each tool is necessary and the count feels neither sparse nor overwhelming.
Completeness5/5
The tool set provides a complete read-only workflow: list available dataflows, get database structure with codelist resolution, query observations, and analyze large results via DataCanvas. There are no obvious gaps for the stated domain.
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| canvas_id | Yes | Canvas ID returned by imf_query_dataset when results were too large for inline delivery. |
Output Schema
ParametersJSON 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
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by revealing that the tool depends on data staged by a prior imf_query_dataset call. It also clarifies the output table and column schema, which is not obvious from annotations alone. No contradictions with readOnlyHint or idempotentHint.
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 consists of two sentences, each serving a clear purpose: the first states the action and return value, the second provides usage context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter, annotations, output schema), the description fully covers the tool's role in the data flow, its prerequisites, and its output. No gaps are evident.
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 100%, with the input schema already providing a good description of canvas_id. The tool description does not add new parameter-level details, so a baseline score of 3 is appropriate.
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 lists DataCanvas tables and columns, and specifies the return includes name, row count, and column schema. It distinguishes from siblings by positioning as a required precursor to imf_dataframe_query and by referencing a prior imf_query_dataset call.
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 states the tool is 'Required before imf_dataframe_query to discover the table and column names for SQL,' providing clear context on when to use it. It implicitly excludes use before imf_query_dataset, though it stops short of stating negative cases or alternatives.
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. One SELECT statement per call; a leading WITH … SELECT (CTE) is accepted. DML and DDL are rejected.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | Read-only SQL SELECT statement — exactly one statement, starting with SELECT or with a WITH … SELECT common table expression. 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| rows | Yes | Query result rows, capped at the canvas row limit (default 10,000). |
| row_count | Yes | Number of rows materialized in rows. Equals the canvas row limit when truncated is true — DataCanvas does not report a pre-cap total, so this is never larger than rows.length. |
| truncated | Yes | True when the query matched more rows than the canvas row limit and the result was capped. Page the remainder with a stable ORDER BY plus LIMIT/OFFSET, or narrow the query with WHERE or aggregation. |
Tool Definition Quality
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already declare readOnlyHint=true and idempotentHint=true, the description goes further by adding behavioral details: it rejects DML/DDL, accepts a single SELECT with optional CTE, and requires prior table/column discovery. No contradiction exists between the description and annotations.
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 three sentences long and front-loaded with the main action. Every sentence adds distinct value: the primary behavior, supported capabilities, prerequisites, and constraints. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description is complete: it covers the prerequisite workflow, data source, SQL constraints, and supported query patterns. No critical operational context is missing, and the agent can safely invoke the tool with correct expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with detailed descriptions for both 'sql' and 'canvas_id', so the baseline is 3. The tool description does not add new parameter-specific semantics beyond restating the one-statement rule and the source of the canvas_id, which are already in the 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 uses a specific verb ('Run a read-only SQL SELECT') and identifies the exact resource ('DataCanvas table staged by imf_query_dataset') and capabilities (multi-country comparisons, time-series aggregation, cross-indicator joins). This clearly distinguishes 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a prerequisite ('Requires imf_dataframe_describe first'), sets a hard constraint ('One SELECT statement per call'), and defines exclusions ('DML and DDL are rejected'). This gives the agent full when-to-use and when-not-to-use guidance.
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 with a codelist preview 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. Each codelist is capped at the first 50 entries by default; set codelist_filter to return every entry matching a substring, or read the imf://database/{dataflow_id} resource for complete codelists. 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.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | Human-readable dataflow name. |
| notice | No | Populated when a codelist_filter matched no entries anywhere, or when a dimension has no resolvable codelist — the two produce the same empty array and need opposite next steps. |
| 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 | This dataflow's own description in full — not the shared DSD's, and not the shortened preview imf_list_databases returns for the same id. Absent when the dataflow publishes none. |
| 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. |
| codelist_filter | No | Echo of the codelist_filter that produced this result. Absent when no filter was applied — an empty codelist then means the codelist could not be resolved, not that the filter missed. |
Tool Definition Quality
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds several behavioral details beyond annotations: the 50-entry default cap, codelist_filter substring behavior, ISO 3-letter vs 2-letter codes, and the crucial caveat that codelists enumerate the universe, not coverage. These enrich the readOnlyHint/idempotentHint annotations without contradicting them.
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 dense but well-organized, front-loading the primary purpose and then addressing filtering, code format, and coverage caveats. Each sentence adds value, though it could be tightened by merging related notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (SDMX codes, codelists, key ordering), the description covers purpose, usage context, filter behavior, alternatives, and a critical no_data caveat. With an output schema present, it doesn't need to detail return structure, making it comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 100%, the baseline is 3, but the description meaningfully augments parameter semantics: it explains the codelist_filter's function relative to the 50-entry cap, provides an example, and notes dataflow_id case sensitivity. This goes beyond the schema's field descriptions.
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 explicitly states the tool fetches a dataflow's dimension list with codelist previews, using a specific verb and resource. It distinguishes itself from siblings by positioning itself as a prerequisite for imf_query_dataset and by contrasting with the resource for complete codelists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states this tool is required before imf_query_dataset, establishing when to use it. It also mentions an alternative (reading the imf://database/{dataflow_id} resource) and provides guidance on codelist_filter for large lists, though it doesn't explicitly say when not to use siblings.
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. Results are paged — 50 per call by default, adjustable with limit and offset — and total_count reports how many dataflows matched. Descriptions are shortened here; imf_get_database returns the full text for a single dataflow.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum dataflows to return in this call. Default 50, ceiling 200; total_count reports how many matched, so a partial page is always recognizable as one. | |
| filter | No | Optional name, ID, or description substring to filter results. Case-insensitive. Example: "exchange rate" returns ER and related dataflows. | |
| offset | No | Number of matching dataflows to skip before this page. Combine with limit to page through a broad or unfiltered catalog. | |
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit that bounded this page. |
| shown | No | Dataflows returned in this page. |
| notice | No | Populated when the filter matches nothing, or when matches remain beyond this page — explains why and names the next offset to request. |
| offset | Yes | Number of matching dataflows skipped before this page. |
| dataflows | Yes | This page of matching dataflows; pass the id to imf_get_database to resolve dimension codelists. |
| truncated | No | True when matching dataflows remain beyond this page. |
| total_count | Yes | Dataflows matching filter and include_vintages, before limit and offset are applied. Exceeds returned_count when more pages remain. |
| returned_count | Yes | Dataflows in this page — the length of dataflows. |
Tool Definition Quality
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description discloses pagination behavior (50 per call, adjustable with limit and offset, total_count reporting), exclusion of vintages by default, and that descriptions are shortened. These are important behavioral traits not covered by annotations.
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 three sentences, front-loaded with purpose, then entry-point context, then pagination and response details. Every sentence earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's list-like nature, the annotations (read-only, idempotent) and the presence of an output schema, the description covers purpose, usage, vintages, pagination, and response content. It is complete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context about pagination (e.g., 'adjustable with limit and offset') and total_count, but these details are largely also present in the schema's parameter descriptions. It does not add new semantic meaning for the parameters beyond what the schema already provides.
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 purpose: 'List IMF SDMX dataflows available on the portal.' It uses a specific verb and resource, and distinguishes itself from siblings by noting it is the entry point for imf_get_database and imf_query_dataset, which 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: it is the entry point for every query, and the sibling tools imf_get_database and imf_query_dataset both require a dataflow id from this listing. It also explains the default exclusion of vintages and how to include them, guiding selection for different needs.
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, and status, plus the unit, scale, and decimals of each series — a key resolving to several series carries one entry per series in series_metadata, since unit and scale differ between them. 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). Every position must carry a code: use + to combine codes (e.g. USA+GBR.NGDP_RPCH.A) and * to match every code at a position (e.g. *.NGDP_RPCH.A for all countries). 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-SN, YYYY-QN, YYYY-MM, or YYYY-MM-DD) with start_period no later than end_period; malformed or reversed ranges are rejected. A bound covers the whole period it names, so end_period 2023 includes 2023-M12 and 2023-Q4. Large analytical result sets (multi-country, long time range) spill to DataCanvas; imf_dataframe_query provides SQL analysis of spilled results.
ParametersJSON Schema
| 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 combine codes at one position (e.g. USA+GBR.NGDP_RPCH.A). Use * to match every code at a position — *.NGDP_RPCH.A returns the indicator for all countries, and CAN.*.A every indicator for Canada. Every position needs a code or a *; an empty segment (USA..A) is rejected. 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 formats as start_period, and must not be earlier than it. The bound covers the whole period it names, so end_period 2023 admits 2023-M12 and 2023-Q4. 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). Accepts any of YYYY (annual), YYYY-SN (semi-annual, e.g. 2023-S1), YYYY-QN (quarterly, e.g. 2023-Q1), YYYY-MM (monthly), or YYYY-MM-DD (daily), whatever the dataflow's frequency. The bound covers the whole period it names, so start_period 2023 admits 2023-M01 and 2023-Q1. Observations before this period are excluded from the result. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| key | Yes | Dimension key used in the query, e.g. USA.NGDP_RPCH.A. |
| notice | No | Populated when a period bound was set but some observations carry a time_period label the range filter does not recognize — those rows are returned unfiltered, so the requested range did not apply to them. |
| 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. |
| series_metadata | No | Per-series attributes, one entry per distinct series_key in the result. Present only when the query resolved to more than one series; a single-series query carries its values in series_attributes instead. Unit and scale differ across series in one query — WEO NGDPD is USD at scale 9 while NGDP_RPCH is PT unscaled — so interpret each series against its own entry. |
| observation_count | Yes | Total observations in the result. |
| series_attributes | Yes | Attributes of the first series in the result — the same series as series_metadata[0]. A key with + or * resolves to several series whose scale and unit differ, and this field describes only the first of them: read series_metadata for the rest, and never apply these values to another series_key. |
Tool Definition Quality
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations declare readOnlyHint, openWorldHint, and idempotentHint, the description adds substantial behavioral context: per-series metadata entries, ISO 3-letter code requirement, valid-code-still-no-data possibility, inclusive period bounds, and DataCanvas spill. These go well beyond the annotations.
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 dense and well-structured, starting with the core purpose, then key syntax, edge cases, and spill behavior. Every sentence provides unique value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, output schema, multiple edge cases), the description fully covers prerequisites, key syntax, period validation, return metadata, and error behavior, and it integrates well with the sibling tools and existing schema. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful semantics: examples of key formatting (+ and * operators), start/end period interpretation, and the distinction between codelist universe and actual series coverage. This enhances understanding beyond the parameter descriptions.
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 ('Query') with a clear resource ('IMF SDMX dataflow') and scope ('by dimension key over a time range'), while also noting the return structure. This clearly differentiates it from siblings like imf_get_database and imf_dataframe_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states a required prerequisite ('Requires imf_get_database first'), provides key format rules, and points to imf_dataframe_query for spilled results. This gives concrete when-to-use and follow-up guidance, effectively positioning the tool among its siblings.
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!
Related MCP Servers
- Alicense-qualityCmaintenanceProvides access to European Central Bank statistical data through SDMX data flows, enabling querying and listing of data flows via natural language or direct tool calls.3MIT
- AlicenseAqualityAmaintenanceOfficial economic statistics with full citations — World Bank, IMF WEO, ECB — plus verify_stat to check a claimed figure against the official series. Free, remote, no auth.121MIT
- AlicenseAqualityBmaintenanceEnables querying, exploring, and downloading ISTAT statistical datasets via SDMX REST API, with unified metadata, territorial code resolution, and data extraction.7MIT
Try in Browser
Your Connectors
Sign in to create a connector for this server.