一个用于 FilmMap 地图集的 Model Context Protocol 服务器：161 个国家的 15,272 个真实拍摄地点，与记录在这些地点的 12,762 部电影、剧集、电子游戏、动漫和漫画 相关联，包含坐标、知名度排名、每个地点的制作列表以及每项声明背后的来源。
它已经在运行。将客户端指向托管端点——无需安装、无需注册、无需 API 密钥：
https://thefilmmap.com/mcpStreamable HTTP，无状态，仅 POST（GET 返回 405 是正确的）。
{
"mcpServers": {
"filmmap": {
"type": "http",
"url": "https://thefilmmap.com/mcp"
}
}
}Related MCP server: slugline-mcp
工具 | 功能 |
| 给出标题，获取其拍摄地点，每个地点附有证据 |
| 反向查询，也是这个地图集不寻常之处：给出地点，获取所有记录为在此制作的内容 |
| 按名称查找制作，不区分重音和大小写，最佳匹配优先 |
| 按名称查找地点，可按国家或地点类型筛选 |
| WGS84 坐标半径内的地点，每个带有 |
| 地图集排名，全球范围或某个国家或某种地点类型内 |
| 每个国家及其拥有的拍摄地点数量 |
| 实时聚合——按媒介和地点类型的总数、热门国家、最繁忙地点 |
在将其接入任何生成散文的内容之前，这部分值得一读。
电影和剧集按 拍摄地点 (P915) 放置。电子游戏、动漫和漫画没有拍摄地点，因此它们按 叙事地点 (P840) 放置——即故事发生地——每条记录都会说明其携带的是哪种关系。将两者混为一谈会发布虚假声明。
地点不是场景。 P915 记录的是制作在某地拍摄，仅此而已。哪个场景在哪里拍摄不在数据中，也不得从中推断。
两种证据，绝不合并。 大多数链接是 Wikidata 陈述。有些是制作在英文维基百科 Filming 部分中提到的地点，或其编辑者归入的设定分类；这些会出现在各自的字段中，并标注其来源的确切文章和章节。重复时请说“根据维基百科”。
覆盖不均衡，服务器也如此说明。 834 部制作仅记录到国家级别，显示国家而无坐标。另有 3,906 部完全无法定位；它们作为工作清单发布在 thefilmmap.com/gaps/ 上，以便在 Wikidata 上修复。
基于 Wikidata 构建，照片来自 Wikimedia Commons，文章文本以链接而非捆绑方式提供。事实记录为 CC0，可从 thefilmmap.com/data 下载为 GeoJSON 和 CSV，也镜像在 GitHub 上。
服务器读取一个文件 atlas-compact.json，这是站点自身的线格式，每次部署时都会重建。
ATLAS_JSON=/path/to/atlas-compact.json PORT=8896 node server.mjs或者使用 Docker，它会将地图集的公开副本烘焙到镜像中：
docker build -t filmmap-mcp .
docker run -p 8896:8896 filmmap-mcp # → http://localhost:8896/mcpHOST 默认为 127.0.0.1；容器设置为 0.0.0.0，因为默认值在容器外部无法访问。
服务器采用 MIT 许可证。其提供的数据集为 CC0；通过 URL 引用的照片和维基百科文本保留其各自的许可证。
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.
Location understanding for AI agents: words in, one verified location out. Beta: contiguous US.
Mobility, geocoding and nearby urban services for AI agents.
Search and explore a global travel points-of-interest catalog (cities, countries, POIs).
Film/TV public-record rights intelligence for AI agents with provenance and bounded verification.