Places worth a detour, from Wikidata: search, nearby lookup, fame rankings, stats. No key, CC0.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.4/5 across 8 of 8 tools scored.
Each tool has a clearly distinct purpose: get_place for a single record, search_places for name-based search, top_places for ranked lists, random_place for random selection, places_near for proximity, get_statistics for aggregates, list_countries and list_kinds for enumerations. No ambiguity.
All tool names follow a consistent verb_noun pattern with underscores (e.g., get_place, list_countries, places_near). No mixing of conventions or ambiguous verbs.
8 tools is ideal for this domain—neither too few nor too many. Each tool serves a specific function without redundancy, covering lookup, search, listing, random, proximity, and statistics.
The tool set covers core read operations: single item retrieval, search, filtering by country/kind, nearby places, and aggregate statistics. Minor gaps exist, such as no direct reverse geocode or bulk export, but the surface is comprehensive for its stated purpose.
get_placeGet one place in fullAInspectFetch one place’s full record by slug (preferred, e.g. "neuschwanstein-castle") or exact name: coordinates, founding year, worldwide fame rank and tier, short description, photo URL, Wikipedia and Wikidata links, and a deep link that opens it on the map. Unsure of the slug? Call search_places first.
| Name | Required | Description | Default |
|---|---|---|---|
| place | Yes | Slug (preferred, e.g. "colosseum") or exact name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses what data is returned (coordinates, founding year, fame rank, etc.) and that it's a read operation. However, it does not mention permissions, rate limits, or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with no wasted words. It front-loads the verb and resource, then lists key fields efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is complete. It lists all return fields and usage guidance. The absence of an output schema is compensated by the detailed list of returned data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value: it specifies that slugs are preferred, provides an example ('neuschwanstein-castle'), and clarifies that exact names also work. This goes beyond the schema's simple description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Fetch one place’s full record by slug or exact name'. It lists the specific fields returned (coordinates, founding year, etc.) and distinguishes from the sibling tool search_places.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using a slug and provides guidance: 'Unsure of the slug? Call search_places first.' This tells the agent when to use this tool versus an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_statisticsAtlas statisticsAInspectHeadline statistics computed live from the atlas: totals by kind, top countries, fame-tier sizes, dated-entry stats, geographic extremes and the most famous place. The source for aggregate claims like "how many castles are on Detourmap" or "which country has the most notable places".
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool is 'computed live' and lists return values, implying a read-only operation. It does not disclose rate limits or performance characteristics, but the information given is sufficient for typical use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the key idea ('Headline statistics computed live'), and every word adds value. No redundancy or verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description comprehensively lists the types of statistics returned (totals, top countries, fame tiers, etc.) and gives example questions. This is complete for a no-parameter, read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage (by default), the baseline is 4. The description adds no parameter info because there are none, but that is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is specific and informative: it states the tool computes 'headline statistics' from the atlas, listing categories like totals by kind, top countries, etc. It provides examples of questions it answers, clearly distinguishing it from siblings that handle individual places, lists, or spatial queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for aggregate claims ('how many castles') but does not explicitly state when to use this tool over siblings or when not to use it. No direct comparison or exclusion criteria are provided, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_countriesCountries with place countsAInspectEvery country in the atlas with its place count, most first — answers "which country has the most notable places". Countries with eight or more places include a browsable index page URL.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It describes output structure (place count, URL for high counts) but does not disclose behaviors like read-only nature, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides a complete overview of what the tool returns, including key details like ordering and URL for high-count countries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description adds meaning about the output content, which is valuable beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists every country with its place count, sorted most first, and answers a specific question. It distinguishes itself from siblings like get_place and list_kinds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by answering a specific question, but it does not explicitly state when not to use or provide alternatives beyond the implied scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_kindsThe seven kinds of placeAInspectDetourmap’s seven kinds (layers) with worldwide counts and browsable index pages — ruins & the uncanny, sacred sites, built landmarks, nature & landscapes, parks & cemeteries, museums & culture, and fun & leisure.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes what is returned (kinds, counts, index pages) and implies no side effects. Sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, compact and front-loaded. Could be slightly more structured but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with no output schema, description fully explains what the tool returns, listing the seven kinds and mentioning counts and index pages.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, baseline 4. Description adds meaning about the output (kinds and counts) beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description lists the seven kinds (layers) with worldwide counts and browsable index pages, and names the categories. It clearly distinguishes from sibling tools like get_place or search_places.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool over alternatives. Implied usage for viewing categories, but lacks when-not or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
places_nearFind places worth a detour near a pointAInspectList notable places within a radius of a WGS84 coordinate, most famous first (rank order), each with distance_km — the direct answer to "what is worth visiting near ?". Radius defaults to 50 km (max 500). Geocode the location yourself, then call this with its latitude/longitude. Filter by kind to answer e.g. "waterfalls near Zurich".
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Kind of place — key or slug: ruins (Ruins & the uncanny), sacred (Sacred sites), landmark (Built landmarks), natural (Nature & landscapes), parks (Parks & cemeteries), museum (Museums & culture), fun (Fun & leisure) (optional) | |
| limit | No | Max results (default 15) | |
| latitude | Yes | ||
| longitude | Yes | ||
| radius_km | No | Search radius in km (default 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, description fully discloses behavior: radius defaults and limits, rank order, distance_km returned, and that geocoding is not internal. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key info (what, how, defaults), no redundant phrases. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema but description mentions distance_km and rank order, sufficient for a list tool. Could add pagination info but not essential given limit param.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 60% with descriptions for kind, limit, radius_km. Description compensates for undocumented latitude/longitude by explaining they are geocoding results. Adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'List notable places' with clear resource (places near a point) and differentiates from siblings like search_places by emphasizing geolocation-based query and rank order by fame.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('direct answer to what is worth visiting near') and preprocessing instruction (geocode yourself). Does not explicitly list exclusions but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
random_placeA random place worth a detourAInspectOne random place with its full record — deliberately biased toward the little-known long tail, like the site’s own "Surprise me" button. Optionally limit by country and/or kind. Great for discovery and "place of the day" features.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Kind of place — key or slug: ruins (Ruins & the uncanny), sacred (Sacred sites), landmark (Built landmarks), natural (Nature & landscapes), parks (Parks & cemeteries), museum (Museums & culture), fun (Fun & leisure) (optional) | |
| country | No | Country name or ISO code (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses bias toward little-known entries, but no annotations exist; missing details on response format, data freshness, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences front-loading the core purpose and optional filters, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main purpose and optional filters for a simple random tool; could mention what 'full record' includes or error handling, but sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameters are fully described in schema; description only repeats optionality, adding no extra meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns one random place biased toward little-known entries, distinguishing it from sibling tools like 'get_place' (specific) and 'search_places' (query-based).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Suggests use for discovery and 'place of the day' features, and notes optional filters, but lacks explicit when-not-to-use or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_placesSearch places by nameAInspectSearch 111,955 notable places worldwide by name (accent- and case-insensitive substring match): ruins & the uncanny, sacred sites, built landmarks, nature & landscapes, parks & cemeteries, museums & culture and fun & leisure. Optionally filter by country (name or ISO code) and kind. Results come best-match-first, then by fame; each carries coordinates, fame rank/tier and links to the map and Wikipedia. If nothing matches, retry with a shorter fragment.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Kind of place — key or slug: ruins (Ruins & the uncanny), sacred (Sacred sites), landmark (Built landmarks), natural (Nature & landscapes), parks (Parks & cemeteries), museum (Museums & culture), fun (Fun & leisure) (optional) | |
| limit | No | Max results (default 10) | |
| query | Yes | Name or part of a name, e.g. "pyramiden" or "plitvice" | |
| country | No | Country name or 2-letter ISO code (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses search algorithm, result ordering, and output fields (coordinates, fame, links). Does not mention rate limits, authentication, or pagination behavior beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise single paragraph, front-loaded with purpose and key details. Every sentence adds value, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, description provides thorough context: search mechanism, filters, result structure, and troubleshooting hint. Fully adequate for agent to decide and use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds value beyond schema by explaining accent/case insensitivity, substring matching, and result details. Schema already covers 100% of parameters, but description enriches understanding significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches worldwide places by name with accent- and case-insensitive substring match, lists categories, and distinguishes from siblings by specifying the search scope and filtering options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance to retry with a shorter fragment on no match, and mentions optional filters by country and kind. However, lacks explicit when-to-use vs. alternatives like places_near or top_places.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
top_placesMost famous placesAInspectThe most famous places worldwide, in one country, or of one kind — ordered by Detourmap fame rank (derived from Wikipedia language coverage; rank 1 is the most famous). The direct answer to "most famous in " and "what are the must-sees in ".
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Kind of place — key or slug: ruins (Ruins & the uncanny), sacred (Sacred sites), landmark (Built landmarks), natural (Nature & landscapes), parks (Parks & cemeteries), museum (Museums & culture), fun (Fun & leisure) (optional) | |
| limit | No | How many (default 10) | |
| country | No | Country name or ISO code (optional — omit for worldwide) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the ranking methodology ('Detourmap fame rank derived from Wikipedia language coverage') and ordering behavior. It does not mention side effects, authentication, or rate limits, but the tool appears to be a read-only query, so the transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no filler. Every sentence adds value: the first defines scope and ordering, the second clarifies specific query use cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 optional parameters and no output schema, the description is mostly complete. It explains the ranking and filtering, but lacks any mention of the return format or structure, which would be helpful for an agent to understand the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description reiterates that 'kind' and 'country' can be used to filter, but does not add significant semantics beyond what the schema already provides (e.g., specific values for 'kind' or format for 'country').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns 'most famous places' ordered by fame rank, and provides concrete use cases like 'most famous <kind> in <country>'. It distinguishes from sibling tools like search_places, random_place, and places_near by its specific ranking focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly indicates when to use this tool: for queries about 'most famous' places or 'must-sees' in a country. It does not explicitly state when not to use it or mention alternatives, but the provided use cases and sibling context imply appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!