Skip to main content
Glama

population

Population and demography, drilled down from the world to the ZIP code. Give a key (us, us-ca, us-ca-los-angeles, gb, gb-england-london), a US zip, or a place name in q; no argument is the world. Answers with the area (population, year, measures: age, income, home value, rent, poverty, education, unemployment, race and Hispanic origin for the US; growth, age structure, births, deaths, fertility, life expectancy, migration, GDP per head and Gini for countries), how many areas of each level it contains, and the largest of its children at level (country, state, city or zip). Sources: World Bank, US Census ACS 5-year, GeoNames.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoA place name to look up, e.g. Springfield (optional)
keyNoArea key, e.g. us, us-ca, us-ca-los-angeles, us-90210, de (optional)
zipNoA US ZIP code (optional)
levelNoWhich children to list: country, state, city or zip (optional)
limitNoChildren to list, default 20, max 500
offsetNoSkip this many children, for paging

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the response shape: the area with population, year, and a list of measures; the count of areas at each level; and the largest children at the requested level. It also names data sources. It does not explicitly state that the operation is read-only, but that is implied by the nature of the tool and the lack of mutation language. Minor gaps like error handling for invalid keys are not covered, but the essential behavior is transparent.

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 somewhat long but every sentence contributes value. The first sentence states the purpose, the second details inputs, the third describes outputs, and the fourth cites sources. It front-loads the core function and packs in the necessary specifics without fluff. It is dense but not verbose, appropriate for a tool with six parameters and complex output requirements.

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 there is no output schema, the description must explain what the tool returns, and it does: the area with population, year, measures (listed), count of areas at each level, and largest children. It also covers inputs thoroughly and names sources. It does not explicitly describe pagination behavior beyond the limit/offset parameters, but those are already in the schema. The description is sufficient for an agent to understand the tool's scope and output without additional context.

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 already provides descriptions for all six parameters, so the baseline is 3. The description adds meaningful context by explaining the hierarchical relationship between key, zip, and q, and by clarifying that no argument means the world. It also elaborates on the level parameter's purpose (country, state, city, zip). This goes beyond the schema's simple examples and helps the agent understand how to combine parameters, so it earns a 4.

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 function: providing population and demographic data for geographic areas from world down to ZIP code. It specifies the resource (population/demography) and the drill-down nature, and it lists concrete input methods (key, zip, q) and output contents (area measures, children). It is distinct from all sibling tools, which focus on feeds, profiles, TLDs, etc., so no confusion arises.

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 gives explicit instructions on how to specify an area: via a hierarchical key (e.g., us-ca), a US zip, or a place name in q, with no argument meaning the world. It also explains the optional level parameter for listing children. While it does not name alternatives, none of the sibling tools serve a similar purpose, so no comparative guidance is necessary. The usage context is clear and complete.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.