Ukrainian schools, community search and education budgets. Sources: EDBO, KATOTTG, Open Budget.
Scored across 3 tools
Each tool has a clearly distinct purpose: budget retrieval, school detail lookup, and school listing by community. There is little risk of confusing the three operations.
All tool names follow a consistent verb_noun snake_case pattern: get_education_budget, get_school_info, list_schools_by_community. The convention is predictable and readable.
Three tools is a reasonable focused surface for a narrow Ukraine schools data server, though it is on the thin side. Each tool clearly earns its place.
The surface covers budget lookup, school details, and community-based listing, but lacks obvious supporting operations such as listing communities, searching schools by name, or filtering budget data by school/community. These gaps are notable though not crippling for basic lookup workflows.
Get education budget plans and actual expenses from Open Budget.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| budget_code | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it discloses almost nothing about behavior: whether this is read-only, where the Open Budget data comes from, how current it is, or what the response contains. Only the content scope (plans versus actual expenses) adds any signal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence with no filler, and the resource is front-loaded. Brevity here is not the issue; the sentence is simply too thin to carry its load.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a required parameter that is entirely undefined, the definition leaves critical gaps. An agent cannot reliably construct a call without discovering the budget_code semantics by trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain budget_code and year, yet it mentions neither. The required budget_code — where to obtain it, its format, what happens if it is invalid — is completely undocumented, and the 2026 default for year is never referenced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource (get education budget plans and actual expenses) and its scope (Open Budget), which is enough to distinguish it from get_school_info and list_schools_by_community. It stops short of stating which budget domain or region it covers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool rather than the sibling school tools, and no mention of prerequisites such as needing a known budget_code first. The agent is left to infer the context 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.
Get school details and administrative territory.
| Name | Required | Description | Default |
|---|---|---|---|
| school_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. The word 'Get' implies a read operation, but the description does not state permissions, error behavior, or what happens with invalid school IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It is concise, though that conciseness comes at the cost of under-specification captured in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter lookup, the description is still too thin: it does not say what 'details' are returned or what 'administrative territory' means. With no output schema and no annotations, more context is needed to call this confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the single 'school_id' parameter beyond implying it identifies a school. The parameter name is self-explanatory, but format or validation expectations are not described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Get school details'), so the basic operation is clear. However, 'administrative territory' is vague, and it does not differentiate from the sibling tool 'list_schools_by_community' or clarify whether this is a single-record lookup versus a list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives such as 'list_schools_by_community' or 'get_education_budget'. Usage is only implied by the required 'school_id' parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List educational institutions by Ukrainian KATOTTG community.
| Name | Required | Description | Default |
|---|---|---|---|
| community_code | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It implies a read-only listing but does not state return format, pagination, ordering, completeness, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no redundancy or filler. It communicates the core action and scope efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and undocumented parameters, the description leaves too much operational detail unspecified—especially the parameter format and what the returned list contains—for an agent to call it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single required parameter. The description only hints that community_code relates to a Ukrainian KATOTTG community, but does not specify code format, examples, or validation expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and resource ('educational institutions') with a scoping dimension ('by Ukrainian KATOTTG community'). This distinguishes it reasonably well from get_school_info (detail lookup) and get_education_budget, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus get_school_info or get_education_budget. Usage is only implied by the resource and filter, with no exclusions or prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_education_budgetget_school_infolist_schools_by_communityUkraine public spending MCP — State Treasury payment transactions (keyless).
School enrollment, graduation rates, demographics, finance, and Title I data
Education Data MCP — US K-12 schools, districts, funding and child poverty.
Add one secure layer between your agents and this server.