A
licenseNot graded
qualityD
maintenanceA Model Context Protocol (MCP) server that gives Claude access to your WHOOP biometric data — recovery, sleep, strain, and workouts.
47
MIT
ghed-mcp
by Decilion
Provides tools for accessing and querying the World Health Organization's Global Health Expenditure Database (GHED), enabling retrieval of health expenditure indicators, country profiles, trend analyses, and research-ready panel data across countries, regions, and income groups.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@ghed-mcpCompare health expenditure trends in Brazil and Argentina from 2010 to 2020"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
ghed-mcp
A Model Context Protocol (MCP) server that gives AI assistants like Claude direct access to the World Health Organization's Global Health Expenditure Database (GHED) — purpose-built for comparative health-financing research.
What it does
ghed-mcp wraps the WHO GHED all-data workbook in a small set of task-shaped MCP tools so an AI assistant can answer questions like:
"Build me a health-financing profile for Colombia."
"Compare out-of-pocket burden across LAC countries since 2000."
"What's the government priority gradient by World Bank income group?"
"Decompose Peru's current health expenditure by financing scheme for 2023."
Country names, ISO3 codes, WHO region codes (AFR, AMR, EMR, EUR, SEAR, WPR) and World Bank income labels (Low, Lower-middle, Upper-middle, High) are all accepted, with aliases — region="Americas" and income="UMIC" work the same as the canonical values. Collective aliases match the academic global-health convention: income="LMIC" expands to the union of Low + Lower-middle + Upper-middle (not the World Bank's narrower lower-middle-only definition), and income="MIC" expands to Lower-middle + Upper-middle. CSV export is built in.
Related MCP server: WealthGuard MCP
Why this exists
Raw access to GHED is technically possible from any LLM — but in practice it's painful: there is no stable documented API, the all-data workbook contains over 4,000 variables across the SHA 2011 accounting framework, indicator codes are cryptic (gghed_che is "domestic general government health expenditure as a share of current health expenditure"), and not every variable is additive (you can't sum percentages or PPP values as accounting identities). ghed-mcp collapses the friction:
Discovers the latest GHED all data workbook automatically from WHO's Documentation Centre.
Caches the XLSX locally and builds a derived SQLite database for fast queries.
Steers the model toward headline
INDICATORSfirst, with detailed SHA series available on demand.Knows the additive hierarchies (CHE = HF1+HF2+HF3+HF4+HFnec, GGHE-D = FS1+FS3, …) and validates breakdowns with a sum-vs-parent balance check.
The tool design reflects how health-financing researchers actually work: country profiles, regional and income-group benchmarks, financing-mix decompositions, and metadata for citation.
Install
Requires Python 3.11 or newer. Check yours with python3 --version — on macOS, python3 from system Python is often 3.9, in which case install a current Python via brew install python (or pyenv) before continuing.
git clone https://github.com/Decilion/ghed-mcp.git
cd ghed-mcp
python3 -m venv .venv
source .venv/bin/activate
pip install -e .Then register the server with your MCP client.
Claude Code:
claude mcp add ghed /absolute/path/to/.venv/bin/ghed-mcpClaude Desktop: add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"ghed": {
"command": "/absolute/path/to/.venv/bin/ghed-mcp"
}
}
}Codex CLI:
codex mcp add ghed -- /absolute/path/to/.venv/bin/ghed-mcpThis writes an entry to ~/.codex/config.toml. List or remove with codex mcp list / codex mcp remove ghed.
Other MCP-compatible clients (Cursor, Cline, Continue, etc.): point them at the ghed-mcp console script in your venv. The MCP protocol is the same across clients — only the registration UI differs.
Restart your client. The ghed server should appear with all tools, the ghed://indicator/{indicator_code}, ghed://methodology, ghed://topics/{topic_id}, and ghed://research-use-cases/{use_case} resources, and the compare_health_expenditure prompt available.
The first call downloads the GHED all-data workbook (~30 MB) and builds a derived SQLite cache under ~/.cache/ghed-mcp/. This takes 2–3 minutes on a fresh laptop; subsequent calls are instant. Set GHED_MCP_CACHE_DIR to relocate.
Tool reference
Tool signatures show the canonical parameter names — the server rejects unknown kwargs (Pydantic extra="forbid"), so getting the names right matters. In particular: country is singular, countries is the list form, year filters are year_start / year_end (not year_from / year_to).
Cache and version
Tool | Signature | Purpose |
|
| Download or re-download the public GHED workbook and rebuild SQLite |
|
| Workbook, SQLite cache, source document, and row counts |
|
| Compare the cached source document with the current all-data workbook metadata |
|
| Workbook version lines and cache provenance |
Methodology and discovery
Tool | Signature | Purpose |
|
| GHED variable classes, categories, cautions, and curated topics |
|
| Curated topic map for common health-expenditure questions |
|
| Literature-inspired GHED research workflows and recommended variables |
|
| Map a natural-language research question to likely GHED variables and cautions |
|
| Counts by GHED Codebook category |
|
| Paginated headline indicators only ( |
|
| Paginated full GHED codebook variables |
|
| Search headline indicators by default |
|
| Search all variables, including detailed SHA series |
|
| Codebook metadata for one variable |
Country resolution
Tool | Signature | Purpose |
|
| Countries and territories in the workbook, optionally by group |
|
| Available GHED region and income group values |
|
| Resolve a country name fragment or alias to ISO3 |
|
| Source, data-type, and estimation notes from the Metadata sheet |
|
| Latest headline health expenditure values for one country |
Data extraction
Tool | Signature | Purpose |
|
| One indicator with optional country/group/year filters |
|
| One indicator across countries, returned as tidy rows or CSV |
|
| One indicator across a country group (curated, regional, or income-based) |
|
| Group stats, coverage, top/bottom countries, and mixed-year warnings |
|
| First/latest country trends for one indicator |
|
| First/latest country trends for multiple indicators |
|
| Rank countries by absolute change, percent change, or CAGR |
Research workflows
Tool | Signature | Purpose |
|
| Availability summary for one or more variables before panel construction |
|
| Tidy long panel for multiple variables, countries, and years |
|
| Export-ready data CSV, codebook CSV, availability CSV, and README text |
Quality and accounting checks
Tool | Signature | Purpose |
|
| Known additive parent-child relationships for a variable |
|
| Classify a variable as total, component, ratio/share, amount, or context series |
|
| Country-year breakdown with child sum, shares, and balance check |
|
| Availability, metadata completeness, data-type mix, and caution flags |
Resources and prompts
Resource
ghed://indicator/{indicator_code}— readable view of one indicator's metadataResource
ghed://methodology— readable methodology guide for variable selectionResource
ghed://topics/{topic_id}— readable view of a curated topic and its indicator codesResource
ghed://research-use-cases/{use_case}— readable view of one research use casePrompt
compare_health_expenditure(countries, indicator)— guided template for cross-country health-financing analysis
Regional analysis
Both gho-mcp and ghed-mcp expose the same curated country groupings beyond what WHO and the World Bank publish as built-in dimensions. Pass country_group="LAC" (or any of the codes below) on the data tools and the server resolves to the right ISO3 list — without you having to enumerate codes by hand.
Available groups
Code | Definition | Members |
| 33 sovereign Latin American & Caribbean states (PAHO/Decilion convention) | 33 |
| World Bank's 42-economy LAC region — sovereign states plus territories (Aruba, Cayman Islands, Curaçao, Puerto Rico, etc.) | 42 |
| World Bank East Asia & Pacific (FY2026) | 38 |
| World Bank Europe & Central Asia | 58 |
| World Bank "Middle East, North Africa, Afghanistan and Pakistan" (FY2026) | 23 |
| MENA without Israel and Malta | 21 |
| World Bank North America (Bermuda, Canada, USA) | 3 |
| World Bank South Asia (FY2026 — without AFG and PAK, now in MENA) | 6 |
| World Bank Sub-Saharan Africa | 48 |
| UN Least Developed Countries | 44 |
| OECD member countries | 38 |
Aliases include natural-language ("Latin America and Caribbean", "Sub-Saharan Africa", "Least Developed Countries") and official codes (LCN, SSF, etc.). Two read-only tools — list_curated_country_groups and resolve_country_group_membership — let an assistant inspect or expand the lists at runtime.
Using country_group= on the data tools
country_group= merges (deduplicated) with any explicit countries= list and composes with region / income via AND semantics. Some illustrative calls — the first four work identically on both ghed-mcp and gho-mcp:
compare_countries(indicator_code="oops_che", country_group="LAC",
latest_only=True) # GHED
compare_countries(indicator_code="WHOSIS_000001", country_group="OECD",
year_start=2010, year_end=2023) # GHO
list_curated_country_groups() # both
resolve_country_group_membership("LAC") # both — returns 33 ISO3 codes
# ghed-mcp also exposes:
build_research_panel(indicator_codes=["che_gdp", "gghed_che"],
country_group="OECD", year_start=2000, year_end=2024)
summarize_country_group(indicator_code="ext_che", country_group="LDC",
latest_only=True)
list_countries(country_group="LAC", income="High") # LAC HICsCurated-group members are soft-resolved: ISO3 codes the underlying source doesn't publish are silently dropped (e.g. LAC_TERRITORIES includes Aruba and Curaçao, which GHED doesn't cover). User-supplied countries= are still strict-resolved, so typos still raise.
Membership cadence
The lists are static Python data baked into each package — no runtime refresh, no separate cache. Users get updates by reinstalling the package.
The LAST_VERIFIED constant in country_groups.py records when each list was last cross-checked against:
World Bank country and lending groups: https://datahelpdesk.worldbank.org/knowledgebase/articles/906519
UN Least Developed Countries: https://www.un.org/development/desa/dpad/least-developed-country-category.html
OECD members: https://www.oecd.org/about/document/list-oecd-member-countries.htm
Re-check annually. Known upcoming changes at the time of writing: Bangladesh, Lao PDR, and Nepal are scheduled to graduate from LDC status on 2026-11-24; Solomon Islands on 2027-12-13.
The same country_groups.py file lives in both ghed-mcp and gho-mcp (canonical source: ghed-mcp), so a regional analysis behaves identically against either database.
Examples
Each block below shows a natural-language prompt and a sketch of the underlying tool calls.
Country profile
"Give me a Colombia health-financing profile."
The assistant calls country_profile(country="Colombia") and returns CHE as % GDP, CHE per capita (USD), government share of CHE, OOP share of CHE, external share, GGHE-D as % GDP, and GGHE-D as % GGE — all latest year, with a mixed_reference_years warning if reference years differ.
Comparative LAC analysis
"Compare out-of-pocket burden across the Andean countries since 2000."
The assistant calls:
compare_countries(
indicator_code="oops_che",
countries=["Colombia", "Ecuador", "Peru", "Bolivia", "Venezuela"],
year_start=2000,
latest_only=False,
format="csv",
)and gets a CSV ready to drop into any spreadsheet, statistical package, or charting tool.
Income-group gradient
"What's the public health-spending priority gradient by income group in 2022?"
The assistant calls summarize_country_group("gghed_gge", income="upper middle income", year=2022) (and parallel calls for Low / Lower-middle / High), returning median, top-five, and bottom-five for each group with coverage ratios.
Accounting-identity decomposition
"Decompose Peru's CHE in 2023 by financing scheme."
The assistant calls:
explain_indicator_relationship(indicator_code="che")
build_additive_breakdown(
indicator_code="che",
country="Peru",
year=2023,
relationship_id="che_by_financing_scheme",
)and returns each child component (HF.1, HF.2, HF.3, HF.4, HF.nec) with its share of the parent and a balance check (balanced: true) confirming the sum reconciles.
From CSV output to analysis tools
compare_countries(..., format="csv") and build_research_package(...) return CSV strings under the csv, data_csv, codebook_csv, or availability_csv keys. Two common downstream paths:
To pandas — for time-series analysis or modelling:
import io, pandas as pd
# csv_text is the value of result["csv"] from compare_countries
df = pd.read_csv(io.StringIO(csv_text))
df["year"] = df["year"].astype(int)
df = df.dropna(subset=["value"]).pivot_table(
index="year", columns="country_name", values="value"
)
df.plot(title="OOP share of CHE, Andean countries")To any external tool (Excel, Google Sheets, R, Stata, Tableau, charting platforms, etc.):
with open("data.csv", "w") as f:
f.write(csv_text)The columns indicator_code, indicator_name, country_code, country_name, region, income, year, value, unit, currency are tidy-format-friendly and map cleanly into most analysis or visualization workflows. For wide-format / per-country columns, pivot first (pandas snippet above).
Advanced queries
The friendly tools cover headline indicators, country/region/income-group filtering, year ranges, and the most common additive decompositions. For everything else — detailed SHA series by function, provider, disease/condition, cross-tabs, capital, age, COVID-19 reporting items — explore the full codebook with list_variables and search_variables:
list_variables(category_1="HEALTH EXPENDITURE DATA", category_2="HEALTH CARE FUNCTIONS")
search_variables(query="diabetes", category_1="HEALTH EXPENDITURE DATA")For long-code SHA hierarchies (e.g. sha11.HC, sha11.HP, sha11.HF), use additive_hierarchy(indicator_code=...) — it returns curated codebook formulas first, then inferred direct children from the SHA long-code tree for current-NCU amount variables. Pair with build_additive_breakdown to validate any decomposition for a country-year.
Inspect what each variable actually is before pulling — explain_indicator_relationship(indicator_code) classifies it as additive_parent, component, derived_ratio_or_share, amount_series, or context_or_conversion_series and surfaces interpretation cautions.
Topics covered by topics_index
core_spending— CHE level and scale (CHE/GDP, CHE per capita USD/PPP)government_spending— GGHE-D level, share of CHE, share of GDP, fiscal priority (GGE)out_of_pocket— household burden, OOP share of CHE, OOP per capitaexternal_aid— external funding for health and donor dependenceprivate_spending— private domestic spending and voluntary prepaymentcapital— capital health expenditure (HK)primary_health_care— PHC level and share of CHEmacro_context— GDP, population, exchange rates, PPP conversion factors
research_use_cases adds literature-inspired patterns:
health_financing_transition— financing-mix change with income, time, or reformfinancial_protection_oop— OOP indicators as macro context for UHC researchgovernment_priority— government health-spending effort and priority in the public budgetdonor_dependence— external funding dependence and its trajectoryprivate_and_voluntary_insurance— private, voluntary, and prepaid arrangementsservices_providers_sha— detailed SHA series by function, provider, scheme, sourceprimary_health_care— PHC spending levels and shares
Development
pip install -e ".[dev]"
pytestTests use a synthetic GHED workbook fixture; no network access required for the standard suite.
Limitations
GHED does not expose a stable documented API. This server discovers the current all-data workbook from WHO's Documentation Centre and caches it locally; if WHO changes the directory structure or naming, the discovery logic will need a release.
First cold start downloads ~30 MB and builds a ~300 MB SQLite cache (2–3 minutes on a typical laptop). Subsequent calls reuse the cache;
refresh_cacherebuilds it.The all-data workbook contains over 4,000 variables. Detailed SHA series can be sparse for recent years; use
data_availabilityandassess_data_qualitybefore strong claims.Variant series (current NCU, constant NCU, current USD, constant USD, PPP, per-capita, %CHE, %GDP, %GGE) are not interchangeable as accounting identities.
additive_hierarchyandbuild_additive_breakdownonly validate current-NCU amount variables.Aggregate values (regional, income-group, global) are not computed by GHED; this server does not recompute them. Use
summarize_country_groupfor descriptive group statistics across reporting countries.Latest years can be preliminary — inspect Version sheet and Metadata notes via
versionandget_country_metadata.
About the WHO Global Health Expenditure Database
The WHO Global Health Expenditure Database (GHED) is the World Health Organization's central platform for internationally comparable data on health spending. It is the authoritative source for indicators on:
Levels and trends of health expenditure across 195 countries and territories, with most series running from 2000 onward
System of Health Accounts 2011 (SHA 2011) — health expenditure decomposed by financing arrangements, revenues, providers, functions, diseases and conditions, capital formation, and primary health care
Universal Health Coverage financing context — government share, out-of-pocket burden, external funding, voluntary insurance
Macro denominators and conversion variables — GDP, population, exchange rates, price indexes — to support per-capita, %GDP, constant-price, and PPP-adjusted analysis
Country-level metadata — sources, data type (Documented / Estimated / Imputed), methods of estimation, country footnotes — for transparent citation
GHED underpins WHO's Global Spending on Health annual report, Health Accounts country profiles, and the financing chapter of World Health Statistics. The data is free and openly published — through the all-data workbook this server wraps, and through the official GHED portal with its own visualizations and downloads.
This MCP server is plumbing. The data, the indicator definitions, the SHA 2011 methodological work, and the country-level data validation are all WHO's. If you use values retrieved through this server, please:
Cite WHO as the source. The
sourceblock on every data response includes the workbook path, modification time, parameters, and retrieval timestamp to make this straightforward.Visit the GHED portal for indicator metadata, methodology notes, and the official visualizations. The MCP exposes the data; the portal provides the canonical context.
Read the Global Spending on Health annual report for WHO's curated narrative analysis of what the data shows.
GHED is a public good. The most valuable contribution any user can make is to support and reference WHO's underlying data work.
Built by
Decilion — global health consulting across Latin America and the Caribbean, with an applied AI lens.
This server is one of Decilion's open-source contributions to the global health data community. It pairs naturally with gho-mcp for combined GHO + GHED workflows. If you use it in research, a brief acknowledgment is appreciated but not required.
License
MIT — see LICENSE.
Available Tools
35 toolsadditive_hierarchyBRead-only
Return known additive child relationships for a GHED variable.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| indicator_code | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true, so the description does not need to repeat those. It adds the concept of 'known' relationships, implying non-exhaustiveness, which aligns with openWorldHint. No contradictions, but little added insight 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 9 words, front-loading the key action. It is efficient, but could benefit from a brief second sentence clarifying the parameter or output scope. Nonetheless, it achieves conciseness without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with one parameter and an existing output schema, the description is minimally adequate. It misses details like error handling or data scope, but for a straightforward retrieval, it passes the bar. Improvement would add context about the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description mentions 'GHED variable' but the parameter is named 'indicator_code', with no explanation of their relationship. The agent must infer that indicator_code identifies a GHED variable. This is insufficient for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'return' and the resource 'additive child relationships for a GHED variable'. It distinguishes from siblings like 'explain_indicator_relationship' by focusing on returning existing relationships rather than explaining them. However, 'GHED' is not explained, which assumes domain knowledge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or when not to use it. This leaves the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
assess_data_qualityCRead-only
Summarize metadata, availability, and cautions for an indicator/filter.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| indicator_code | Yes | ||
| country | No | ||
| countries | No | ||
| country_group | No | ||
| region | No | ||
| income | No | ||
| year_start | No | ||
| year_end | No | ||
| top | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so no contradiction. The description adds minimal behavioral context beyond the purpose—it does not explain what 'cautions' entails or how the summary is structured. For a read-only tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with no wasted words. However, it is too brief given the tool's complexity, sacrificing necessary details for brevity. A few more sentences would improve completeness without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks context about the output (which has an output schema) and the interplay of filters. Despite having many parameters, no explanation of how they are used together is provided. The tool's complexity demands more descriptive context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The description only mentions 'indicator/filter' but does not explain any of the 9 parameters, such as geography filters or year range. This is a critical gap.
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 action ('Summarize') and the resource ('metadata, availability, and cautions for an indicator/filter'). It distinguishes itself from siblings like 'data_availability' and 'get_indicator_metadata' by combining these aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives. For instance, if only metadata is needed, 'get_indicator_metadata' might be more appropriate; if only availability, use 'data_availability'. No such context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
build_additive_breakdownBRead-only
Build and validate an additive breakdown for one country-year.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| indicator_code | Yes | ||
| country | Yes | ||
| year | Yes | ||
| relationship_id | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true, so the description's claim to 'build and validate' aligns with safe behavior. However, it does not add further details like performance implications or validation specifics.
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?
The description is a single sentence that is front-loaded and efficient. However, it is slightly vague and could benefit from a second sentence to clarify parameters or usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4 parameters, the presence of an output schema, and annotations, the description is insufficient. It does not cover parameter semantics, usage guidance, or behavioral details, leaving significant gaps for the AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 4 parameters (indicator_code, country, year, relationship_id). The phrase 'for one country-year' hints at country and year but ignores indicator_code and relationship_id completely.
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 action ('Build and validate') and the resource ('additive breakdown for one country-year'), differentiating it from sibling tools like 'additive_hierarchy' or 'build_research_package' by specifying the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'additive_hierarchy' or 'explain_indicator_relationship'. The description lacks context on prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
build_research_packageBRead-only
Build export-ready CSV data, codebook, and README text for a research extract.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| indicator_codes | Yes | ||
| countries | No | ||
| country_group | No | ||
| region | No | ||
| income | No | ||
| year_start | No | ||
| year_end | No | ||
| top | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true, so the description's mention of 'build' might imply creation, but the readOnlyHint indicates no state change. The description adds context about the output format (CSV, codebook, README) 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence covers the tool's outputs efficiently. However, it could be slightly more structured (e.g., listing outputs) without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters with zero description coverage, the description is incomplete. It does not explain parameter usage, valid combinations, or how to configure the export. The output schema exists but does not compensate for missing parameter guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 8 parameters, the description offers no parameter-level explanation. For example, it does not clarify the difference between 'countries' and 'country_group' or how 'top' limits rows. This is a significant gap.
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 produces export-ready CSV data, codebook, and README text for a research extract. This specific verb-output combination distinguishes it from sibling tools like build_additive_breakdown or build_research_panel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a researcher needs an exportable package of data and documentation, but it lacks explicit guidance on when not to use it or alternatives among many siblings (e.g., get_indicator_data for raw data).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
build_research_panelARead-only
Build a tidy long panel for multiple GHED variables across countries and years.
country_group accepts curated codes ("LAC", "OECD", "LDC", "SSA", …)
that resolve to ISO3 lists; combine freely with countries, region,
and income (filters apply via SQL AND).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| indicator_codes | Yes | ||
| countries | No | ||
| country_group | No | ||
| region | No | ||
| income | No | ||
| year_start | No | ||
| year_end | No | ||
| top | No | ||
| format | No | rows |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.2/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description discloses that country_group resolves to ISO3 lists and filters combine via SQL AND, offering behavioral insight into parameter interaction. No contradiction with annotations exists.
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 concise, using two sentences to convey purpose and key parameter behavior without extraneous detail. It is well-structured with a clear main statement followed by a specific note on country_group.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters and an output schema, the description lacks completeness by not explaining most parameters or the output format. While annotations cover safety, the description does not fully enable an agent to use the tool correctly, though the existence of an output schema mitigates return value ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage of 0%, the description must compensate. It only explains the country_group parameter and the filter combination logic, leaving 8 parameters (indicator_codes, countries, region, income, year_start, year_end, top, format) unaddressed. This is insufficient for an agent to correctly invoke the tool.
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 builds a tidy long panel for multiple GHED variables across countries and years, specifying the resource (GHED variables), action (build panel), and scope (countries/years). This distinguishes it from sibling tools like get_indicator_data which retrieve single indicators, or compare_countries which focus on comparisons.
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 explains how country_group works with curated codes and that filters (countries, region, income) combine via SQL AND, providing context for usage. However, it does not explicitly state when to use this tool vs alternatives, such as when a multi-variable panel is needed versus simple indicator retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cache_statusARead-only
Return local workbook and derived SQLite cache status.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description need not repeat those. The description confirms the tool returns status without side effects. It adds minimal context beyond annotations, such as describing the specific cache sources (workbook and SQLite). No contradictions.
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?
One concise sentence that directly states the tool's purpose. No wasted words—every part is necessary. Front-loaded with the action verb 'Return' and the resource.
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?
Given the tool's simplicity (0 parameters, no complex behavior), the description is fairly complete. It names the cache sources and indicates the return action. An output schema exists, so return value details are covered there. Slightly improved by mentioning both 'local workbook' and 'derived SQLite'.
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 has 0 parameters with 100% coverage. Per scoring rules, 0 params yields a baseline of 4. The description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns cache status for local workbook and derived SQLite. It is specific about the resource (cache status) and action (return). It distinguishes from siblings like refresh_cache by focusing on retrieval rather than refreshing. However, it could be more precise about what 'derived' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like refresh_cache or other status-related tools. The description does not specify contexts or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_for_updatesARead-only
Compare the local cache source document with the current GHED all-data file.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world behavior. The description adds context about what is being compared but does not introduce behavioral traits beyond those already captured.
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?
A single, front-loaded sentence that is concise and contains no unnecessary words. Every part contributes to the meaning.
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?
Given the absence of parameters and the presence of an output schema, the description is sufficiently complete. It could mention what the output indicates, but the core function is clear.
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?
No parameters exist, so schema coverage is 100%. The description does not need to add parameter information; a baseline of 4 is appropriate.
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 action ('compare') and the specific resources ('local cache source document' vs 'current GHED all-data file'), distinguishing it from sibling tools like cache_status and refresh_cache.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case (checking cache freshness) but does not explicitly state when to use this tool versus alternatives like cache_status or refresh_cache.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_countriesARead-only
One GHED indicator across countries, returned as tidy rows or CSV.
Pass either an explicit countries list or a curated country_group
(e.g. "LAC", "OECD", "LDC", "SSA") — or both, in which case they are
merged. See list_curated_country_groups for available groups.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| indicator_code | Yes | ||
| countries | No | ||
| country_group | No | ||
| year_start | No | ||
| year_end | No | ||
| latest_only | No | ||
| top | No | ||
| format | No | rows |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations: it mentions output format options (rows vs CSV) and parameter merging behavior. Annotations already declare readOnlyHint and openWorldHint, so the description supplements without contradicting. It does not detail rate limits or other potential behaviors.
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 very concise: two sentences that front-load the purpose, then provide parameter guidance. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters (1 required) and 0% schema description coverage, the description covers the core parameters but misses several optional ones. Output schema exists, so return values are covered. It is adequate for basic use but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain all parameters. It covers indicator_code, countries, country_group, and format, but not year_start, year_end, latest_only, or top. These omissions leave significant gaps for an 8-parameter tool.
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 it returns 'One GHED indicator across countries' in tidy rows or CSV format. It specifies the core resource (GHED indicator) and action (compare across countries), distinguishing it from siblings like 'compare_country_group' or 'get_indicator_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?
It explains how to use countries vs country_group parameters, including that they can be merged, and references list_curated_country_groups for available groups. It does not explicitly state when not to use this tool, but the guidance is sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_country_groupARead-only
Compare one GHED indicator across a country group (curated, regional, or income-based).
Pass at least one of country_group (e.g. "LAC", "OECD", "LDC"),
region, or income. Multiple filters compose via SQL AND, so
country_group="LAC", income="High" returns LAC HICs.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| indicator_code | Yes | ||
| country_group | No | ||
| region | No | ||
| income | No | ||
| year_start | No | ||
| year_end | No | ||
| latest_only | No | ||
| top | No | ||
| format | No | rows |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds filtering behavior (AND composition) but does not detail response format or pagination. No contradiction with 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 concise paragraphs: first sentence defines purpose, second explains filter logic. No redundant words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and an output schema, the description lacks details on what 'compare' returns (e.g., summary statistics, differences), and omits explanation for year range, latest_only, top, and format parameters. Incomplete for the complexity.
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 coverage is 0%. The description explains the key grouping parameters (country_group, region, income) and their composition, but ignores other parameters like year_start, year_end, latest_only, top, and format. Partial compensation for low coverage.
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 verb 'compare' and the resource 'GHED indicator across a country group'. It distinguishes from siblings like compare_countries and summarize_country_group by specifying the grouping dimension (curated, regional, income-based).
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?
Provides explicit guidance: 'Pass at least one of country_group, region, or income' and explains filter composition via SQL AND. However, it does not explicitly state when to avoid this tool or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_trendsCRead-only
Compute first/latest trend summaries for multiple GHED indicators.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| indicator_codes | Yes | ||
| countries | No | ||
| country_group | No | ||
| region | No | ||
| income | No | ||
| year_start | No | ||
| year_end | No | ||
| top_per_indicator | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is clear. The description adds no additional behavioral context, such as the definition of 'first/latest' or how summaries are computed. It does not explain what happens with the output or any limitations.
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?
The description is a single short sentence that front-loads the key action. It is concise, but at the expense of necessary detail. Every word earns its place, yet the overall value is limited by its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, only one required, and 0% schema description coverage, the description is severely incomplete. It fails to explain how to structure the request or interpret the output. The presence of an output schema does not compensate for the lack of parameter and usage guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description adds no information about any of the 8 parameters. The agent cannot infer what 'indicator_codes' expects, how to filter by countries, year range, or other parameters. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'compute' and the resource 'first/latest trend summaries for multiple GHED indicators'. It provides a specific and distinct purpose. However, it could be more precise about what 'first/latest' means and how it differs from sibling tools like 'indicator_trend'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as 'indicator_trend', 'compare_countries', or 'compare_country_group'. The description does not mention when-not to use it or provide any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
country_profileBRead-only
Latest headline health-expenditure values for one country.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | ||
| year | No | ||
| indicator_codes | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that the tool returns 'latest' values, implying currency but not high transparency. No mention of data limits, pagination, or potential warnings, but the annotations cover the safety profile adequately.
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 a single sentence with no unnecessary words. It is front-loaded and efficient, conveying the core purpose without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no schema descriptions, and a tool that likely has nuanced optional filtering (year, indicator codes), the description is too sparse. While an output schema exists, the lack of parameter guidance makes the tool significantly incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters. It only hints at 'country' implicitly, but does not explain 'year' or 'indicator_codes' meanings, formats, or relationships. This leaves the agent without critical information to use optional parameters correctly.
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 identifies the tool as providing 'latest headline health-expenditure values for one country.' This succinctly states the verb (provides), resource (headline health-expenditure values), and scope (one country), distinguishing it from sibling tools like compare_countries that handle multiple countries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention when not to use it or point to siblings like compare_countries or get_indicator_data for different needs, leaving the agent to infer usage without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
data_availabilityARead-only
Summarize availability for indicators before building a research panel.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| indicator_codes | Yes | ||
| countries | No | ||
| country_group | No | ||
| region | No | ||
| income | No | ||
| year_start | No | ||
| year_end | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with annotations (readOnlyHint=true), indicating a read-only summary operation. However, it adds no behavioral details beyond what the annotations already convey, such as data freshness or pagination behavior.
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?
The description is a single concise sentence that front-loads the key verb and resource. It is appropriately brief but could benefit from slight elaboration on parameter usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values need not be described. However, with 7 parameters and 0% schema description coverage, the description is incomplete for guiding parameter selection. Annotations partially compensate, but parameter semantics are lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, leaving 7 parameters completely undocumented. The description mentions 'indicators' but does not elaborate on the meaning or usage of the fields like 'countries', 'region', 'year_start', etc. This is insufficient for an agent to correctly fill parameters.
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 with a specific verb 'summarize' and resource 'availability for indicators', and the context 'before building a research panel' distinguishes it from sibling tools like 'build_research_panel' and 'get_indicator_metadata'.
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 provides clear timing guidance ('before building a research panel'), but does not explicitly state when not to use the tool or mention alternatives among the 34 sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_indicator_relationshipBRead-only
Explain whether a variable is a total, component, ratio/share, or context series.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| indicator_code | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include 'readOnlyHint: true' and 'openWorldHint: true', providing safety and scope context. The description only says 'explain', which is consistent but adds no behavioral details like whether it requires specific permissions or how it handles missing data. Annotations carry most of the burden.
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 a single, front-loaded sentence that conveys the core functionality with no wasted words. It is concise and structured optimally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only, output schema present), the description is minimally viable. It explains what it does but lacks usage context. With an output schema, return values don't need explanation, but some guidance on when to use it would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (parameters have no descriptions). The description mentions 'variable' but the parameter is 'indicator_code' with no explanation of what should be provided, format, or examples. It does not compensate for the missing schema descriptions.
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: 'Explain whether a variable is a total, component, ratio/share, or context series.' It uses a specific verb ('explain') and resource ('indicator relationship'), distinguishing it from sibling tools like 'additive_hierarchy' and 'build_additive_breakdown'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for understanding how a variable relates to others, but it does not explicitly state when to use this tool vs alternatives like 'additive_hierarchy' or 'build_additive_breakdown'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_country_codeCRead-only
Find ISO3 country codes by name, alias, or code fragment.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ||
| country_name | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds no extra behavioral details such as case sensitivity, partial match behavior, or handling of multiple matches.
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?
Single sentence, waste-free. Could benefit from brief structure or examples, but efficient for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple lookup tool with output schema and annotations. Missing information on behavior when both parameters are null or conflicting, and no fallback guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should clarify parameter roles. It mentions search by name, alias, or code fragment but does not map these to the two parameters (country and country_name), leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds ISO3 country codes using name, alias, or code fragment. It is specific and distinguishes from siblings that deal with country metadata or listings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_country_metadata or list_countries. No when-not instructions or context for optimal use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_country_metadataCRead-only
Return source, data-type, and estimation notes from the Metadata sheet.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ||
| indicator_code | No | ||
| top | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds no behavioral traits beyond the specific fields returned (source, data-type, estimation notes), offering minimal extra value. No mention of pagination, default behavior, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence). However, it sacrifices content for brevity, lacking parameter or usage context, which means sentences don't fully earn their place for a tool with multiple optional parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three optional parameters and no required inputs, the description does not explain filtering logic or behavior when parameters are null. The 'top' parameter suggests pagination, which is unmentioned. Output schema exists but description should clarify input semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning of the three parameters (country, indicator_code, top). It merely implies 'country' via the tool name but provides no details on how parameters interact or affect results.
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 returns source, data-type, and estimation notes from the Metadata sheet, using a specific verb ('Return') and resource ('Metadata sheet'), distinguishing it from sibling tools like get_indicator_metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., compare_countries, get_indicator_data). No mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_indicator_dataARead-only
Fetch one GHED indicator with optional country and year filters.
Spatial filters compose: country (singular), countries (list), and
country_group (curated, e.g. "LAC") merge into a single country list,
and region / income further constrain via SQL AND.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| indicator_code | Yes | ||
| country | No | ||
| countries | No | ||
| country_group | No | ||
| region | No | ||
| income | No | ||
| year_start | No | ||
| year_end | No | ||
| latest_only | No | ||
| top | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and open-world hints. The description adds behavioral transparency by detailing how spatial filters interact, which goes beyond annotations. However, it does not mention other behaviors like pagination (top parameter) or data freshness, but this is acceptable given the annotations.
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?
The description is concise with two paragraphs: a clear function statement and a focused explanation of spatial filter composition. It avoids redundancy and front-loads the main purpose. Minor improvement could further tighten the second paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, output schema exists), the description covers purpose and spatial filter logic but omits details on temporal filters, pagination, and behavior of the top parameter. The output schema covers return values, but the agent still needs more behavioral context for complete usage.
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 0%, so the description must compensate. It explains spatial filter composition (country, countries, country_group, region, income) but fails to describe temporal filters (year_start, year_end), latest_only, or top. This partial coverage leaves gaps for a significant number of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch one GHED indicator with optional country and year filters', specifying the verb (Fetch), resource (GHED indicator), and available filters. However, it does not differentiate from sibling tools like compare_countries or indicator_trend, which may cause confusion about when to use this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how spatial filters compose (merge into single country list, AND constraints), providing some guidance on filter usage. But it lacks explicit context on when to use this tool versus alternatives, such as search_indicators or compare_trends.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_indicator_metadataBRead-only
Return Codebook metadata for one GHED indicator.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| indicator_code | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description adds no new behavioral context. It is consistent with the read-only nature, but does not disclose any additional traits like pagination, authentication, or rate limits.
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 a single sentence with no fluff, efficiently conveying the tool's purpose. It is appropriately front-loaded.
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?
Given the tool is simple (one required parameter, output schema exists), the description is adequate. However, it could mention what 'codebook metadata' includes (e.g., definition, source) to improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description does not explain the parameter 'indicator_code' beyond its existence. The description fails to compensate for the missing schema descriptions, leaving the agent with minimal guidance on parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'Codebook metadata for one GHED indicator', which is a specific verb-resource combination. It distinguishes from siblings like 'get_indicator_data' (returns data) and 'list_indicators' (lists all indicators), but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as 'search_indicators' or 'list_indicators', or when not to use it. The description simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
indicator_trendCRead-only
Compute country-level first/latest trends for one GHED indicator.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| indicator_code | Yes | ||
| countries | No | ||
| country_group | No | ||
| region | No | ||
| income | No | ||
| year_start | No | ||
| year_end | No | ||
| min_year_count | No | ||
| min_period_years | No | ||
| top | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds no behavioral context beyond 'compute trends', omitting details like whether the result is a summary or includes growth rates, or any side effects. Since annotations already cover safety, the description adds minimal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks sufficient detail. It does not waste words, but it omits essential context, making it inadequate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no schema descriptions, and an output schema (unseen), the description is severely incomplete. Agents lack information to effectively use the tool, such as how to filter by countries or time ranges or interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters but only implicitly mentions indicator_code. None of the 9 optional parameters (countries, year_start, etc.) are explained, leaving agents without crucial usage information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes trends for one GHED indicator. The phrase 'first/latest trends' gives a sense of time dimension, but it's somewhat vague. It distinguishes from siblings like get_indicator_data (raw data) and compare_trends (multiple indicators), but could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like compare_trends or get_indicator_data. Agents are left to infer the appropriate context, which may lead to incorrect tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_countriesARead-only
List countries and territories available in GHED, optionally by group.
country_group accepts curated codes (LAC, OECD, LDC, SSA, …) and
intersects with region / income when more than one is set, so
country_group="LAC", income="High" returns LAC HICs.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | ||
| income | No | ||
| country_group | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and openWorldHint. The description adds value by explaining that country_group accepts curated codes and intersects with region/income, clarifying the filtering logic beyond what annotations provide.
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 concise with two sentences. The first states the core purpose, the second adds crucial behavioral detail. No extraneous or redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description covers the essential purpose and key filtering behavior. However, it does not define all parameters, which is a gap for a tool with 0% schema description coverage. It is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage. The description only elaborates on country_group with examples, but does not define region or income parameters or their accepted values. This leaves significant ambiguity for the agent.
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 'List countries and territories available in GHED', using a specific verb and resource. It distinguishes from sibling tools like get_country_metadata (which provides details) and find_country_code (which maps codes), and adds context about optional grouping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to list countries, optionally filtered by group) and describes the intersection behavior, but does not explicitly state when not to use it or mention alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_country_groupsBRead-only
List GHED country grouping values by region and World Bank income class.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint) indicate basic safety, and the description confirms a listing operation. However, the mention of filtering by region/income is inconsistent with the parameterless schema, potentially confusing behavior. No additional behavioral traits disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is concise, but the phrase 'by region and World Bank income class' is misleading given the empty parameter set. It earns its place but introduces inaccuracy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema present, the description minimally covers purpose. It lacks context about how the output relates to sibling tools or how to use the returned groups. Some detail is missing for full completeness.
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?
No parameters exist (schema coverage 100%), so the description adds value by explaining the tool's purpose (listing groupings by region and income class). This contextualizes what the tool returns beyond the name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists GHED country grouping values, with a specific scope ('by region and World Bank income class'). However, this implies filtering parameters that do not exist in the input schema, creating a slight mismatch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like list_curated_country_groups or summarize_country_group. The description does not specify context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_curated_country_groupsARead-only
List Decilion's curated country groupings (WB regions, LDCs, OECD).
Returns groups beyond GHED's built-in WHO regions and World Bank income
classes — World Bank geographic regions, the UN Least Developed Countries
list, and OECD membership. Use the returned members lists with the
countries parameter on data tools, or pass the group code to
resolve_country_group_membership to get just the ISO3 list.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe read (readOnlyHint) and no side effects (openWorldHint). The description adds value by specifying the types of groups returned and how to leverage them, but does not detail response format beyond what the output schema likely provides.
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 sentences, front-loaded with purpose and immediate usage guidance. Every sentence adds unique value without redundancy.
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 parameters, existing annotations, and presence of an output schema, the description is complete: it explains what the tool does, what it returns, and how to use the results in other tools.
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?
With zero parameters, the description cannot add parameter semantics. Baseline 4 is appropriate as the schema coverage is 100% and no parameter info is needed.
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 it lists Decilion's curated country groupings (WB regions, LDCs, OECD) and explicitly contrasts them with built-in groups, distinguishing it from siblings like list_country_groups and resolve_country_group_membership.
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?
Provides explicit guidance on when to use the tool (for groups beyond built-in) and how to use the returned data (with `members` lists or via resolve_country_group_membership). Lacks explicit 'when not to use' but the contrast with built-in groups implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_indicatorsBRead-only
List headline GHED indicators only (category_1 = INDICATORS).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| skip | No | ||
| top | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds that the tool returns only headline indicators (category_1 = INDICATORS), providing useful filtering context. However, it does not disclose pagination behavior or result limits beyond schema defaults.
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 a single, well-front-loaded sentence that captures the core functionality without unnecessary words. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description sufficiently explains the tool's purpose but lacks detail on parameter semantics. Given the presence of an output schema and the simplicity of the tool, it is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning or usage of 'skip' and 'top' parameters. It only provides the titles 'Skip' and 'Top', which are not fully explanatory for an agent.
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 'List headline GHED indicators only (category_1 = INDICATORS)', specifying the verb 'list', the resource 'headline GHED indicators', and a filtering condition. This distinguishes it from sibling tools like 'list_countries' or 'list_variables'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives such as 'search_indicators' or 'get_indicator_metadata'. There is no explicit when-to-use or when-not-to context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_variable_categoriesARead-only
List GHED variable category counts from the Codebook.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds minimal context: it lists counts from the Codebook. It does not elaborate on potential changes, frequency, or source limitations beyond what annotations imply.
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?
A single, front-loaded sentence with no unnecessary words. It efficiently conveys the tool's purpose.
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?
With zero parameters, an existing output schema, and annotations, the description is complete enough. It identifies the data source ('Codebook') and the nature of the output ('counts'), which is sufficient for a simple list 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?
There are no parameters, so baseline is 4. The description need not add parameter details; the schema coverage is 100% by default.
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 action ('List') and the specific resource ('GHED variable category counts from the Codebook'). It distinguishes itself from siblings like 'list_variables' by focusing on categories and providing counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, such as 'list_variables' or 'search_variables'. The description does not specify any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_variablesCRead-only
List all GHED Codebook variables, optionally filtered by category.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| category_1 | No | ||
| category_2 | No | ||
| skip | No | ||
| top | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds the source (GHED Codebook) and filtering capability, but does not elaborate on behavioral traits like pagination or listing scope. It does not contradict annotations.
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?
The description is a single concise sentence, efficiently stating the core functionality. However, it is slightly too brief, sacrificing clarity on parameters and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of 4 parameters, many sibling tools, and no schema descriptions, the description is incomplete. It fails to explain parameter usage, provide guidance on when to use this vs. search_variables, or clarify the role of categories.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters. It only mentions optional filtering by category, leaving category_1, category_2, skip, and top undefined. The skip and top parameters for pagination are entirely unmentioned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists GHED Codebook variables with optional filtering by category. It uses a specific verb 'List' and resource 'variables', but does not explicitly differentiate from similar sibling tools like search_variables or list_variable_categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as search_variables or list_variable_categories. It does not mention prerequisites, constraints, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
methodology_guideARead-only
Explain how GHED variables are organized and how to choose the right series.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint as true. The description adds value beyond those by specifying the explanatory nature of the tool—it conveys knowledge rather than performing data mutations. No contradictions exist, and the description appropriately complements the 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?
The description is a single, focused sentence that immediately conveys the tool's purpose. Every word earns its place; there is no redundancy or unnecessary detail. It is front-loaded and easy to parse.
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?
Given the tool's simplicity (no parameters, explanatory role), the description is complete enough. An output schema exists, so return values do not need description. The description adequately covers what the tool does and why an agent would use it.
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 tool has zero parameters, so baseline score is 4 as per instructions. The description does not need to elaborate on parameters. Schema coverage is effectively 100% since there are no parameters to document.
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 explains how GHED variables are organized and how to choose the right series. It uses a specific verb 'Explain' and specifies the resource 'GHED variables'. This purpose is distinct from all sibling tools, which do not offer explanatory guidance on variable organization.
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 explicitly tells when to use the tool: when needing to understand variable organization and series selection. While it lacks explicit 'when not to use' statements, the context is clear enough that an agent can infer appropriate usage, especially given the unique explanatory role among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rank_country_changesCRead-only
Rank countries by change in one indicator over the requested period.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| indicator_code | Yes | ||
| countries | No | ||
| country_group | No | ||
| region | No | ||
| income | No | ||
| year_start | No | ||
| year_end | No | ||
| metric | No | absolute_change | |
| descending | No | ||
| min_year_count | No | ||
| min_period_years | No | ||
| top | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds the context of ranking by change over a period but does not disclose additional behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but insufficient given the tool's complexity. It front-loads the purpose but fails to provide necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 parameters and no schema descriptions, the description is severely incomplete. It does not explain parameter semantics, output format, or usage context, making it insufficient for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the 12 parameters. It only mentions 'indicator' and 'period', leaving all other parameters (countries, region, income, year_start, year_end, metric, etc.) undocumented.
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 ranks countries by change in one indicator over a period, with a specific verb and resource. It distinguishes from sibling tools like compare_countries or comparative_trends.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
refresh_cacheAIdempotent
Download or re-download the public GHED workbook and rebuild SQLite.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotence and non-destructiveness. The description adds the specific action (download, rebuild) but lacks details on potential side effects like network usage, time cost, or impact on concurrent operations.
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?
Single sentence, no redundancy. The description is concise and front-loads the core action.
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 zero parameters and the presence of an output schema, the description sufficiently covers the tool's purpose and behavior. No additional context is necessary for this simple 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?
No parameters exist, so baseline is 4. The description does not need to add meaning beyond what the schema provides, and it correctly omits unnecessary detail.
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 downloads/re-downloads the GHED workbook and rebuilds SQLite, specifying the exact action and resource. This distinguishes it from sibling tools like cache_status or check_for_updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, recommended context, or situations to avoid, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
research_use_casesBRead-only
Research patterns seen in GHED-using literature, with recommended variables.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. Description adds context about content (GHED-using literature) but no behavioral details beyond annotations. Minimal additional value.
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?
Single sentence, very concise. Front-loads purpose. No unnecessary words. Appropriate for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists but not visible. Description mentions patterns and recommended variables but no detail on output structure or format. For a tool with no parameters and existing output schema, slightly more context on what to expect would be helpful.
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?
No parameters, so schema coverage is 100%. Baseline is 4. Description doesn't mention zero parameters, but it's not necessary. No loss of meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states tool researches patterns in GHED-using literature and gives recommended variables. Verb 'research' is somewhat vague but resource 'GHED-using literature' is specific, and it distinguishes from siblings like 'suggest_variables_for_research_question' which focuses on a specific question.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Sibling list includes many research-oriented tools, but no comparison or context is provided. Agent must infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_country_group_membershipARead-only
Resolve a curated group code to its ISO3 member list.
Accepts canonical codes (LAC, SSA, LDC, OECD, …), official WB region codes (LCN, SSF, …), and common spellings ("Latin America and Caribbean", "Sub-Saharan Africa", "Least Developed Countries").
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| group | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is read-only and non-exhaustive. The description adds behavioral context by specifying acceptable input formats (canonical codes, WB region codes, common spellings), which aids correct invocation.
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 two sentences: the first defines the primary function, the second lists acceptable inputs. Every sentence adds value with no redundancy.
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?
The description adequately covers the input parameter and acceptable formats. Despite the presence of an output schema, it lacks mention of error handling for invalid inputs, but overall it is sufficient for a straightforward resolution tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully compensates by explaining the 'group' parameter accepts canonical codes, WB region codes, and common spellings, providing concrete examples. This adds significant meaning beyond the schema's bare string type.
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 resolves curated group codes to their ISO3 member lists. It distinguishes itself from sibling tools like list_country_groups and summarize_country_group by focusing on resolving codes to members, not listing or summarizing.
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 implicitly tells when to use the tool: when you have a group code or common spelling and need the ISO3 member list. It could be improved by explicitly stating when not to use it (e.g., for non-curated groups), but the context makes it clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_indicatorsBRead-only
Search headline GHED indicators by default; pass category_1=None for all variables.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top | No | ||
| category_1 | No | INDICATORS | |
| category_2 | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. Description adds no new behavioral information beyond the search action.
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?
One sentence, 16 words, front-loaded with action and key parameter tip. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 params (0% schema coverage) and existing output schema, description leaves major gaps: query semantics, pagination, allowed category_1 values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only category_1 is partially explained. query, top, and category_2 have no schema descriptions and the description provides no meaning for them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Search', resource 'headline GHED indicators', and default behavior. Distinguishes from 'list_indicators' but could clarify 'headline'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives specific tip for category_1 parameter but no guidance on when to use this tool over siblings like 'search_variables' or 'list_indicators'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_variablesBRead-only
Search all GHED Codebook variables, including detailed SHA series.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top | No | ||
| category_1 | No | ||
| category_2 | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint, so the safety profile is clear. The description adds minimal behavioral context beyond noting that results include SHA series. No additional disclosure of constraints or side effects is needed given 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?
The description is a single sentence with no fluff. It conveys the core purpose efficiently and is well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description states the scope (all variables, including SHA series) but omits mention of optional filter parameters (category_1, category_2). An output schema exists, which may document return values, but the inability to filter from the description is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must explain parameters, but it does not. While parameter names like 'query' and 'top' are self-explanatory, 'category_1' and 'category_2' could benefit from explanation. The description adds no parameter-level context.
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 that the tool searches all GHED Codebook variables, including detailed SHA series. It specifies the verb (search) and resource (GHED Codebook variables), distinguishing it from sibling tools like list_variables and search_indicators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of when not to use it or how it differs from similar tools like list_variables, search_indicators, or suggest_variables_for_research_question.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suggest_variables_for_research_questionARead-only
Map a natural-language research question to likely GHED variables and cautions.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds value by mentioning 'cautions', suggesting the tool also provides warnings or limitations, which extends behavioral context beyond structured 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?
Single sentence that efficiently communicates action, input, and output. Every word earns its place with no redundancy.
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?
Has an output schema, which reduces the burden on description for return values. Description covers the core purpose and adds 'cautions'. Could elaborate on what cautions entail, but sufficient given output schema exists.
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 coverage is 0% for the single parameter 'question', so the description must compensate. It clarifies the parameter is a 'natural-language research question', but provides no format guidance or examples. Adequate but not enhanced.
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 'Map' and specifies the resource 'natural-language research question' and output 'likely GHED variables and cautions'. It clearly distinguishes from siblings like search_variables that perform string matching rather than conceptual mapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for research questions but does not explicitly state when to use this tool versus alternatives like search_variables or list_variables. No when-not or exclusion criteria provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
summarize_country_groupBRead-only
Summarize an indicator within a country group (curated, regional, or income).
Pass at least one of country_group ("LAC", "OECD", "LDC", …),
region, or income.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| indicator_code | Yes | ||
| country_group | No | ||
| region | No | ||
| income | No | ||
| year | No | ||
| latest_only | No | ||
| top_n | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds no extra behavioral context like side effects or rate limits. Acceptable given annotation coverage, but no added value.
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?
Two concise sentences front-loading purpose and usage tip. No fluff, but could be more structured with parameter list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters and 0% schema coverage, the description only covers grouping selection. Missing explanation of other parameters and summary behavior, though output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; the description only hints at three grouping parameters (country_group, region, income) with examples. Other parameters (indicator_code, year, latest_only, top_n) are not explained, failing to compensate for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool summarizes an indicator within a country group, specifying types (curated, regional, income). It distinguishes from siblings like compare_country_group, but could be more explicit about the summary's nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a usage tip to pass at least one grouping parameter with examples, but lacks when-to-use guidance or alternatives. Minimal but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
topics_indexARead-only
Curated GHED topic index mapping common user requests to variable codes.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety. The description adds that it is 'curated' and involves 'mapping', which provides context but does not elaborate on behavioral traits like static nature or update frequency. It is adequate given the 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?
The description is a single sentence that is concise, front-loaded with the key term 'Curated', and contains no unnecessary words. It efficiently conveys the tool's core function.
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?
Given the tool's simplicity (no parameters, annotated, output schema exists), the description is mostly complete. It explains the purpose but could briefly mention what the output contains or how the mapping is structured, though the output schema likely covers that.
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?
There are no parameters, so the schema has 100% coverage. The baseline for zero-parameter tools is 4, and the description does not need to add parameter details. It correctly omits irrelevant information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a curated index mapping user requests to variable codes. It specifies the resource (GHED topic index) and the action (mapping). However, it does not explicitly differentiate from sibling tools like search_indicators or list_variables, but the unique mapping purpose is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. With many sibling tools for searching and listing, the description should indicate that this tool is for translating user requests directly to codes, rather than general search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
versionARead-only
Return workbook version lines and cache provenance.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint. Description adds 'cache provenance', giving more detail but no behavioral traits beyond what annotations imply.
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?
Single clear sentence with no wasted words. Perfectly concise.
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?
Tool has zero parameters and output schema exists, so description adequately covers what it returns. No gaps.
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?
No parameters, so baseline 4. Description adds no parameter info but not needed.
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?
Clearly states it returns workbook version lines and cache provenance. Distinct from sibling tools like cache_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use versus alternatives like cache_status or refresh_cache.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
35 tool updates
v0.5.1- First observed
additive_hierarchy - First observed
assess_data_quality - First observed
build_additive_breakdown - First observed
build_research_package - First observed
build_research_panel - First observed
cache_status - First observed
check_for_updates - First observed
compare_countries - First observed
compare_country_group - First observed
compare_trends - First observed
country_profile - First observed
data_availability - First observed
explain_indicator_relationship - First observed
find_country_code - First observed
get_country_metadata - First observed
get_indicator_data - First observed
get_indicator_metadata - First observed
indicator_trend - First observed
list_countries - First observed
list_country_groups - First observed
list_curated_country_groups - First observed
list_indicators - First observed
list_variable_categories - First observed
list_variables - First observed
methodology_guide - First observed
rank_country_changes - First observed
refresh_cache - First observed
research_use_cases - First observed
resolve_country_group_membership - First observed
search_indicators - First observed
search_variables - First observed
suggest_variables_for_research_question - First observed
summarize_country_group - First observed
topics_index - First observed
version
TDQS
B3.4/5.0
Disambiguation4/5
Most tools have distinct purposes (e.g., list vs search, compare countries vs groups), but some like 'compare_countries' and 'compare_country_group' could be confused if descriptions are not read carefully.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern, with clear verbs like 'list', 'get', 'search', 'compare', 'build', etc. No mixing of conventions.
Tool Count3/5
35 tools is above the recommended range, but the server covers a complex domain (health expenditure data exploration and extraction) and each tool serves a specific purpose, making it borderline acceptable.
Completeness5/5
The tool surface covers the full lifecycle of data discovery (list, search, metadata), retrieval (indicator data, trends, rankings), analysis (compare, breakdown, panel building), and diagnostics (data quality, cache management), with no apparent gaps for its stated scope.
Maintenance
ActivityInactive
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Hosted MCP server exposing US hospital procedure cost data to AI assistants
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
Hosted MCP server for Cliniko — patients, appointments, availability, and invoices for AI agents.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that connects Claude to your Google Sheets for personal finance tracking, analysis, and reporting — all through natural language.2-
- AlicenseNot gradedqualityAmaintenanceA Model Context Protocol (MCP) server that brings your Withings health data into Claude, allowing natural conversation access to sleep patterns, body measurements, workouts, heart data, and more.39MIT
- AlicenseAqualityCmaintenanceA Model Context Protocol (MCP) server that gives AI assistants direct access to the World Health Organization's Global Health Observatory (GHO) for comparative health systems research.15MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Decilion/ghed-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server