ew-mcp

Official

by UrbanInstitute

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Get metric values

get_data

Read-onlyIdempotent

Fetch Education-to-Workforce metric values for places or rank places on a metric. Choose by geo ID, state, or extremes; automatic benchmarks included.

Instructions

Fetch Education-to-Workforce metric values for places, or rank places on a metric. Choose places one of three ways: geo_ids for specific ones, state for every place at that level in a state, or rank for the extremes.

State and national benchmarks are added automatically for a handful of places; demographic context is added for a whole state.

Coverage is uneven: districts carry ~35 metrics, counties ~62, and many places have no data for a given metric. "No data here" is a real finding — report it rather than substituting a different geography.

Every result carries its own reading notes and caveats. Use them: values are rendered for you, some metrics are signed representation gaps rather than rates, and there are NO margins of error, sample sizes or denominators anywhere in this dataset, so never call a difference significant.

Args: metric_ids: Comma-separated ids — "47" or "47,51". geo_level: "national", "state", "county", or "district". geo_ids: Comma-separated geoids from resolve_place. state: 2-digit state FIPS — every place at geo_level in that state. years: Comma-separated years — "2022" or "2013,2022". Omit for all. disaggregate: A dimension ("race", "gender", "disability", "ell", "income") for every group, or one group code ("d1_hispanic"). Ranking requires a single group code. rank: "highest" or "lowest" to rank places instead of listing values. limit: How many places to return when ranking.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`rank`	No
`limit`	No
`state`	No
`years`	No
`geo_ids`	No
`geo_level`	Yes
`metric_ids`	Yes
`disaggregate`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 11, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the read-only/idempotent annotations, the description discloses substantial behavior: benchmarks added automatically, demographic context for states, uneven coverage by geography, and the critical caveat that there are NO margins of error, sample sizes or denominators so differences must never be called significant. This is exactly the kind of context annotations cannot convey.

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 purpose and selection options are front-loaded, and every section (benchmarks, coverage caveats, args) earns its place. It is somewhat long, but the length is justified by the 0% schema coverage and the genuine nuance in the dataset.

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 an output schema present, the description need not explain return values, and it fills the remaining gaps: parameter meanings, auto-added benchmarks, coverage unevenness, and the statistical-misuse warning. Nothing an agent needs to call this correctly is missing.

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?

Schema description coverage is 0%, so the description carries the full burden and does so thoroughly: it explains each of the 8 parameters, gives comma-separated syntax examples for metric_ids/years/geo_ids, clarifies state as 2-digit FIPS, and specifies that disaggregate accepts a dimension or a single group code.

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 opens with a specific verb+resource ('Fetch Education-to-Workforce metric values for places, or rank places on a metric') and covers both listing and ranking modes. It also distinguishes itself from sibling resolve_place by explicitly directing geoid sourcing there.

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 clearly lays out three mutually exclusive ways to select places (geo_ids, state, rank) and adds constraints like 'Ranking requires a single group code' and 'Omit for all' on years. It routes to resolve_place for geoids, though it doesn't explicitly state when to prefer this tool over siblings like search.

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

Deploy Server