World Bank Data360 MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: search_datasets_tool and search_local_indicators serve different search functions (API vs. offline), get_temporal_coverage_tool handles year availability, retrieve_data_tool fetches actual data, and list_popular_indicators provides curated discovery. The descriptions explicitly differentiate their roles, preventing agent misselection.
Naming Consistency3/5
The naming is mixed, with some tools using verb_noun (search_datasets_tool, retrieve_data_tool) and others using noun_verb (get_temporal_coverage_tool, list_popular_indicators). While all names are readable and descriptive, the inconsistency in verb placement and suffix usage ('_tool' on some but not others) reduces predictability. The pattern is not chaotic but lacks uniformity.
Tool Count5/5
With 5 tools, the count is well-scoped for a World Bank data server, covering essential workflows: discovery (search_local_indicators, list_popular_indicators), search (search_datasets_tool), validation (get_temporal_coverage_tool), and retrieval (retrieve_data_tool). Each tool earns its place without bloat, supporting a clear data access pipeline.
Completeness4/5
The tool set covers the core data retrieval workflow comprehensively: search, temporal validation, and data fetching, with additional discovery aids. Minor gaps exist, such as no explicit tools for filtering or aggregating data beyond basic parameters, but agents can work around these using the provided tools. The surface supports end-to-end data access without dead ends.
Average 4.5/5 across 5 of 5 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and delivers comprehensive behavioral disclosure. It explains how parameters affect API behavior (e.g., countries parameter fetches only those countries efficiently, exclude_aggregates filters out regional codes), describes defaults and their rationale (limit default 20 for token minimization), and details response formatting expectations. No contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (prerequisite, type requirements, examples, how it works, formatting instructions). However, it's quite lengthy with repetitive emphasis on type requirements. Some information could be more condensed while maintaining clarity, as multiple examples and warnings about quotes could be streamlined.
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 (10 parameters, 0% schema coverage, no annotations, but has output schema), the description is remarkably complete. It covers prerequisites, parameter semantics, behavioral traits, defaults, examples, and post-processing instructions. The output schema existence means return values don't need explanation, and the description provides everything else needed for effective use.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter semantics. It explains type requirements with examples, describes what each parameter does (e.g., 'countries parameter: API fetches ONLY those countries'), clarifies defaults and their effects, and provides correct JSON examples. This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves data from World Bank Data360, which is a clear purpose. However, it doesn't differentiate from sibling tools like search_datasets_tool or list_popular_indicators, leaving it vague whether this is for raw data retrieval versus metadata exploration. The description focuses more on technical requirements than distinguishing functionality.
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 provides explicit guidance: it states a prerequisite (call get_temporal_coverage first), gives clear examples of when to use specific parameters, and implicitly contrasts with siblings by focusing on actual data retrieval rather than metadata. The 'HOW IT WORKS' section offers detailed context for parameter selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it's a search operation (implied read-only), returns a list of datasets with specific fields (indicator IDs, names, database IDs, search scores), and includes optimization tips for query formatting (e.g., removing punctuation, expanding abbreviations). However, it lacks details on error handling, rate limits, or authentication needs, which are minor gaps given the context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with XML-like tags (<purpose>, <workflow>, etc.), which aids organization but adds verbosity. Each section earns its place by providing workflow context, optimization tips, and examples, but the formatting could be more streamlined. It's appropriately sized for the tool's complexity but not maximally concise due to the markup style.
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 (2 parameters, no annotations, 0% schema coverage, but with an output schema), the description is highly complete. It covers purpose, workflow integration, parameter usage tips, common databases, examples, return values, and next steps. The presence of an output schema means the description doesn't need to detail return formats, and it effectively fills all other contextual gaps, making it sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It adds significant meaning beyond the schema: it explains that 'search_query' should be optimized using the provided tips (e.g., 'Remove punctuation') and implies 'top' controls result count with a default of 20. While it doesn't detail parameter constraints or formats explicitly, the examples and tips offer practical guidance, adequately compensating for the schema gap.
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's purpose as 'Search World Bank Data360 for datasets' and distinguishes it from siblings by positioning it as 'STEP 1 of 3 in the data retrieval workflow' and specifying it finds 'indicator IDs and database IDs needed for subsequent data operations.' This clearly differentiates it from tools like 'retrieve_data_tool' or 'search_local_indicators' by focusing on metadata discovery rather than data retrieval or local searches.
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 provides explicit guidance on when to use this tool versus alternatives through the <workflow> section, which outlines a three-step process where this tool is step 1 for finding IDs, followed by 'get_temporal_coverage' and 'retrieve_data.' It also lists sibling tools like 'list_popular_indicators' and 'search_local_indicators' in context, though it doesn't explicitly contrast them, the workflow implies this tool is for initial searches in the broader retrieval process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's role in a workflow, its prerequisite nature, and what it returns (start_year, end_year, latest_year, full list). However, it doesn't mention potential errors, rate limits, or authentication needs, leaving some behavioral aspects uncovered.
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 well-structured with clear sections (purpose, critical note, workflow, returns, next step) and uses bullet points for readability. It's appropriately sized for its complexity, though the workflow repetition and imperative tone ('Done ✓', 'Check') could be slightly streamlined without losing clarity.
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 moderate complexity, no annotations, and the presence of an output schema, the description is complete enough. It covers purpose, usage context, workflow integration, return values, and next steps. The output schema will handle detailed return structure, so the description appropriately focuses on higher-level guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. While it doesn't explicitly explain the 'indicator' and 'database' parameters, it contextualizes them by stating this tool is for 'a specific dataset' after search_datasets, implying these parameters identify that dataset. This adds meaningful semantics beyond the bare schema, though not exhaustive parameter details.
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 with specific verbs ('Get available years') and resources ('for a specific dataset'), distinguishing it from siblings like retrieve_data_tool (which fetches actual data) and search_datasets_tool (which finds datasets). It explicitly mentions what it returns, making the purpose unambiguous.
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 provides explicit guidance on when to use this tool, stating it should 'Always call this BEFORE retrieve_data to avoid errors' and outlining a workflow with steps 1-3. It differentiates from alternatives by positioning this as a prerequisite to retrieve_data_tool, with clear sequencing instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: 'instant, offline' operation, 'no API call,' 'returns relevance-ranked matches,' and 'instant results.' It also clarifies what is NOT returned ('indicator codes but NOT database IDs'). However, it doesn't mention potential limitations like cache freshness or what happens with no matches.
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 well-structured with clear sections (purpose, how it works, search tips, examples, parameters, returns, note) and front-loads key information. While comprehensive, some sections like the example queries could be more concise. Every sentence adds value, but there's minor verbosity in the examples.
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 (search functionality with behavioral nuances), no annotations, and an output schema (which handles return values), the description is remarkably complete. It covers purpose, usage guidelines, behavioral traits, parameter semantics, workflow integration with siblings, and practical examples, leaving no significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It provides meaningful context for both parameters: 'query' is explained with examples and search tips (e.g., 'simple keywords,' 'case-insensitive'), and 'limit' is clarified as 'maximum number of results to return' with the default value. This adds substantial value beyond the bare 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 clearly states the tool's purpose: searching through locally cached metadata for World Bank indicators. It specifies the verb 'search' and resource 'local metadata for World Bank indicators,' and explicitly distinguishes it from the sibling 'search_datasets' tool by noting this is a 'FAST alternative' for discovering available data types before API search.
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 provides explicit guidance on when to use this tool versus alternatives. It states 'Use this to discover what types of data are available before using the API search' and names the specific alternative 'search_datasets.' It also includes a note explaining the workflow: after finding indicators here, use search_datasets to get database IDs for data retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It effectively discloses behavioral traits: it's a read-only discovery tool (implied by 'Get' and 'curated list'), returns exactly 38 indicators with specific fields (codes, names, descriptions, categories), and provides the complete category breakdown. However, it doesn't mention potential limitations like rate limits or authentication requirements.
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?
Well-structured and appropriately sized. The description is front-loaded with the core purpose, followed by usage context, detailed category breakdown, return format, and clear next steps. Every sentence adds value with zero waste.
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 has 0 parameters, 100% schema coverage, and an output schema exists, the description provides excellent completeness. It explains the tool's purpose, when to use it, what it returns (including the exact count of 38 indicators and their structure), and how to proceed with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so baseline is 4. The description appropriately explains this is a parameterless tool for browsing curated content, which adds useful semantic context beyond the empty 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 clearly states the tool's purpose: 'Get a curated list of popular World Bank indicators' with specific resource ('World Bank indicators') and verb ('Get'). It distinguishes from sibling tools like search_datasets_tool by emphasizing this is for discovery without searching, not for retrieving actual data.
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?
Explicit guidance is provided: 'Perfect for getting started or exploring what data is available' and 'Browse the list, pick an indicator code, then use search_datasets to find the exact database ID before retrieving data.' This clearly states when to use this tool versus alternatives like search_datasets_tool and retrieve_data_tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![world-bank-data-mcp MCP server](https://glama.ai/mcp/servers/llnOrmll/world-bank-data-mcp/badges/card.svg)](https://glama.ai/mcp/servers/llnOrmll/world-bank-data-mcp)

Score Badge

Copy to your README.md:

[![world-bank-data-mcp MCP server](https://glama.ai/mcp/servers/llnOrmll/world-bank-data-mcp/badges/score.svg)](https://glama.ai/mcp/servers/llnOrmll/world-bank-data-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/llnOrmll/world-bank-data-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server