Loading ToolBench
MCP server for IFRC GO Admin API access to humanitarian data
The server defines 30 tools with consistent naming (verb_noun pattern) and basic parameter schemas. However, descriptions are brief and generic, parameter descriptions lack depth, and there is no documented output schema. Most tools accept limit/offset pagination but lack context about what fields are returned. Tools are read-only (safe), but descriptions do not explain WHEN to use each tool or how they differ from similar tools (e.g., get_emergencies vs get_ongoing_drefs both retrieve disaster data). Parameter descriptions are minimal, e.g., 'The ID of the country' does not explain the format (is it numeric? ISO code?). The server uses TypeScript and the official MCP SDK, which ensures basic schema structure, but the definitions lack the polish needed for confident LLM selection.
Access humanitarian appeals for funding
Retrieve completed DREF (Disaster Relief Emergency Fund) operations
Retrieve list of countries in the IFRC system
Get detailed profile information for a specific country
Retrieve list of disaster types in the IFRC system
Get summary statistics about DREF operations
Generic, undifferentiated descriptions. Tools like 'get_completed_drefs' (34 chars), 'get_appeals' (35 chars), and 'get_countries' (30 chars) lack context about WHEN to use them and how they differ from similar tools. Descriptions must explain the key distinction (e.g., 'Completed DREFs have final disbursement and outcome data; use when analyzing past responses') vs generic 'Retrieve X'. This violates the pattern:tool-description baseline of 194 chars average and the critical rule: 'A tool description must answer: What does it do? When should the LLM call it instead of a similar tool?'
Parameter descriptions are minimal and lack context. E.g., 'The ID of the country' does not specify format (numeric ID, ISO code, string?) or how to obtain it. The rubric requires: 'Write descriptions as if prompt-engineering. State WHAT the tool does, WHEN to use it, and any prerequisites.' For 'country_id' and similar lookup parameters, the description should state: 'Country numeric ID (obtain from get_countries). Example: 123' or 'Country ISO 3166-1 alpha-2 code (e.g., US, BD)'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Query emergency events and disasters
Retrieve ERU readiness and availability status
Retrieve available ERU types with ID to label mappings
Retrieve Emergency Response Units (ERUs) from the IFRC system
Retrieve Emergency Response Units deployed to a specific country
Retrieve Emergency Response Units filtered by type
Retrieve field reports from the IFRC system
Retrieve rapid situation updates from the IFRC system
Retrieve flash updates for a specific country
Get currently active DREF operations
Retrieve emergency operations for a specific country
Retrieve personnel deployed to a specific country
Retrieve personnel filtered by deployment type
Retrieve personnel deployment information
Retrieve projects from the IFRC system
Retrieve projects for a specific country
Retrieve list of IFRC regions
Retrieve situation reports from the IFRC system
Retrieve situation reports for a specific country
Retrieve surge deployment alerts from the IFRC system
Find DREF operations by country ISO code
Search DREF operations by disaster type (flood, earthquake, cyclone, etc.)
Search field reports for a specific country
Search emergency operations by date range
No documented output schema. The code defines TypeScript interfaces (DrefOperation, Emergency, Appeal, APIResponse) but these are not exposed in the tool definitions. LLMs cannot determine what fields are returned, forcing them to guess. The rubric states: 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls and extract the right data.' Add outputSchema to each tool with fields like 'id', 'title', 'status', 'amount_requested', etc.
No parameter constraints for disaster types, personnel types, or ERU types. The parameter 'disaster_type' in search_drefs_by_disaster_type accepts free-form strings with only an informal example ('flood, earthquake, cyclone, drought'). Per the rubric: 'When a parameter accepts one of a known set of values, declare it as an enum. Free-form strings invite hallucinated values.' Either expose an enum with valid disaster types via a tool (get_disaster_types exists but is separate), or add enum constraint to the parameter. Same for 'type' in get_personnel_by_type and 'eru_type' in get_erus_by_type.
Date parameters lack format specification. 'search_operations_by_date_range' expects 'start_date' and 'end_date' but does not specify format (ISO 8601? Unix timestamp? Locale-specific?). Per the rubric: 'Describe the expected format, range, and allowed values directly in the parameter description.' Add: 'Date in ISO 8601 format (YYYY-MM-DD), e.g., 2024-01-15'.
No error handling guidance. Tools do not specify what errors can occur and how to recover. E.g., if 'country_id' is invalid, does the API return 404 or 400? What should the LLM do? Per the rubric: 'Error responses must tell the LLM what to do next.' Add error handling documentation or implement try-catch with actionable error messages like 'Country not found. Try get_countries() to find valid IDs.'
Inconsistent tool granularity for date ranges. 'search_operations_by_date_range' requires BOTH start_date and end_date, with no default. Per the rubric: 'Reduce required parameters by providing smart defaults.' Either provide defaults (e.g., start_date defaults to 30 days ago, end_date to today) or make one optional. This reduces friction for simple queries like 'operations in the last month'.