Skip to main content
Glama

find_polity

Read-onlyIdempotent

Look up a state or empire by name or any of its Wikidata labels and aliases (substring, case-insensitive), or by Wikidata QID. Returns its lifespan, every border snapshot with its bounding box, and links.

Input Schema

NameRequiredDescriptionDefault
langNoSite language for returned page and map links. Use the language the user is writing in.en
queryYesName, e.g. "Ottoman", or a QID, e.g. "Q12560".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / lang
      Added value: +{
      +  "default": "en",
      +  "description": "Site language for returned page and map links. Use the language the user is writing in.",
      +  "enum": [
      +    "en",
      +    "fr",
      +    "es",
      +    "pt",
      +    "de",
      +    "it",
      +    "nl",
      +    "ja",
      +    "ru",
      +    "pl",
      +    "tr",
      +    "id",
      +    "hi",
      +    "ar"
      +  ],
      +  "type": "string"
      +}
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: substring, case-insensitive matching over labels/aliases, and the fact that the result set includes lifespan, every border snapshot with bounding box, and links. It does not say what happens on zero or multiple matches.

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?

Two tight sentences: the first front-loads the lookup keys and matching semantics, the second states what is returned. No filler or restatement of the tool name.

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?

With no output schema, the description correctly takes on the burden of describing returns (lifespan, border snapshots with bounding boxes, links) and the matching rules. The only gaps are ambiguity handling for multiple matches and the empty-result case, which are minor for a read-only lookup.

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 baseline is 3. The description adds meaning beyond the schema's terse 'Name, e.g. Ottoman or a QID' by clarifying that matching also covers all Wikidata labels and aliases and is substring/case-insensitive, which materially affects how the agent should phrase the query. The 'lang' parameter is left entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource ('look up a state or empire') plus the exact matching keys (name, Wikidata labels/aliases, QID), so the agent immediately knows this is an entity-resolution tool rather than a temporal or event tool. It stops short of naming sibling tools like world_at_year to explicitly route the agent, so it lands just below the top tier.

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

Usage Guidelines3/5

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

Usage is implied by the lookup semantics and the accepted identifier forms, which tells the agent it should be used when the user names a polity. There is no explicit when-to-use/when-not statement and no mention of alternatives such as world_at_year for time-based queries or search_events for event lookups.

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.

Resources