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 distinct query type: aggregate stats, country counts, proximity search, name search, production search, rankings, and the two inverse place/production lookups. The only mild overlap is between get_statistics and list_countries, both of which surface country-level counts, but their descriptions make the distinction clear.
Naming conventions are mixed: get_statistics and list_countries use verb-first patterns, search_locations and search_productions use search_, but locations_near starts with a noun and what_was_filmed_here/where_was_it_filmed are full question phrases. The names are readable and mostly intuitive, but they do not follow a single predictable pattern.
Eight tools is well-scoped for a filming-locations atlas. Each tool covers a clearly useful query mode without redundancy, and the set feels appropriately sized for the domain.
The tool surface covers the core user journeys: find a production's locations, find what was filmed at a place, search by name, search near coordinates, get rankings, and retrieve country and aggregate statistics. The descriptions explicitly acknowledge data limitations like country-only records and scene-level absence, so no obvious dead ends remain.
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 14,549 productions across 18,697 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 the full burden of behavioral disclosure. It explicitly discloses that games and anime are SET not filmed (via the relation field), that countries_only indicates coarse country-level data with a caution against guessing a street, and that scene-level information is never recorded to prevent inappropriate inference. These are significant behavioral traits that an agent must know to avoid errors, and they are clearly stated.
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 a paragraph but each sentence earns its place: the core action, the coverage numbers, and the two critical caveats. It is front-loaded with the primary purpose before diving into nuance. While slightly verbose, it avoids redundancy and the length is justified by the tool's complexity. It could be trimmed without loss, but it remains structured and scannable.
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 mixed entity types (films, games, anime), ambiguous 'filmed' vs 'set', and coarse country data, the description covers all essential knowledge an agent needs to call and interpret results correctly. It even warns against a common hallucination (inferring specific streets). There is no output schema, so the description's description of return values is sufficient. The completeness is high.
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 both parameters (title and limit) with clear descriptions, giving 100% coverage. The tool description adds contextual semantics about the relation field and output, but does not add detail about parameter values, defaults, or formats beyond the schema. This meets the baseline of 3 since the schema does the heavy lifting.
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 states a specific verb ('Give') and a specific resource ('a film or television title'), and clearly describes the output: every place Wikidata records as filmed at, with coordinates, plus coarse countries. It preemptively differentiates from siblings like what_was_filmed_here by emphasizing it is 'the main tool' and covering games/anime, which no sibling does. The purpose is unambiguous and action-oriented.
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 ('Give a film or television title') but does not explicitly contrast with alternatives such as what_was_filmed_here or search_productions. The phrase 'The main tool' gives a weak signal of primacy, but there is no explicit when-to-use / when-not-to-use guidance or naming of sibling tools. The caveats about games/anime and countries_only are data-interpretation guidance, not tool-selection guidance.
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.
Open manufacturing and maker facility locations for country and facility-type queries.
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.
