Where films and TV were shot, and where games, anime and manga are set. Wikidata, read only, CC0.
Scored across 8 tools
Each tool targets a clearly distinct query: get_statistics (aggregates), list_countries (counts by country), locations_near (radius search), search_locations (by name), search_productions (by title), top_locations (ranked lists), what_was_filmed_here (place→productions) and where_was_it_filmed (title→places). The inverse pair and the search/list pair have non-overlapping inputs, so misselection is unlikely.
All names are snake_case and mostly follow a verb_noun or noun-phrase pattern (get_statistics, list_countries, search_locations, search_productions, top_locations, locations_near). The two question-style names (where_was_it_filmed, what_was_filmed_here) deviate but are readable and arguably deliberate for the inverse-lookup tools.
Eight tools is well-scoped for a read-only filming-location atlas, with each tool covering a distinct access path (aggregate, geographic, name, title, ranked, inverse). No tool feels redundant or missing from the count.
The surface covers discovery (search/lists/top), geographic proximity, and both directions of the place↔production relationship, plus statistics. Minor gap: no dedicated single-location detail endpoint, though what_was_filmed_here largely fills it; read-only scope means create/update/delete are appropriately absent.
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 23,531 productions across 31,111 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 and no output schema, the description carries the full burden and does so well: it names the underlying Wikidata properties (P840 vs P915), describes the `relation` and `countries_only` fields, and states a hard limitation (no scene-level data). It discloses provenance and caveats an agent needs to answer honestly, which is exactly the kind of context structured fields don't supply here.
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?
Purpose and scope are front-loaded, and the two critical caveats (set-vs-filmed, honest gap reporting) are called out explicitly. It is somewhat verbose with the metatextual 'two things to carry into any answer' framing, but nearly every sentence delivers actionable guidance, so the length is largely justified.
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 and no annotations, the description covers what it returns (places with coordinates, country-only records, a `relation` field) and its semantic limits. Minor gaps remain: it doesn't say how a missing/ambiguous title behaves or mention result ordering, but nothing essential to invoking it correctly is absent.
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 both `title` (with slug examples) and `limit` (default 50, max 200) are already documented in the schema. The description adds no parameter-level detail beyond what the schema provides, matching the baseline 3 for full schema coverage.
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 concrete verb+resource: give a film/TV title and get every filming place Wikidata records, with coordinates and country-level fallbacks. It also scopes the corpus precisely (23,531 productions, 31,111 places) and clarifies that games/anime are included as SET locations, which an agent could not guess from the name alone. This cleanly separates it from the sibling tools that go the reverse direction (what_was_filmed_here).
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?
Gives clear when-to-use context (any title, including games/anime) and strong interpretive rules: use `relation` to distinguish filmed-at from set-in, and report `countries_only` as a known gap rather than guessing. It does not explicitly name or contrast the alternatives (e.g. what_was_filmed_here, search_productions), so routing between siblings is left partly to inference.
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.
locations_near1 field changedInput schema / properties / category / descriptionPrevious value: -"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) (optional)"New value: +"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)"search_locations1 field changedInput schema / properties / category / descriptionPrevious value: -"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) (optional)"New value: +"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)"search_productions1 field changedInput schema / properties / kind / enumPrevious value: -[
- "film",
- "tv",
- "game",
- "anime"
-]New value: +[
+ "film",
+ "tv",
+ "game",
+ "anime",
+ "manga"
+]top_locations1 field changedInput schema / properties / category / descriptionPrevious value: -"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) (optional)"New value: +"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)"get_statisticslist_countrieslocations_nearsearch_locationssearch_productionstop_locationswhat_was_filmed_herewhere_was_it_filmedPlaces worth a detour, from Wikidata: search, nearby lookup, fame rankings, stats. No key, CC0.
Castles, fortresses, palaces and ruins worldwide: search, nearby, fame ranking, statistics. CC0.
Wikidata <-> OpenStreetMap reconciliation.
Media memory for AI agents and their humans: books, movies, music, shows, anime, podcasts, games.
Add one secure layer between your agents and this server.
