Skip to main content
Glama
paulvercoustre

UNDP Open Data MCP Server

List UNDP approaches and markers

undp_list_approaches

List UNDP policy markers such as gender and capacity development, returning marker IDs to filter project searches by approach.

Instructions

List 'Our Approaches' — the policy markers UNDP tags projects with (gender, capacity development, and similar). The marker types and ids returned here feed the marker_type / marker_id filters on undp_search_projects.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
yearNoFour-digit year.
operating_unitNoOperating unit iso3.
include_top_donorsNoInclude top donors and recipients per marker.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4/5.0
Behavior3/5

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

There are no annotations, so the description carries the full burden. 'List' implies a read-only operation and the description reveals that the output includes marker types and ids, but it doesn't state output shape, default behavior when optional filters are omitted, or whether include_top_donors changes the result set. Adequate but with clear gaps.

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 focused sentences with no filler. The first sentence defines the resource and gives examples; the second sentence is front-loaded with the downstream use.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple optional-filter list tool, the essential information is present: what it lists, what the output contains, and how the output is consumed. With no output schema, a brief note on the default result set or response format would make it fully complete, but the current context is sufficient for correct invocation.

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 parameters are already documented by the schema. The description adds a helpful connection to downstream filters but does not add meaning to the individual parameters 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?

The description uses a specific verb and resource ('List Our Approaches — policy markers'), gives examples ('gender, capacity development, and similar'), and connects the result to marker_type/marker_id filters on undp_search_projects. This clearly separates it from sibling list tools for operating units, SDGs, etc.

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?

It explicitly tells the agent that the returned marker types and ids are intended to feed the marker filters on undp_search_projects, giving a concrete when-to-use context. It doesn't explicitly enumerate alternatives to avoid, but this is not necessary given the clear downstream purpose.

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