Skip to main content
Glama

Find place codes

mb_find_place
Read-onlyIdempotent

Convert a city, airport, station or hotel name into the correct code or ID required by flight, train, bus, taxi and hotel searches.

Instructions

Turn a city, airport, station or hotel name into the code a search takes.

flight: airports (Iranian, IATA code; Tehran domestic is THR, not IKA; prefer these to XXXALL for domestic routes) and cities (any country; XXXALL = all its airports). train: station ids (Tehran 1, Mashhad 191). bus / taxi: 8-digit city ids (Tehran 11320000 = all terminals; 11321006 = Tehran South). hotel: city slugs (mb_search_hotels, mb_city_hotels) and hotel slugs (mb_hotel, mb_hotel_rooms). Next: mb_search_flights, mb_search_trains, mb_search_buses, mb_search_taxis or mb_search_hotels.

Input Schema

NameRequiredDescriptionDefault
modeYesWhich search the code is for; each mode uses its own ids.
limitNoMax places per list.
queryYesPlace name in Persian or English, or a code, e.g. 'مشهد', 'tehran' or 'IST'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.3.0
    • removedInput schema / properties / limit / title
      Removed value: -"Limit"
    • removedInput schema / properties / mode / title
      Removed value: -"Mode"
    • removedInput schema / properties / query / title
      Removed value: -"Query"
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "title": "mb_find_placeDictOutput",
      -  "type": "object"
      -}New value: +null
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful domain behavior beyond that: Tehran domestic is THR not IKA, and these codes are preferred over XXXALL for domestic routes.

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?

Front-loads the one-line purpose, then breaks down by mode with concrete examples. Dense and information-rich, though the multi-clause mode section could be tightened.

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 carries the burden of explaining what is returned, and it does so by describing the code formats per mode. Covers the essential path from name to code and the handoff to search tools.

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%, but the description adds meaning the schema does not: the concrete per-mode id formats and example codes that let an agent interpret and choose `mode` correctly. It goes beyond the terse enum description without fully documenting limit behavior.

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?

States a specific transformation ('Turn a city, airport, station or hotel name into the code a search takes'), naming both the input resource and the output artifact. This clearly distinguishes it from the mb_search_* siblings that consume those codes.

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?

Explicitly maps each mode to the id type it needs (flight→airports/cities, train→station ids, bus/taxi→8-digit city ids, hotel→slugs) and closes with a concrete 'Next:' routing to the five search tools. Both when-to-use and the downstream alternatives are named.

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