edp-mcp

Official

by UrbanInstitute

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Summarize data

get_summary

Read-onlyIdempotent

Aggregate education data by group with counts, sums, averages. Handles multi-year trends in one call, returning complete results or refusing invalid groupings.

Instructions

Aggregate a dataset server-side: counts, sums, averages by group. Use this rather than get_data whenever the question is about totals ("how many schools per state", "total enrollment by race").

EVERY year comes back in one call — results are grouped by year on top of by, so a trend needs one call, never one per year. Filter years only to narrow a large result. Results are COMPLETE or refused. The API cannot rank aggregates, and refuses groupings that produce too many groups (by=leaid nationally, for instance).

var and by are drawn from two different pools — describe_dataset lists both for any dataset. Guessing costs a slow round trip; reading them does not.

COST: this hits a live API and a broad aggregation can take 30s+.

NO COUNTY AGGREGATION for schools or districts. Several datasets return county_code as a column, but it is neither filterable nor groupable, so county totals cannot be computed here — fetch the rows with get_data and aggregate them yourself, or say the portal does not support it. Do not retry with county in by.

Args: path: The SUMMARY path — no year, no {placeholders}, e.g. "schools/ccd/enrollment". describe_dataset prints the right one for any dataset. Some differ from the data path ("college-university/ipeds/fall-enrollment/race"). var: The measure to aggregate — a numeric, non-filter variable stat: sum, count, avg, min, max, median, stddev, or variance by: Comma-separated groupings — "fips", "fips,race". May also use variables from the source's directory ("school_level", "sector"). filters: "fips=6" — omit year to get every year; "year=2018,2019,2020" to restrict the range

Input Schema

TableJSON Schema

Name	Required	Description	Default
`by`	Yes
`var`	Yes
`path`	Yes
`stat`	Yes
`filters`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 18, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context beyond annotations: 'Results are COMPLETE or refused' (failure mode), 'this hits a live API and a broad aggregation can take 30s+' (performance), 'Guessing costs a slow round trip; reading them does not' (latency cost), and 'The API cannot rank aggregates' (capability limit). It also reveals that 'EVERY year comes back in one call' and that the API refuses groupings producing too many groups. This is rich disclosure that materially helps the agent.

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 dense but every sentence earns its place. It is front-loaded with purpose and usage, then moves into behavioral constraints, performance cost, and parameter semantics. The Args section is clearly structured. Given the tool's complexity and the need to compensate for the lack of schema descriptions, the length is appropriate — there is no fluff or repetition.

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?

For a tool with 5 parameters, 0% schema descriptions, and no enums, the description covers everything an agent needs: purpose, usage, exclusions, behavioral constraints, failure modes, performance, and parameter semantics. It also names alternative tools and explains when to use them. Since an output schema exists, it does not need to describe return values. No critical information 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% — no parameter descriptions are provided in the input schema. The description fully compensates by explaining every parameter in the Args section with concrete examples and constraints: path ('The SUMMARY path — no year, no {placeholders}, e.g. schools/ccd/enrollment'), var ('the measure to aggregate — a numeric, non-filter variable'), stat (lists the allowed values), by (examples 'fips' and 'fips,race' plus directory variables), and filters (examples with year and fips). This is exactly what the agent needs to construct valid calls.

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 precise statement of what the tool does ('Aggregate a dataset server-side: counts, sums, averages by group') and immediately differentiates it from the sibling get_data by stating 'Use this rather than get_data whenever the question is about totals.' This gives the agent a clear verb, resource, and scope, and explicitly names the alternative it is not.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance ('Use this rather than get_data whenever the question is about totals'), plus concrete exclusions and alternatives: 'NO COUNTY AGGREGATION... fetch the rows with get_data and aggregate them yourself,' and 'Do not retry with county in by.' It also explains when to filter years and warns that 'The API cannot rank aggregates' and 'refuses groupings that produce too many groups.' These are clear usage rules and alternatives.

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

Deploy Server