Skip to main content
Glama
xmpuspus

ph-civic-data-mcp

by xmpuspus

Search HDX for Philippine humanitarian datasets

search_hdx_datasets
Read-onlyIdempotent

Search for Philippine humanitarian datasets by keyword, returning recently modified matches with licenses and up to 20 resources per dataset.

Instructions

Search HDX for Philippine humanitarian datasets by keyword.

Calls the CKAN package_search action filtered to the Philippines country group and returns matching datasets, most recently modified first, each with its own license and up to 20 resources. Examples:

search_hdx_datasets("flood") datasets matching "flood" search_hdx_datasets("food prices", rows=5) 5 most recently modified matches

On failure: an empty query, a query over 200 characters, a query with a control character, or a rows value outside 1 to 50 gives validation_error true and data_status "invalid_request". An unreachable HDX API gives upstream_error true and data_status "unavailable". A response whose success field is not true, or whose result.results field is not a list, gives upstream_error true and data_status "indeterminate". Datasets sent beside a missing or non-integer count also give data_status "indeterminate", with the parsed datasets kept and never cached: CKAN always sends a real count, so a bad one is drift even when the datasets read fine. Zero datasets on a clean query with a real integer count gives data_status "empty", never a failure, and still caches. Every dataset carries its own license_id: read it before you reuse a resource.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rowsNoNumber of datasets to return, 1 to 50 (default 10).
queryYesFree-text search term, 1 to 200 printable characters, for example "flood", "food security", "displacement".

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.0

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes far beyond annotations by detailing all error conditions (validation_error, upstream_error, indeterminate), data_status values (invalid_request, unavailable, empty), caching behavior, and edge-case handling (e.g., zero results with a real count). This is a model of transparent behavior disclosure.

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?

The description is well-structured with paragraphs covering purpose, examples, and failure modes. It is dense with useful information without being redundant. Every sentence contributes essential details, and the formatting makes it easy to scan. Despite its length, it is appropriately concise given the number of edge cases it addresses.

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?

The description covers all relevant aspects needed to correctly invoke the tool and interpret results: source API, country filter, sorting, output fields (license_id), error handling, and caching. It even includes warnings about consent (reading license_id before reuse). This provides comprehensive contextual information beyond the schema and annotations.

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 already covers the parameters and their constraints (query length, rows range). The description adds value by providing usage examples, explaining the default sorting, and clarifying the effect of invalid values (e.g., rows outside 1-50). Since schema coverage is 100%, the baseline is 3, and the description gives extra context, earning a 4.

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 HDX for Philippine humanitarian datasets by keyword. It also explains the underlying CKAN action and provides concrete examples, making it unambiguous and distinct from sibling tools like search_procurement or search_psa_catalog.

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 gives explicit usage examples and details on query and rows parameters, but it does not explicitly contrast with alternatives. However, the tool's specific scope (HDX datasets) and the provided examples make it obvious when to use it, so it falls just short of a 5 due to lack of explicit 'use this instead of X' guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.