Georgia Civic Data

Find a Place or Group Code

resolve_entity

Read-onlyIdempotent

Turns a place or demographic name or code into the code the data uses (district_code, school_code, county_fips, or demographic) with its label, e.g. 'Atlanta Public Schools' or 'Fulton'. A guessed code otherwise returns an empty page. kind is district, school, county, or demographic; 'Fulton' as a county is the county and as a district is the school district, which are different things. Matches loosely, ranks candidates, and flags ambiguous when several are close. A real Georgia place is never matched to a different one: a consolidated city returns its county ('Columbus' -> Muscogee, matched_on=consolidated_city), another city asked as a county returns the county it is in, flagged ambiguous, and a one-letter misspelling returns matched_on=typo. A city school system answers to the common forms of its name ('Decatur Public Schools' -> City Schools Of Decatur, matched_on=city_system), and a county's system to its place name ('Cobb Schools' -> the county's district, matched_on=county_system). A school or district is also found by an earlier name ('Brookhaven Innovation Academy' -> BIA Charter School, matched_on=former_name). place_note, when present, explains the match and is worth passing on to the user. Census tracts have no kind here: filter by tract_geoid, the 11-digit Census tract ID.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "kind": "<kind>",
      "query": "<query>"
    },
    "name": "resolve_entity"
  }
}

Input Schema

Name	Required	Description
`kind`	Yes	What the name is: district, school, county, or demographic.
`limit`	No	Most candidates to return (default 10, at most 50).
`query`	Yes	The name or code to look up, e.g. 'Fulton'.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 26, 2026
- addedInput schema / properties / kind / description
```
Added value: +"What the name is: district, school, county, or demographic."
```
- addedInput schema / properties / kind / enum
```
Added value: +[
+  "district",
+  "school",
+  "county",
+  "demographic"
+]
```
- addedInput schema / properties / limit / description
```
Added value: +"Most candidates to return (default 10, at most 50)."
```
- addedInput schema / properties / limit / maximum
```
Added value: +50
```
- addedInput schema / properties / limit / minimum
```
Added value: +1
```
- addedInput schema / properties / query / description
```
Added value: +"The name or code to look up, e.g. 'Fulton'."
```
First observedSep 7, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations, the description discloses important behavior: loose matching, candidate ranking, ambiguity flags, special consolidated-city and typo handling, former-name matching, and place_note explanations. This gives an agent substantial behavioral context not captured by readOnlyHint or idempotentHint.

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 definition is front-loaded with the core purpose and then layers in edge-case behavior. It is somewhat long and example-dense, but the detail is relevant to correct resolution rather than wasted.

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 annotations covering safety and an output schema covering return values, the description supplies the remaining behavioral context an agent needs: matching behavior, ambiguity handling, place_note, and the census-tract exclusion. Nothing important appears missing for correct invocation.

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?

Schema coverage is 100%, so the schema already documents all three parameters. The description adds meaningful semantics for kind and query, especially the county-versus-district distinction for names like 'Fulton' and examples of matched_on outcomes, though it does not further explain limit.

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 states a specific verb and resource: it turns a place or demographic name/code into the data's canonical code and label. It also names the output code types (district_code, school_code, county_fips, demographic), making the tool's scope clear and distinguishable from general querying siblings.

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 gives useful usage context: guessed codes return an empty page, kind must be one of four values, and census tracts are explicitly out of scope and should be filtered by tract_geoid instead. It does not name sibling tools or explicitly say when to use this instead of them, so it falls short of a full 5.

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

All Georgia Civic Data tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?