UNHCR Population Data MCP Server

by rvibek

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
The tools are mostly distinct, covering demographics, population, RSD applications, RSD decisions, and solutions. However, get_demographics_data and get_population_data could be confused as both handle forcibly displaced populations, though demographics focuses on age/sex breakdowns while population covers types like refugees. Descriptions help clarify, but overlap exists.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with 'get_' prefix and descriptive nouns (e.g., get_demographics_data, get_population_data). This predictable naming makes it easy for agents to understand and navigate the toolset without confusion.
Tool Count5/5
With 5 tools, the server is well-scoped for UNHCR population data, covering key aspects like demographics, population figures, RSD processes, and solutions. Each tool serves a clear purpose, avoiding bloat while providing comprehensive coverage for the domain.
Completeness4/5
The toolset covers core UNHCR data areas well, including demographics, population types, RSD applications/decisions, and solutions. A minor gap is the lack of tools for updating or managing data (e.g., CRUD operations), but this is reasonable for a read-only data query server focused on retrieval from an external API.
Average 3.7/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

Behavior2/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 mentions the data source (UNHCR API) and implies a read operation ('Get'), but doesn't cover important aspects like authentication requirements, rate limits, error handling, or whether it's a safe read operation. For a tool with 5 parameters and no annotations, this is insufficient.
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, args, returns) and uses bullet points effectively. Every sentence adds value, though the 'Returns' section could be more specific about the data format rather than just repeating 'RSD application data from UNHCR API.'
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, but has an output schema, the description is moderately complete. The parameter documentation is excellent, but behavioral aspects are under-specified. The output schema existence means the description doesn't need to detail return values, but other behavioral context is missing for a tool of this complexity.
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?
The description provides excellent parameter semantics that fully compensate for the 0% schema description coverage. For each of the 5 parameters, it explains: 1) what they filter (coo=country of origin, coa=country of asylum, year=year), 2) format requirements (ISO3 codes, comma-separated for multiple values), 3) defaults (year defaults to 2025), and 4) usage context (coo_all for analyzing origin countries, coa_all for analyzing asylum countries). 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.
Purpose4/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 RSD application data from UNHCR.' It specifies the verb ('Get'), resource ('RSD application data'), and source ('UNHCR'). However, it doesn't explicitly differentiate this tool from its siblings (like get_rsd_decisions), which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings (get_demographics_data, get_population_data, get_rsd_decisions, get_solutions). It only documents parameters without explaining the tool's specific use case or how it differs from related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the tool retrieves data from the UNHCR API, implying a read-only operation, but doesn't mention rate limits, authentication requirements, error handling, or data freshness. For a data-fetching tool with zero annotation coverage, this leaves significant gaps in understanding its operational behavior.
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 appropriately sized with two main sections: a purpose statement and parameter explanations. The Args/Returns structure is clear, though the purpose sentence could be slightly more front-loaded. No redundant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with 0% schema coverage and no annotations, the description does an excellent job explaining parameter semantics. The presence of an output schema means return values don't need explanation. However, for a data retrieval tool, additional context about data sources, update frequency, or limitations would enhance completeness.
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 description coverage is 0%, so the description must fully compensate. It provides clear explanations for all 5 parameters: coo and coa as ISO3 code filters (with comma-separated multiple values), year with default and format, and coo_all/coa_all with specific use cases for breakdown analysis. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves UNHCR durable solutions figures with specific categories listed (refugee returnees, resettlement, naturalisation, returned IDPs). It uses a specific verb ('Get') and identifies the resource, though it doesn't explicitly differentiate from sibling tools like get_population_data or get_demographics_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the sibling tools (get_demographics_data, get_population_data, get_rsd_applications, get_rsd_decisions). The description mentions analyzing breakdowns by nationality or country with coo_all/coa_all parameters, but this is parameter semantics rather than usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the data source ('UNHCR API') and that breakdowns are available 'when available,' which adds some context. However, it lacks critical behavioral details such as rate limits, authentication requirements, error handling, or whether this is a read-only operation (implied by 'Get' but not explicit).
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 a purpose statement followed by 'Args:' and 'Returns:' sections. It's appropriately sized with no redundant sentences, though the parameter explanations are detailed, which is necessary given the lack of schema descriptions. It could be slightly more front-loaded with a clearer distinction from siblings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no annotations, but with an output schema), the description is mostly complete. It covers all parameters thoroughly and mentions the data source. The output schema exists, so the description doesn't need to detail return values. However, it lacks some behavioral context like error cases or performance considerations.
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 clear semantics for all 6 parameters. Each parameter is explained with purpose, format (e.g., 'ISO3 code'), default values (e.g., 'defaults to 2025'), and usage context (e.g., 'Set to True when breaking down results by ORIGIN country'). This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 forcibly displaced populations demographics data from UNHCR' with specific mention of 'breakdown by age and sex when available.' This provides a specific verb ('Get') and resource ('demographics data'), though it doesn't explicitly differentiate from sibling tools like 'get_population_data' beyond mentioning demographics breakdown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance through parameter explanations (e.g., 'Use for questions about forcibly displaced populations FROM a specific country'), but it doesn't explicitly state when to use this tool versus alternatives like 'get_population_data' or other siblings. The guidance is helpful but not comprehensive for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions the data source ('UNHCR API') but lacks critical details such as rate limits, authentication requirements, error handling, or whether this is a read-only operation. The description does not contradict annotations, but it is insufficient for a tool with no annotation coverage.
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 a purpose statement followed by parameter explanations and a returns section. It is appropriately sized, though the parameter explanations could be slightly more concise. Every sentence adds value, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no annotations) and the presence of an output schema (which handles return values), the description is mostly complete. It covers all parameters semantically and states the data source. However, it lacks behavioral context like rate limits or authentication, which is a gap despite the output schema.
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 description coverage is 0%, so the description must compensate fully. It provides clear semantic explanations for all 5 parameters, including ISO3 code formats, comma-separated lists for multiple values, default values (year defaults to 2025), and the purpose of boolean flags (coo_all for nationality breakdown, coa_all for country breakdown). This adds significant 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 verb ('Get') and resource ('Refugee Status Determination (RSD) decision data from UNHCR'), making the purpose specific and unambiguous. It distinguishes this tool from siblings like 'get_rsd_applications' by focusing on decisions rather than applications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through parameter explanations (e.g., 'when analyzing decisions breakdown BY NATIONALITY'), but it does not explicitly state when to use this tool versus alternatives like 'get_population_data' or 'get_solutions'. No clear exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that data comes from 'UNHCR API' and describes the tool's purpose, but lacks details on behavioral traits like rate limits, authentication requirements, error handling, or whether this is a read-only operation. The description doesn't contradict annotations (none exist), but provides only basic operational context.
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 appropriately sized and well-structured with clear sections (purpose, args, returns). Every sentence adds value, though the parameter explanations could be slightly more concise. The front-loaded purpose statement immediately clarifies the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with 0% schema coverage and no annotations, the description does an excellent job explaining parameter semantics. The presence of an output schema means the description doesn't need to detail return values. However, for a data retrieval tool with no annotations, additional context about data freshness, limitations, or API constraints would improve completeness.
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 description coverage is 0%, so the description must compensate fully. It provides detailed semantic explanations for all 5 parameters: coo ('Country of origin'), coa ('Country of asylum'), year ('Year to filter by'), coo_all ('breaking down results by ORIGIN country'), and coa_all ('breaking down results by ASYLUM country'). Each parameter's purpose and usage context is clearly explained beyond what the bare schema 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 specific action ('Get forcibly displaced populations data') and resource ('from UNHCR'), explicitly listing the types of populations covered (refugees, asylum seekers, stateless persons). It distinguishes this tool from siblings like get_demographics_data or get_rsd_applications by focusing on population data rather than demographics or RSD processes.
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 provides clear context for when to use specific parameters (e.g., 'Use for questions about refugees FROM a specific country' for coo), which implicitly guides usage. However, it doesn't explicitly state when to use this tool versus sibling tools like get_demographics_data or provide explicit exclusions or alternatives.
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:

[![mcp_unhcr MCP server](https://glama.ai/mcp/servers/rvibek/mcp_unhcr/badges/card.svg)](https://glama.ai/mcp/servers/rvibek/mcp_unhcr)

Score Badge

Copy to your README.md:

[![mcp_unhcr MCP server](https://glama.ai/mcp/servers/rvibek/mcp_unhcr/badges/score.svg)](https://glama.ai/mcp/servers/rvibek/mcp_unhcr)

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/rvibek/mcp_unhcr'

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