Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@FilmMap MCP server Where was The Grand Budapest Hotel filmed?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol server for the FilmMap atlas: 15,368 real filming locations across 166 countries, joined to the 13,312 films, series, video games, anime and manga recorded at them, with coordinates, fame ranking, per-place production lists and the source behind every claim.
It is already running. Point a client at the hosted endpoint — there is no install, no signup and no API key:
https://thefilmmap.com/mcpStreamable HTTP, stateless, POST-only (a GET returning 405 is correct).
{
"mcpServers": {
"filmmap": {
"type": "http",
"url": "https://thefilmmap.com/mcp"
}
}
}Related MCP server: mcp-arcgis-albuquerque
Tool | What it does |
| Give a title, get the places it was shot at, each with its evidence |
| The inverse, and the question this atlas is unusual for answering: give a place, get everything recorded as made there |
| Find productions by name, accent- and case-insensitive, best match first |
| Find places by name, filterable by country or kind of place |
| Places within a radius of a WGS84 coordinate, each with |
| The atlas ranked, worldwide or inside one country or one kind of place |
| Every country with how many filming locations it holds |
| Live aggregates — totals by medium and by kind of place, top countries, busiest places |
This is the part worth reading before wiring it into anything that writes prose.
Films and series are placed by filming location (P915). Video games, anime and manga are filmed nowhere, so they are placed by narrative location (P840) — where the story is set — and every record says which relation it carries. Repeating one as the other publishes a false claim.
A place is not a scene. P915 records that a production filmed at a place and stops there. Which scene was shot where is not in the data and must not be inferred from it.
Two kinds of evidence, never merged. Most links are Wikidata statements. Some are places named in a production's English Wikipedia Filming section, or a setting category its editors filed it under; those arrive in their own fields, labelled with the exact article and section they were read from. Say "per Wikipedia" when you repeat one.
Coverage is uneven and the server says so. 834 productions are recorded only at country level and appear with countries and no coordinates. A further 3,906 cannot be placed at all; they are published as a work list at thefilmmap.com/gaps/ so they can be fixed on Wikidata.
Built from Wikidata, with photographs from Wikimedia Commons and article text linked rather than bundled. The factual records are CC0 and downloadable as GeoJSON and CSV from thefilmmap.com/data, also mirrored on GitHub.
The server reads one file, atlas-compact.json, which is the site's own wire
format and is rebuilt on every deploy.
ATLAS_JSON=/path/to/atlas-compact.json PORT=8896 node server.mjsOr with Docker, which bakes the public copy of the atlas into the image:
docker build -t filmmap-mcp .
docker run -p 8896:8896 filmmap-mcp # → http://localhost:8896/mcpHOST defaults to 127.0.0.1; the container sets 0.0.0.0 because the default
is unreachable from outside a container.
MIT for the server. The dataset it serves is CC0; photographs and Wikipedia text referenced by URL stay under their own licences.
Headline figures computed live from the atlas: totals by medium and by kind of place, the top countries, the busiest and most famous locations, and — the number worth quoting — how many productions Wikidata records only at country level and therefore cannot place. The source for any aggregate claim about this dataset.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses that figures are 'computed live from the atlas' and includes the important caveat about productions that cannot be placed below country level. It does not explicitly state read-only behavior, but the zero-parameter aggregate nature makes this low-risk and adequately 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?
The description is compact and front-loaded, naming the operation in the first phrase and then enumerating outputs efficiently. The second sentence adds usage context without padding, and even the stylistic aside about the 'number worth quoting' carries practical guidance about the most useful statistic.
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 zero-parameter tool with no output schema, the description is complete: it identifies what the tool returns in enough detail for an agent to know what to expect, clarifies that results are live, and positions the tool as the canonical source for aggregate claims. Nothing essential is missing for selecting or invoking it.
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?
The tool has zero parameters and 100% schema description coverage, so there is nothing for the description to add. The baseline of 4 applies because no parameter documentation is needed.
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 computes headline aggregate statistics from the atlas, enumerating exactly what figures it returns: totals by medium and kind of place, top countries, busiest/famous locations, and country-level-only productions. This distinguishes it from the sibling tools, which focus on specific lookups and lists rather than dataset-wide aggregates.
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 final sentence, 'The source for any aggregate claim about this dataset,' gives clear guidance on when to use this tool. It does not explicitly name alternative tools or state exclusion conditions, but the aggregate-vs-specific distinction is strongly implied by the description and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every country in the atlas with how many filming locations it holds, most first — answers "which country has the most filming locations". Countries with a browsable page carry its URL. Coverage reflects what Wikidata records, which is uneven and skewed to Europe and North America, so read these as records and not as an inventory of world film production.
| 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 disclosure burden. It reveals ordering (most first), optional URL presence for browsable countries, and an important data-quality caveat about uneven Wikidata coverage. It stops short of describing fields or pagination, but there are no parameters and the output shape is implied.
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 front-loaded sentences contain the core result, ordering, URL behavior, and a caveat, with no filler. The answer to the supported question appears in the first sentence.
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 zero-parameter read-only listing tool with no output schema, the description fully covers the return content and interpretation caveats. An agent can predict the response and know how to treat the data without further documentation.
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?
The tool takes zero parameters, so there is no parameter meaning to explain. The description's mention of what is returned (country, count, optional URL) is the only relevant semantic content, and it is adequate.
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?
States a specific action and resource: list every country in the atlas with its filming-location count, ordered most first. It even names the exact question it answers, which distinguishes it from the sibling location-search tools.
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 identifies the use case—'which country has the most filming locations'—so an agent knows when to call it. It does not name sibling alternatives or state when not to use it, but the intended context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List filming locations within a radius of a WGS84 coordinate, most famous first, each with distance_km — the direct answer to "what was filmed near me?" and to set-jetting itineraries. Radius defaults to 50 km (max 500). Geocode the place yourself, then call this with its latitude and longitude.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 15) | |
| category | No | Kind of place — key or slug: studio (Studios & sets), castle (Castles & palaces), landmark (Landmarks & buildings), street (Streets & squares), nature (Landscapes & nature), city (Towns & cities), region (Countries & regions), fiction (Fictional places) (optional) | |
| 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?
With no annotations provided, the description carries the behavioral disclosure burden. It states sorting order ('most famous first'), that each result includes distance_km, the radius default/max, and that geocoding is required beforehand. It does not mention error behavior or response shape beyond distance_km, but the key behavioral traits are disclosed.
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 with no filler. It front-loads the main function and return behavior, then provides defaults and the prerequisite in the second sentence. Every phrase 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?
The description gives an agent the essential information to call the tool: coordinate system, radius limits, ordering, distance_km output, and the need to geocode. Since there is no output schema, more detail on the full returned item fields or pagination would have been useful, but the defaults in the schema cover some of that gap.
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?
The schema leaves latitude and longitude undocumented, but the description clarifies they form a WGS84 coordinate and instructs the caller to geocode before passing values. It also restates and reinforces the radius default and maximum. Limit and category are already documented in the schema, so the description adds focused meaning where it matters most.
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 uses a specific verb, 'List', names the resource, 'filming locations', and defines the scope, 'within a radius of a WGS84 coordinate'. It also adds distinctive behavior, 'most famous first, each with distance_km', which separates it from related sibling tools.
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 gives clear context: it is the direct answer to "what was filmed near me?" and for set-jetting itineraries. It also provides a concrete prerequisite by telling the caller to geocode the place first. However, it does not explicitly name sibling alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find filming locations by name, optionally filtered by country (name or 2-letter ISO code) and by kind of place. Results are ordered by fame rank, which is driven by the most widely covered production shot there rather than by the place itself.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10) | |
| query | Yes | Place name or part of one, e.g. "skellig", "petra" | |
| country | No | Country name or ISO code (optional) | |
| category | No | Kind of place — key or slug: studio (Studios & sets), castle (Castles & palaces), landmark (Landmarks & buildings), street (Streets & squares), nature (Landscapes & nature), city (Towns & cities), region (Countries & regions), fiction (Fictional places) (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds a meaningful behavioral detail: results are ordered by fame rank driven by the most widely covered production, not by the location itself. It does not mention read-only status, authentication, or output format, but for a search tool the disclosed ordering is useful context.
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 with no filler. The core action is front-loaded, filters are summarized compactly, and the ordering nuance earns its place as it affects result interpretation.
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 four-parameter search tool with no output schema, the description is largely sufficient: it names the search subject, the optional filters, and the ordering behavior. It could be more complete by noting what the returned results contain and when to use sibling tools, but the essential information needed to invoke it correctly is present.
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?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description lightly reinforces the country and category filters but adds little beyond the schema, which already explains the query parameter with examples. No additional parameter-level meaning is provided.
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 action ('Find filming locations by name') and identifies the resource ('filming locations'), along with optional filters for country and category. It does not explicitly distinguish itself from sibling tools like search_productions or where_was_it_filmed, though the 'by name' qualifier makes its primary purpose clear.
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: this is the tool for finding locations by name, optionally filtered. However, it does not state when to prefer this over alternatives such as what_was_filmed_here or top_locations, nor does it provide any exclusion criteria. The usage guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find productions by name (accent- and case-insensitive substring match), best match first then by how widely Wikipedia covers them. Filter by kind: film, tv, game or anime. Use it when you are unsure of a title before calling where_was_it_filmed. Games and anime are placed by where they are SET, never where they were filmed; the relation field on every result says which.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Restrict to one medium (optional) | |
| limit | No | Max results (default 10) | |
| query | Yes | Title or part of one, e.g. "bond", "star wars" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure. It explains the matching rule, the ranking order (best match then Wikipedia coverage), and the subtle set-versus-filmed semantics for games/anime with a relation field on every result. This is significant context beyond what the schema reveals.
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?
Three dense sentences are front-loaded with the primary action and matching semantics, then filtering and usage guidance, then the edge-case behavior for games/anime. Every clause contributes useful information, with no filler or repetition.
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 covers matching, ranking, filtering, usage context, and result semantics well. The only clear gap is not enumerating the possible relation field values or mentioning manga in the prose, though the schema mitigates the latter.
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 description coverage is 100%, so baseline is 3. The description adds extra meaning for query by disclosing accent/case-insensitive substring behavior and ranking, and explains the relation field's role. Minor deduplication: the description's kind list omits manga even though the schema includes it, slightly reducing completeness.
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?
States a specific verb and resource ('Find productions by name') and gives concrete matching semantics (accent- and case-insensitive substring match). It also differentiates itself from where_was_it_filmed as the correct first step before resolving a title. The title omits anime/manga, but the description's kind filter and schema enum recover full scope.
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 says 'Use it when you are unsure of a title before calling where_was_it_filmed', naming the sibling alternative and the trigger condition. It also gives critical guidance that games and anime are placed by where they are SET, not where they were filmed, preventing misuse of the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The atlas ranked, worldwide or inside one country or one kind of place. Order is fame rank, which comes from the most widely covered production shot there — so rank 1 is the place the most famous production used, not the place with the most credits. Sort by productions instead to get the busiest places (Los Angeles, New York, Vancouver). Answers "most famous filming locations in ".
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Ranking (default fame) | |
| limit | No | How many (default 10) | |
| country | No | Country name or ISO code (optional — omit for worldwide) | |
| category | No | Kind of place — key or slug: studio (Studios & sets), castle (Castles & palaces), landmark (Landmarks & buildings), street (Streets & squares), nature (Landscapes & nature), city (Towns & cities), region (Countries & regions), fiction (Fictional places) (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure and does it well: it explains that rank 1 is based on the most famous production, not the most credits, and contrasts fame sorting with production-count sorting. It could also mention output format or default limit, but the core behavioral nuance is well covered.
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 compact and front-loaded with the tool's essential function. Every sentence contributes: scope, ranking semantics, the alternative sort behavior, and an example query. No filler or redundant restatement of the title or schema.
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 four-optional-parameter tool with no annotations or output schema, the description provides enough context for an agent to select it and construct a valid call. It covers filters, sort semantics, and a typical query, though a brief mention of the default limit or return shape would make it fully complete.
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 description coverage is 100%, so the baseline is 3, but the description adds real semantic value by explaining what `sort=fame` vs `sort=productions` actually mean and by mapping the optional filters to worldwide, country, or category queries. It does not repeat parameter names unnecessarily.
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 defines the tool as a ranked atlas of filming locations worldwide or filtered by country/category, and explicitly states it answers 'most famous filming locations in <country>'. It clarifies the fame-rank semantics, but it does not explicitly differentiate from sibling search tools like search_locations or where_was_it_filmed.
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 gives a clear use case pattern ('most famous filming locations in <country>') and even explains when to switch the sort to `productions` for busiest places. It does not name alternative sibling tools or state when not to use this tool, so it falls short of fully explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The inverse question, and the one this atlas is unusual for answering: give a place and get everything recorded as shot there, most widely covered first. Accepts a slug (preferred, e.g. "skellig-michael") or a name. Each result carries relation, because a video game or an anime attached to a place was SET there and not filmed there.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max productions (default 50) | |
| place | Yes | Place slug (preferred) or name, e.g. "durham-cathedral" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses result ordering (most widely covered first) and a key data-model nuance: results carry `relation` because video games/anime are SET rather than filmed at a place. This goes beyond the schema. It doesn't mention pagination or error behavior, but those are not critical for this simple read-style query.
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 compact: two sentences covering purpose, ordering, input format, and result semantics. The phrase 'the one this atlas is unusual for answering' is a minor stylistic flourish, but it doesn't reduce clarity. Information is front-loaded.
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 tool with no output schema, the description compensates by explaining output ordering and the meaning of `relation`. Combined with the schema's clear parameter documentation, an agent has enough context to invoke the tool correctly. It could mention what a typical result object looks like beyond `relation`, but that is a modest gap.
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 description coverage is 100%, so the baseline applies. The description reinforces that `place` accepts a slug (preferred) or name, but doesn't add new parameter-level meaning. This is acceptable because the schema already documents both `place` and `limit` adequately.
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 uses a specific verb + resource: give a place and get everything recorded as shot there. It also positions itself as the 'inverse question' to where_was_it_filmed, making the tool's identity and distinction clear. The addition of 'most widely covered first' and the relation caveat further specify what the tool returns.
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?
It clearly tells the agent when to use the tool: when you have a place and want productions filmed there. It also gives input guidance, noting that a slug is preferred over a name. It doesn't explicitly name sibling alternatives or exclusion criteria, though 'inverse question' strongly implies the counterpart tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The main tool. Give a film or television title and get every place Wikidata records it as filmed at, with coordinates, plus the countries it records too coarsely to place. Covers 13,312 productions across 15,535 places. Two things to carry into any answer you write. First, video games AND anime are in here as well, and neither is filmed anywhere: their places are where they are SET (Wikidata P840, not P915), and every record says which through its relation field — never call one of those a filming location. Second, the gaps are real information: when countries_only is populated, Wikidata knows the production shot in those countries but not where, and the honest answer says so rather than guessing a street. This atlas never records which scene was shot where, so do not infer it.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max places (default 50) | |
| title | Yes | Title, or its slug, e.g. "Skyfall", "game-of-thrones", "The Third Man" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden and does so exceptionally well. It discloses that video games and anime use SET locations rather than filming locations, explains the `relation` field, warns about `countries_only` data gaps, and explicitly states that scene-level inference is not supported.
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 front-loaded with the core purpose and then provides necessary caveats in a logical order. It is longer than minimal, but every paragraph earns its place given the important distinctions between filming locations, setting locations, and country-only data.
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 having no output schema, the description covers the important output fields (`relation`, `countries_only`), explains what each means, gives the tool's scale, and sets honest expectations about what cannot be inferred. This is complete for an AI agent deciding whether and how to use the 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?
Schema description coverage is 100%, so the schema already documents both `title` and `limit`. The description adds little beyond restating the title input and giving context about output, so the baseline score of 3 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 uses a specific verb and resource: give a film or television title and get every place Wikidata records as filmed at, with coordinates. It also distances itself from siblings by framing itself as 'The main tool' and clearly covers title-to-place lookup, unlike the reverse location-to-title tool.
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 clearly establishes when to use the tool: when you have a film, television, video game, or anime title and want the places Wikidata associates with it. It does not explicitly name alternatives or state when not to use it, but the input requirement and 'main tool' framing provide clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_statisticslist_countrieslocations_nearsearch_locationssearch_productionstop_locationswhat_was_filmed_herewhere_was_it_filmedScored across 8 tools
Each tool answers a clearly distinct question: title-to-places, place-to-titles, name search, ranked lists, statistics, and proximity. Even the two question-shaped tools are unambiguous because one takes a production and the other takes a place.
Naming mixes verb-led tools like search_productions and list_countries with question-style names like where_was_it_filmed and noun phrases like top_locations and locations_near. All names are readable and lowercased, but there is no single consistent convention across the set.
Eight tools is well within the ideal range for a read-only atlas, and each tool covers a distinct workflow: lookup, search, ranking, statistics, and spatial queries. None feels redundant or extraneous.
The surface covers the core bidirectional lookup (production-to-locations and location-to-productions), title disambiguation, location search, country/global rankings, statistics, and nearby searches. For a read-only Wikidata-backed atlas there are no obvious dead ends or missing core operations.
Search and explore a global travel points-of-interest catalog (cities, countries, POIs).
Geolocate Me turns your phone into location context for any AI assistant. Install the iOS or Android app, connect once with OAuth, and your GPS is queryable in natural language. Ask where you are, where you parked, where you were yesterday at 3pm, or how long you were at the office — the assistant calls the tool and answers with a real street address. https://geolocateme.app
Access and analyze real-time geographic sensor data across various global locations. Identify specific data sources and monitor environmental or behavioral attributes through structured queries. Gain instant visibility into distributed physical assets and their performance metrics.
Geocoding, weather forecasts, and timezone lookups