Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ifrc-go-admin-mcp-server Show me recent earthquake-related DREF operations"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides access to the International Federation of Red Cross and Red Crescent Societies (IFRC) GO Admin API for disaster relief emergency fund (DREF) data.
DREF Operations: Access completed and ongoing disaster relief emergency fund operations
Appeals: Query humanitarian funding appeals
Emergencies: Get emergency event and disaster data
Search & Filter: Search by country, disaster type, and other criteria
Caching: Built-in response caching to reduce API load
Pagination: Handle large datasets efficiently
Related MCP server: Dify Management MCP
Node.js 18.0.0 or higher
npm or yarn package manager
MCP-compatible client (Claude Desktop, etc.)
npm installnpm run buildnpm startAdd to your Claude Desktop configuration file (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"ifrc-go-admin": {
"command": "node",
"args": ["/path/to/your/ifrc-go-admin-mcp-server/dist/index.js"]
}
}
}get_completed_drefs: Retrieve completed DREF operations
get_ongoing_drefs: Get currently active DREF operations
get_appeals: Access humanitarian appeals for funding
get_emergencies: Query emergency events and disasters
search_drefs_by_country: Find DREF operations by country ISO code
search_drefs_by_disaster_type: Search by disaster type (flood, earthquake, etc.)
get_dref_statistics: Get summary statistics about DREF operations
"Show me recent earthquake-related DREF operations"
"What are the ongoing emergency appeals in Bangladesh?"
"Compare funding amounts for cyclone vs flood disasters this year"
"List all completed DREF operations in West Africa"
npm run build - Compile TypeScript to JavaScript
npm run dev - Watch mode for development
npm start - Start the production server
npm test - Test server startup
Before implementing, explore the API endpoints:
# Test basic connectivity
curl "https://goadmin.ifrc.org/api/v2/dref/?limit=1"
# Check completed DREFs
curl "https://goadmin.ifrc.org/api/v2/completed_dref/?limit=5"
# Search by country
curl "https://goadmin.ifrc.org/api/v2/dref/?country__iso=BD"Update Types: Add TypeScript interfaces for new data structures
Extend API Client: Add methods to IFRCAPIClient class
Register Tools: Add tool definitions in ListToolsRequestSchema handler
Implement Handlers: Add case in CallToolRequestSchema handler
Following IFRC API documentation guidelines:
Default limit is 50 records per page
Maximum limit is 1000 records per page
Stop pagination when returned records < limit
Check for empty array [] to confirm no more data
Use offset-based pagination with limit/offset parameters
The server includes basic caching (5-minute timeout) to be respectful of IFRC's infrastructure. For production use:
Implement exponential backoff for retries
Add request rate limiting
Monitor API usage and respect any documented limits
Consider using webhooks for real-time updates if available
The server includes comprehensive error handling:
HTTP errors from the API
Invalid parameters
Network timeouts
Cache management
Currently, the IFRC GO Admin API appears to be publicly accessible. If authentication is required:
Add API key management to the IFRCAPIClient class
Include authentication headers in requests
Handle authentication errors appropriately
{
"id": 12345,
"title": "Bangladesh: Cyclone Mocha",
"country": "Bangladesh",
"disaster_type": "Cyclone",
"amount_requested": 500000,
"amount_funded": 500000,
"disaster_start_date": "2023-05-14",
"status": "completed"
}{
"id": 67890,
"name": "Morocco Earthquake September 2023",
"countries": ["Morocco"],
"disaster_type": "Earthquake",
"num_affected": 300000,
"disaster_start_date": "2023-09-08"
}ifrc-go-admin-mcp-server/
├── src/
│ └── index.ts # Main MCP server implementation
├── dist/ # Compiled JavaScript output
├── package.json # Project configuration
├── tsconfig.json # TypeScript configuration
└── README.md # This fileFork the repository
Create a feature branch
Make your changes
Add tests for new functionality
Submit a pull request
This server provides access to sensitive humanitarian data. Please:
Use responsibly and respect the humanitarian context
Don't overwhelm the IFRC API with excessive requests
Consider data privacy when analyzing beneficiary information
Contribute improvements back to the humanitarian community
For issues related to:
MCP Server: Open an issue in this repository
IFRC GO API: Contact IFRC technical support
Data Questions: Refer to IFRC GO documentation
MIT License - See LICENSE file for details.
International Federation of Red Cross and Red Crescent Societies
Model Context Protocol development team
Open source humanitarian technology community
Access humanitarian appeals for funding
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 50) | |
| offset | No | Number of results to skip (default: 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only states that the tool accesses appeals, but does not mention whether it returns a list, how pagination works, or any potential side effects (as a read operation, none are expected, but this is not explicitly stated).
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 brief, front-loaded single sentence with no wasted words. It could arguably benefit from more detail, but for a simple read tool it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema (2 optional params with defaults) and no output schema, the description is minimally sufficient. However, it lacks context about what constitutes an 'appeal' and how this tool relates to the sibling DREF tools, leaving some ambiguity for an agent.
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%, with limit and offset already documented. The description adds a little context by indicating the purpose is funding-related, but it does not explain the parameters further. The baseline of 3 applies because the schema does the heavy lifting.
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 clear verb 'Access' and specifies the resource 'humanitarian appeals for funding', which distinguishes it from DREF-specific sibling tools. However, 'Access' is somewhat generic; 'list' or 'get' would be more explicit, so it's not a perfect 5.
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?
No guidance is given on when to use this tool versus alternatives. While the name implies it is for appeals rather than DREFs or emergencies, the description does not explicitly state this or mention any exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve completed DREF (Disaster Relief Emergency Fund) operations
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 50) | |
| offset | No | Number of results to skip (default: 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the action and scope ('completed DREF operations') but does not disclose return format, pagination behavior, authorization requirements, or what 'completed' entails. With no annotations available, the description carries the full burden and falls short.
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 is front-loaded and without fluff. It earns a high score for conciseness, though it could be slightly more informative without becoming verbose.
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 with two parameters and no output schema, but the description does not explain the return value structure or any additional context about completed DREFs. Given the lack of annotations and output schema, the description is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both limit and offset having descriptions. The tool description adds no additional meaning beyond the schema, so 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?
The description clearly states the tool's purpose with a specific verb ('Retrieve') and resource ('completed DREF operations'). This distinguishes it from sibling tools like get_ongoing_drefs and search_drefs_by_country, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention that get_ongoing_drefs handles ongoing operations or that search_drefs_by_country filters by country, leaving the agent without directional context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get summary statistics about DREF operations
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 only states 'Get summary statistics' without disclosing what statistics are included, whether the operation is read-only, or any side effects. The tool name and description imply a read operation but offer no specifics about the data source or aggregation method.
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, direct sentence that fully communicates the high-level purpose without unnecessary words. It is front-loaded with the verb 'Get' and the object 'summary statistics about DREF operations,' which is exactly as concise as needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description is the only source of context. It communicates the basic function but remains vague about what specific statistics are returned. The tool is simple enough that this may suffice, but a slightly more detailed description would improve completeness.
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, which is the baseline for this dimension. There is no additional semantic meaning needed since there is nothing to specify. The description adds no parameter details because none exist; the schema coverage is effectively complete.
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 identifies the tool's purpose: retrieving summary statistics about DREF operations. It uses a specific verb and resource, and it is distinguishable from sibling tools that list specific DREF subsets (completed/ongoing) or search by criteria. However, it does not explicitly contrast with siblings.
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?
There is no guidance on when to use this tool versus the sibling tools. The description does not mention alternatives or provide context such as 'use this when you need aggregated data instead of individual operation lists.' The absence of any usage direction leaves the agent to infer it from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query emergency events and disasters
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 50) | |
| offset | No | Number of results to skip (default: 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Query' implies a read operation, but it does not disclose pagination behavior, return format, authentication needs, or any other operational details. The limit/offset parameters are present in the schema but not explained in the description.
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, concise sentence with no filler or repetition. It efficiently conveys the core purpose without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional params, no output schema), the description covers the basic purpose adequately. However, the lack of usage differentiation from sibling DREF tools and minimal behavioral context leaves room for improvement, preventing a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the two parameters (limit, offset), so the schema already documents their meaning. The description adds no further parameter semantics, but the high coverage warrants the baseline score of 3.
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 queries emergency events and disasters, with a specific verb and resource. It distinguishes from sibling tools which are DREF-specific (e.g., get_completed_drefs, get_appeals), though it does not explicitly contrast itself with them.
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?
No guidance is provided on when to use this tool versus alternatives. The sibling tools are DREF-specific, but the description does not mention any distinction or selection criteria, leaving the agent without explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get currently active DREF operations
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 50) | |
| offset | No | Number of results to skip (default: 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the tool gets active DREF operations and lacks details on pagination, sorting, auth, or return structure, even though the schema hints at limit/offset behavior.
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, front-loaded sentence with no wasted words. It effectively communicates the core operation.
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?
There is no output schema, yet the description does not explain what the tool returns (e.g., fields, format, pagination behavior). For a list endpoint, this incomplete information leaves the agent without sufficient context.
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 input schema already fully documents both parameters (limit and offset) with descriptions and defaults, so the description adds no extra meaning. Baseline of 3 applies due to 100% schema coverage.
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 retrieves currently active DREF operations, using a specific verb ('Get') and resource ('DREF operations'). The word 'active' distinguishes it from siblings like get_completed_drefs.
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?
No guidance is provided about when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or refer to sibling tools such as get_completed_drefs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find DREF operations by country ISO code
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 50) | |
| country_iso | Yes | ISO country code (e.g., BD for Bangladesh, US for United States) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the basic action and filter criterion, but does not disclose behavior such as result ordering, pagination (despite limit parameter), whether all DREF statuses are included, or any authentication requirements. This is a minimal behavioral disclosure.
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 with no filler. It is appropriately sized for a simple search tool and front-loads the key action and filter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only 2 parameters and no output schema, so complexity is low. However, the description does not clarify whether this search returns all DREF statuses or only a subset, which could be ambiguous given sibling tools for completed/ongoing. It is minimally complete but leaves some contextual gaps.
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 parameters are already well-documented. The description adds no new meaning beyond restating the country_iso filter (by country ISO code). It does not clarify behavior of the limit parameter beyond schema defaults, so baseline 3 is 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 clearly states the tool finds DREF operations by country ISO code, using a specific verb and resource. It distinguishes from siblings like search_drefs_by_disaster_type (different filter) and get_completed/ongoing_drefs (status-based).
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 usage for country-based searches but does not explicitly mention when to use this tool versus alternatives like search_drefs_by_disaster_type or get_ongoing_drefs. No exclusions or alternative tools are named, leaving the user to infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search DREF operations by disaster type (flood, earthquake, cyclone, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 50) | |
| disaster_type | Yes | Disaster type to search for (e.g., flood, earthquake, cyclone, drought) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Search DREF operations by disaster type' without explaining how the search behaves (exact match, partial, case sensitivity), what data is returned, or any side effects. The minimal wording gives no insight into the tool's behavior.
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, front-loaded sentence that immediately states the action and focus. It is appropriately concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 2 parameters and no output schema, but the description does not explain what the search returns (e.g., a list of DREF operations, their details, or any pagination behavior). While the purpose is clear, the lack of return-value context makes it slightly incomplete for an agent invoking the tool.
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% — both 'limit' and 'disaster_type' have descriptions in the schema. The description adds only a few examples of disaster types ('flood, earthquake, cyclone, etc.'), which is redundant with the schema's examples. It does not add meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search', the resource 'DREF operations', and the specific filter 'by disaster type'. It distinguishes from siblings like search_drefs_by_country and get_completed_drefs by indicating a type-based search.
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 usage (search when you need DREF ops by disaster type) but does not explicitly state when to use this tool vs alternatives like search_drefs_by_country or get_ongoing_drefs. No exclusions or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct resource or filter: completed vs ongoing DREFs, appeals, emergencies, country-specific and disaster-type-specific DREF searches, and aggregate statistics. There is no overlap or risk of misselection.
All tools follow a clear verb_noun pattern with 'get_' for direct retrieval and 'search_' for filtered queries, followed by the target object. The naming is predictable and uniform.
Seven tools is a well-scoped set for a read-only IFRC query server, covering core DREF operations, appeals, emergencies, and search/statistics without unnecessary bloat.
The surface covers listing, searching, and statistics for DREF operations, plus appeals and emergencies. Minor gaps exist (e.g., no get single DREF by ID, no appeals search), but the main read workflows are complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage Chili Piper scheduling links, meetings, routing rules, and teams. Admin only. Experimental.
Public tools to understand Dynamik, discover datasets, and connect account-scoped capabilities.
Wrapper for the official Projuris ADV REST API (legal practice management): cases, people (clients/p
Manage products, EU Digital Product Passports, operator parties, and GS1 EPCIS supply-chain events.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jmesplana/ifrc-go-admin-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
