Skip to main content
Glama

Criora: climate & disaster risk for any place

Find a place

find_place
Read-onlyIdempotent

Candidate coordinates for a place name or address, best match first, each with its full name and kind (city, state, road and so on).

Call it when a name is ambiguous (several Springfields) and the right candidate must be chosen, or when one place is the subject of several calls and its coordinates should be looked up once. The other place tools take a name themselves and use its best match, so a single question about an unambiguous place needs no find_place first.

It queries OpenStreetMap Nominatim (ODbL) through Criora's geocoder, which every user shares and which sends one request a second: a burst of calls waits its turn, and a name looked up in the last week is answered from a cache. A name that matches nothing returns an empty list. A city resolves to its centre as OpenStreetMap maps it.

Input Schema

NameRequiredDescriptionDefault
limitNoHow many candidates to return
queryYesA place name or address, in any language

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedOutput schema / $defs
      Added value: +{
      +  "Place": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "display_name": {
      +        "description": "The full name, with the region and country",
      +        "title": "Display Name",
      +        "type": "string"
      +      },
      +      "kind": {
      +        "anyOf": [
      +          {
      +            "type": "string"
      +          },
      +          {
      +            "type": "null"
      +          }
      +        ],
      +        "description": "What the name is: city, state, road and so on",
      +        "title": "Kind"
      +      },
      +      "latitude": {
      +        "title": "Latitude",
      +        "type": "number"
      +      },
      +      "longitude": {
      +        "title": "Longitude",
      +        "type": "number"
      +      },
      +      "name": {
      +        "title": "Name",
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "name",
      +      "display_name",
      +      "latitude",
      +      "longitude",
      +      "kind"
      +    ],
      +    "title": "Place",
      +    "type": "object"
      +  }
      +}
    • addedOutput schema / properties / result / items / $ref
      Added value: +"#/$defs/Place"
    • removedOutput schema / properties / result / items / additionalProperties
      Removed value: -true
    • removedOutput schema / properties / result / items / type
      Removed value: -"object"
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, and the description still adds substantial context: a shared Nominatim-backed geocoder rate-limited to one request per second, burst calls queueing, a one-week cache, an empty list on no match, and city results resolving to the OSM centre. That is real behavioral disclosure beyond the structured fields.

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?

Three short paragraphs, front-loaded with the return shape, then routing guidance, then operational caveats. No sentence is filler: even the geocoder provenance sentence carries the licensing, rate-limit and cache facts an agent needs.

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?

An output schema exists, so return values need not be described in prose. Combined with the disambiguation guidance, empty-result behavior, rate limiting and cache semantics, the definition covers everything needed to invoke this tool correctly in an agent loop.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both 'query' and 'limit' documented in the schema itself, so the baseline is 3. The description adds only an implicit ordering guarantee ('best match first') and does not elaborate on the limit cap or accepted address formats beyond what the schema states.

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 first sentence names a specific verb-equivalent (return candidate coordinates) and resource (a place name or address), plus the ordering and payload (best match first, full name and kind). It also distinguishes itself from the sibling place tools, which geocode internally, so an agent can separate find_place from assess_place or get_forecast without opening a schema.

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?

Gives explicit when-to-use triggers (ambiguous name with several Springfields; one place reused across several calls) and an explicit when-not-to ('a single question about an unambiguous place needs no find_place first'). It also identifies the alternative behavior of the other place tools, which is exactly the routing information an agent needs.

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.