Skip to main content
Glama

OpenAny

Search cities by name

treg_post_call_companyenrich_geo_cities_search

Searches cities by name or country codes — returns up to 100 cities per page Uses the caller's OpenAny gateway credentials. Charges and authorization are determined by the gateway.

Input Schema

NameRequiredDescriptionDefault
bodyYesJSON request body for Search cities by name. See individual field descriptions for input requirements.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations, the description must carry the full behavioral burden. It does disclose two useful traits — a 100-result page cap and that charges/authorization are delegated to the gateway — but says nothing about whether the call is free, rate-limited, what error behavior looks like, or what a returned city record contains.

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?

Scope is front-loaded in the first clause, followed by the result-size limit and gateway note. Three short sentences with no filler, though the gateway sentence reads as boilerplate that could be shared across the family.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a small single-body search with a fully documented schema and no output schema, most of what an agent needs is present. The remaining gap is that nothing indicates what a city result looks like (id, name, coordinates) or whether pagination beyond page 1 is worth using, which matters for a tool that returns a capped 100-item page.

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 coverage is 100%, and the schema actually documents more than the description does (prefix matching, ISO alpha-2 format, 1-based page numbers). The description only restates the two search dimensions, so baseline 3 applies.

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?

States a specific verb and resource ('Searches cities') and names the two filter dimensions (name, country codes), which lets an agent place it relative to the geo_countries_search and geo_states_search siblings. It does not explicitly say how it differs from those siblings, so it stops short of a 5.

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 only implied: an agent can infer this is the tool for resolving city names, and 'countryCodes to scope the search' hints at a two-step lookup, but there is no explicit when-to-use, when-not-to-use, or pointer to the countries/states search alternatives.

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.