UN Sustainable Development Goal indicators for all 17 goals, curated by country and year. Free.
Free discovery. Returns the list of live agent-ready data packs available on DaedalMap.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's focus on 'Returns the list' does not contradict that or add much beyond the annotation. The phrase 'live agent-ready data packs' adds context about what data is available, but does not disclose additional behavioral traits such as pagination, rate limits, or response structure.
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, clear sentence that communicates purpose and key context ('Free discovery', 'live agent-ready data packs') without wasted words. It is appropriately sized for the tool's simplicity.
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 parameterless, read-only listing tool, the description adequately states what it returns and the domain (DaedalMap). There is no output schema, but the return type ('list') is stated. Combined with the sibling context, this is sufficient 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?
The tool has zero parameters, so the description does not need to explain parameter semantics. The schema already documents this fully (schema description coverage 100%), and the baseline for zero-parameter tools 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 uses a specific verb ('Returns') and resource ('list of live agent-ready data packs available on DaedalMap'), clearly distinguishing it from siblings like get_pack and query_dataset. The 'Free discovery' phrase clarifies it's a zero-cost listing operation.
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 use for discovering available data packs ('Free discovery'), but does not explicitly state when to use this tool versus alternatives like get_pack or query_dataset. It provides some contextual hint but lacks explicit when-to-use or 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.
Free discovery. Returns detailed metadata, coverage, freshness, preferred canonical tool guidance, and first-query examples for one pack. Call this before querying a new pack so you can see time shape, coverage limits, and the paste-ready first query.
| Name | Required | Description | Default |
|---|---|---|---|
| pack_id | Yes | Pack identifier from get_catalog. Newly catalog-admitted packs require no MCP schema change. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already covering the safety profile, the description adds value by describing the read action as 'Free discovery' and enumerating the behavioral outputs: coverage, freshness, tool guidance, and example queries. It does not contradict the annotation.
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 deliver the tool's purpose, return contents, and usage sequence with no filler. The most important information is front-loaded ('Free discovery') 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?
For a simple one-parameter, read-only tool with no output schema, the description sufficiently enumerates what the agent will receive and when to call it. Combined with the schema, nothing essential is missing for correct invocation.
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 single parameter pack_id is fully documented in the schema, including its source from get_catalog, so the schema carries the semantic burden. The description adds no parameter-specific meaning, making the baseline 3 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 uses a specific verb and object—'Returns detailed metadata, coverage, freshness, preferred canonical tool guidance, and first-query examples for one pack'—which makes the resource and scope unmistakable. It also positions the tool as a discovery/pre-query step rather than a data-returning tool, distinguishing it from 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 gives clear contextual timing: 'Call this before querying a new pack so you can see time shape, coverage limits, and the paste-ready first query.' It does not explicitly name sibling tools or state when not to use it, but the intended workflow is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free blind-caller guidance for one tool visible on this MCP facade. Returns when to use it, what it refuses, a working example, effective access limits, important outputs, provenance fields, recommended next calls, and the shared natural-language-to-strict-JSON interaction contract. Use tools/list to discover names, then call this before an unfamiliar tool.
| Name | Required | Description | Default |
|---|---|---|---|
| tool_name | Yes | Exact tool name from tools/list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint annotation by detailing what the tool returns: 'when to use it, what it refuses, a working example, effective access limits, important outputs, provenance fields, recommended next calls, and the shared natural-language-to-strict-JSON interaction contract.' It also discloses its 'blind-caller' nature, adding useful behavioral context.
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. The first sentence lists the key informational outputs, and the second provides a clear usage workflow. Every word earns its place, with no filler or repetition.
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 (one required parameter, read-only, no output schema) and the description is exceptionally thorough. It explains purpose, usage, return content, and even the recommended sequence with tools/list. The description fully compensates for the lack of an output schema by enumerating the expected outputs.
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 schema already provides a clear description of the single parameter ('Exact tool name from tools/list'), giving 100% coverage. The description adds value by instructing to use tools/list to discover names, reinforcing the parameter's expected value and context, so the baseline 3 is exceeded.
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: providing 'guidance for one tool' visible on the MCP facade. It distinguishes itself from siblings (get_catalog, get_pack, query_dataset) by focusing on tool-facilitation rather than data retrieval, with a specific verb ('returns') and resource ('guidance for one tool').
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 explicit usage context: 'Use tools/list to discover names, then call this before an unfamiliar tool.' This clearly indicates when to use the tool (before unfamiliar tools) and implies a workflow. It doesn't explicitly state when not to use it, but the alternative (tools/list) is named, earning a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generic structured query for direct source_id or pack_id access using the same contract as POST /api/v1/query/dataset. Free packs: currency, distributed_manufacturing, floods, nri, owid, un_sdg, un_wpp, volcanoes, world_bank_wdi. Paid packs: earthquakes, hurricanes, tornadoes, tsunamis, wildfires, world_factbook, worldpop (x402 Base USDC).
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Optional sort instructions for row-returning queries. | |
| limit | No | Maximum number of rows to return for the requested source or pack. | |
| output | No | Optional output controls such as response format hints. | |
| filters | No | Structured filters including time, region_ids, and compare clauses. | |
| metrics | No | Metric ids to return. Use event_count for aggregate counts when supported. | |
| pack_id | No | Pack identifier from get_catalog. Newly catalog-admitted packs require no MCP schema change. | |
| source_id | No | Concrete source id such as 'earthquakes_events', 'volcanoes_events', 'hurricanes_events', or 'un_sdg/01'. | |
| request_id | No | Optional caller-supplied request id for tracing and idempotency. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this as a read-only operation, so the description's burden is lower. It adds a reference to the API contract but does not disclose potential side effects, limitations, or response behavior beyond what annotations already cover. This is adequate but not exceptional.
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, dense sentence that front-loads the main purpose and then lists relevant packs. It is efficient with no fluff, though the enumeration of pack names adds length. Overall it is well-structured and to the point.
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?
With 8 parameters including nested objects and no output schema, the description does not explain the response format or how to structure complex queries. It references the API contract as a hint, but that is indirect. The schema covers parameters, yet the overall contextual completeness for an agent would benefit from a brief note on expected return behavior.
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%, so all 8 parameters are already well-described in the input schema. The tool description adds little beyond the schema, offering only examples of source IDs and pack names. Since the schema carries the explanatory weight, the baseline score of 3 applies.
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 is a generic structured query for direct source_id or pack_id access, referencing the same contract as POST /api/v1/query/dataset. This distinguishes it from siblings like get_catalog (metadata) and get_pack (pack info) because it is the data-retrieval tool.
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 clear context that this tool is for querying data directly by source or pack ID, and lists the available free and paid packs. However, it does not explicitly exclude alternatives or state when to use get_catalog/get_pack instead, so it falls short of full '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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
get_pack1 field changedInput schema / properties / pack_id / descriptionPrevious value: -"Pack identifier such as 'currency', 'earthquakes', 'floods', 'hurricanes', 'tornadoes', 'tsunamis', 'un_sdg', 'volcanoes', 'world_factbook', or 'worldpop'."New value: +"Pack identifier from get_catalog. Newly catalog-admitted packs require no MCP schema change."query_dataset1 field changedInput schema / properties / pack_id / descriptionPrevious value: -"Pack identifier such as 'currency', 'earthquakes', 'floods', 'hurricanes', 'tornadoes', 'tsunamis', 'un_sdg', 'volcanoes', 'world_factbook', or 'worldpop'."New value: +"Pack identifier from get_catalog. Newly catalog-admitted packs require no MCP schema change."get_tool_helpget_pack1 field changedInput schema / properties / pack_id / descriptionPrevious value: -"Pack identifier such as 'currency', 'earthquakes', 'volcanoes', 'tsunamis', 'hurricanes', 'un_sdg', 'world_factbook', or 'worldpop'."New value: +"Pack identifier such as 'currency', 'earthquakes', 'floods', 'hurricanes', 'tornadoes', 'tsunamis', 'un_sdg', 'volcanoes', 'world_factbook', or 'worldpop'."query_dataset1 field changedInput schema / properties / pack_id / descriptionPrevious value: -"Pack id such as 'currency', 'earthquakes', 'volcanoes', 'tsunamis', 'hurricanes', 'un_sdg', 'world_factbook', or 'worldpop'."New value: +"Pack identifier such as 'currency', 'earthquakes', 'floods', 'hurricanes', 'tornadoes', 'tsunamis', 'un_sdg', 'volcanoes', 'world_factbook', or 'worldpop'."get_pack1 field changedInput schema / properties / pack_id / descriptionPrevious value: -"Pack identifier such as 'currency', 'earthquakes', 'volcanoes', 'tsunamis', 'hurricanes', 'un_sdg', or 'world_factbook'."New value: +"Pack identifier such as 'currency', 'earthquakes', 'volcanoes', 'tsunamis', 'hurricanes', 'un_sdg', 'world_factbook', or 'worldpop'."query_dataset1 field changedInput schema / properties / pack_id / descriptionPrevious value: -"Pack id such as 'currency', 'earthquakes', 'volcanoes', 'tsunamis', 'hurricanes', 'un_sdg', or 'world_factbook'."New value: +"Pack id such as 'currency', 'earthquakes', 'volcanoes', 'tsunamis', 'hurricanes', 'un_sdg', 'world_factbook', or 'worldpop'."query_dataset1 field changedInput schema / properties / limit / maximumAdded value: +500get_earthquake_eventsget_fx_ratesget_live_earthquake_eventsget_live_volcano_eventsget_tsunami_eventsget_volcanic_activityClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
No comments yet. Be the first to start the discussion!
World Bank World Development Indicators: curated country-year economy, health, education and more.
UN Sustainable Development Goals (SDG) Indicators MCP — UN Statistics Division.
Query 29,500+ World Bank development indicators for 200+ countries across 60+ years.
490+ economic & demographic indicators for 218 countries from IMF, World Bank, UN, FRED.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: get_catalog discovers available packs, get_pack provides metadata for a specific pack, get_tool_help gives usage guidance for a tool, and query_dataset executes queries. There is no overlap or ambiguity in their roles.
Three tools follow a 'get_*' pattern (get_catalog, get_pack, get_tool_help), but query_dataset breaks the pattern with a different verb. The objects vary (catalog, pack, tool_help, dataset) without a strict verb_noun structure, but the names remain understandable and readable.
With 4 tools, the server is well-scoped for a data access/query facade. Each tool covers a necessary step in the workflow (discover, inspect, get help, query) without bloat, fitting comfortably in the ideal 3-15 range.
The tool surface covers the full user journey for a data query server: discovery (get_catalog), metadata inspection (get_pack), tool guidance (get_tool_help), and actual querying (query_dataset). Minor gaps exist, such as no explicit way to list all available tools without using tools/list, but that is an MCP protocol concern rather than a domain coverage gap.
