Skip to main content
Glama

unhcr-refugees-mcp-server

Query staged dataframes

unhcr_dataframe_query
Read-onlyIdempotent

Run a single-statement SELECT against the dataframes staged by the unhcr_get_* tools. Check a dataframe’s columns with unhcr_dataframe_describe first. Read-only: writes, DDL, DROP, COPY, PRAGMA, ATTACH, external-file functions, and system catalogs (information_schema, pg_catalog, sqlite_master, duckdb_*) are rejected. Optional register_as saves the result as a new dataframe with a fresh TTL. Recompute rates from summed counts rather than averaging rate columns.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sqlYesOne DuckDB SELECT against df_XXXXX_XXXXX tables, at most 20,000 characters — joins, aggregates, window functions, and CTEs work. SUM and COUNT results come back as JSON strings (BIGINT); CAST(… AS DOUBLE) for inline arithmetic. Staged tables add origin/asylum UNHCR and UN region columns for regional GROUP BY.
previewNoRows to return inline when that should be fewer than the query materializes, e.g. a small sample while register_as keeps the whole result; a value above row_limit is treated as row_limit. Omit to return every row up to row_limit.
row_limitNoMost rows the query materializes (1–10000, default 1000). When more match, row_count_capped is true; use register_as to keep the full result.
register_asNoSave the result as a new dataframe under this name (df_ plus two groups of 5 uppercase letters or digits, e.g. df_ABCDE_12345) with a fresh TTL, to chain analyses. The name must not already be staged. The saved rows count toward the 1,000,000-row staging budget: the oldest other dataframes are evicted to make room, and a result larger than the budget is not saved.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
capNoThe cap that bound: preview when lower than row_limit, otherwise row_limit.
rowsNoResult rows, one object per row keyed by column name, bounded by preview and row_limit. BIGINT values (SUM, COUNT) arrive as strings.
errorNoPresent when the call failed. Absent on success.
shownNoRows returned inline.
noticeNoGuidance when the query returned no rows or rows were withheld.
columnsNoColumn names in projection order.
evictedNoOlder dataframes dropped, oldest first, to keep the staged total within the 1,000,000-row budget once register_as saved this result; they can no longer be queried. Present only when any were evicted.
row_countNoRows the query produced, up to row_limit. When row_count_capped is true this is the cap, not the full size.
truncatedNoTrue when rows were withheld by a cap.
expires_atNoISO 8601 expiry of the new dataframe, when register_as was set.
attributionNoAttribution UNHCR requires when these figures are reused.
registered_asNoThe new dataframe, when register_as was set.
row_count_cappedNoTrue when more rows matched than row_limit allowed through.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld, but the description goes well beyond them by enumerating exactly what is rejected (writes, DDL, DROP, COPY, PRAGMA, ATTACH, external-file functions, system catalogs) and by disclosing the eviction/TTL/staging-budget side effects of register_as. That is the kind of behavioral context an agent cannot infer from readOnlyHint=true.

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?

Front-loaded with the core action, then constraints, then the optional register_as behavior and the rate-column caveat. Every sentence carries information, though the denial list and budget details make it denser than strictly needed for scanning.

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?

An output schema exists, so return-shape explanation is unnecessary; the description covers the remaining gaps an agent needs — read-only enforcement, staging budget, eviction, TTL, and the recommended sequencing with unhcr_dataframe_describe.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3; the sql/preview/row_limit semantics are already fully spelled out in the schema. The description restates register_as's TTL behavior but adds no format, unit, or edge-case detail beyond what the 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?

States a precise verb and resource ('Run a single-statement SELECT against the dataframes staged by the unhcr_get_* tools'), and distinguishes itself from the sibling fetchers and from unhcr_dataframe_describe by naming both roles. An agent can tell this is the query layer over staged data without opening a schema.

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?

Gives explicit prerequisites and routing: check a dataframe's columns with unhcr_dataframe_describe first, and use register_as to chain analyses. It also names the correct analytical practice for rate columns ('recompute rates from summed counts rather than averaging rate columns'), which is a when-to-do-what instruction, not just a description.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.