Skip to main content
Glama

List Dataflows

list_dataflows
Read-onlyIdempotent

Browse or keyword-search UNICEF's datasets (dataflows). UNICEF Data covers child health, nutrition, education, child protection, child mortality, child poverty, immunization, water/sanitation/hygiene (WASH) and the child-related SDGs. Each result has an id (the dataflowId you pass to dataflow_structure / get_data), a version, and an English name. There are ~70 datasets; pass query to filter. Example: list_dataflows({ query: "mortality" }) or list_dataflows({ query: "nutrition" }).

Input Schema

NameRequiredDescriptionDefault
limitNoMax results to return (default 50).
queryNoCase-insensitive substring filter on dataset id or name, e.g. "mortality", "education", "immunization".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "query": "mortality"
      +  },
      +  {
      +    "limit": 10,
      +    "query": "nutrition"
      +  }
      +]
  2. First observed

TDQS

A4.3/5.0
Behavior3/5

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds that results have id, version, name, and there are ~70 datasets, but doesn't add significant behavioral traits beyond annotations.

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?

Two well-structured sentences with examples, front-loaded with purpose, no wasted words.

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?

Given no output schema, description mentions result fields (id, version, name), scope (UNICEF, ~70 datasets), and connects to sibling tools, making it complete for a listing tool.

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?

Schema coverage is 100%, baseline 3. Description adds usage examples and explains query as case-insensitive substring filter on id or name, also mentions default limit 50, adding value beyond 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 tool is for browsing or keyword-searching UNICEF datasets (dataflows). It distinguishes from sibling tools by mentioning the 'id' is passed to dataflow_structure/get_data.

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 with examples (passing query like 'mortality' or 'nutrition'), mentions ~70 datasets, and implies filtering. It lacks explicit when-not-to-use, but the examples and context are clear.

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.