Where films and TV were shot, and where games, anime and manga are set. Wikidata, read only, CC0.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 8 of 8 tools scored.
Each tool carves out a distinct query: the production↔place bidirectional pair (where_was_it_filmed / what_was_filmed_here) is symmetric rather than overlapping, and search vs. near vs. rankings vs. aggregates all serve clearly different lookups. The three can-support overview tools (list_countries, top_locations, get_statistics) are differentiated by granularity and use case.
The dominant pattern is verb_noun (get_statistics, list_countries, search_locations, search_productions), but top_locations breaks the verb-verb convention, locations_near is noun-adjective, and what_was_filmed_here / where_was_it_filmed are sentence-style question phrases. Everything is snake_case and memorable, but the verb-first consistency is not maintained.
Eight tools is a well-scoped surface for a filming-locations atlas. Each tool earns its place and covers a distinct query type (by title, by place, by coordinate, by ranking, by country, by statistic) without bloat.
The core bidirectional query surface is fully covered—production to places, place to productions, plus geospatial, rankings, country aggregates, and headline statistics. Minor gaps exist (e.g., no browse-by-country for productions, no way to filter what_was_filmed_here by kind), but the descriptions' explicit handling of data absences shows a mature, well-considered surface.
get_statisticsAtlas statisticsAInspectHeadline 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?
No annotations are provided, so the description carries the full burden. It discloses that figures are 'computed live' (implying real-time calculation) and includes specific details about the data source (productions recorded only at country level). It doesn't mention performance, caching, or error behaviors, but for a read-only statistics tool, the provided details are sufficient.
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 single, well-structured sentence that front-loads the key function ('Headline figures computed live from the atlas') and then provides detail. No fluff; each clause conveys meaningful information.
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 parameters and no output schema, the description fully explains what the tool returns and the context of use. It's complete for an agent to decide when to call it and what to expect. The tool's complexity is low, so the description is adequate.
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, which simplifies semantics. The schema description coverage is 100% (no params), so the description doesn't need to explain parameter meanings but it effectively tells the agent what the tool returns (the aggregate figures). This adds value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes headline figures from the atlas, including specific aggregates (totals by medium, kind of place, top countries, busiest/most famous locations, and the number of productions only recorded at country level). The verb 'computed live' and resource 'atlas' provide a specific purpose, and it distinguishes itself from sibling tools that likely return lists or locations rather than aggregate statistics.
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 use when aggregate claims about the dataset are needed, stating 'The source for any aggregate claim about this dataset.' It doesn't explicitly contrast with siblings, but the focus on aggregate counts and the explicit 'cannot place' statistic clarifies a specific use case. However, it lacks explicit when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_countriesCountries with location countsAInspectEvery 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 provided, the description carries the full burden. It discloses that coverage is uneven and skewed to Europe and North America, and warns that data reflects Wikidata records rather than a complete inventory. This is valuable behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and sorting order, then adds the URL detail and data caveat. Every sentence earns its place with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description covers the key aspects: what it returns (countries with counts and URLs), how it's sorted, and the data quality caveat. It's complete for a simple list 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?
The tool has zero parameters, so the description doesn't need to explain parameters. The baseline for 0 params is 4, and the description appropriately focuses on output semantics instead.
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 lists every country in the atlas with filming location counts, sorted most first, and explicitly answers the question 'which country has the most filming locations'. It distinguishes itself from siblings by focusing on country-level aggregation rather than location search or statistics.
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 when to use this tool (to answer country-level questions about filming locations) and provides context about data coverage. It doesn't explicitly name alternatives, but the sibling list and the clear purpose make the usage context clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
locations_nearFilming locations near a pointAInspectList 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) (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?
No annotations are provided, so the description carries the burden. It discloses the sorting (most famous first), the distance field (distance_km), and the radius default (50 km, max 500). It does not mention rate limits, authentication, or what happens with invalid coordinates, but for a read-only list tool this is acceptable. It does not contradict any annotations (none present).
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: a clear functional statement with sorting and output details, followed by the default/limit and a direct instruction to geocode first. Every sentence adds value, and it is front-loaded with the primary action.
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?
This is a straightforward proximity query tool with no output schema, but the description covers the key output (distance_km), sorting (most famous first), and constraints (radius bounds and default). Given the low complexity and no nested objects, the description is complete for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60% (limit and radius_km have descriptions, but latitude/longitude and category do not). The description adds context beyond the schema: it explains that the radius is in km, default 50, and mentions the distance_km field. It also mentions the famous-first ordering which relates to the limit. It compensates for missing schema descriptions for lat/long by explaining they are WGS84 coordinates. Category is listed but not explained fully—though the schema includes an inline list of allowed values, rendering the description's mention 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?
The description specifies a concrete action: 'List filming locations within a radius of a WGS84 coordinate, most famous first, each with distance_km'. It clearly identifies the resource (filming locations) and the distinguishing behavior (proximity search with distance output), which sets it apart from siblings like 'search_locations' and 'what_was_filmed_here' by emphasizing the proximity and radius concept.
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 states a clear use case: 'the direct answer to "what was filmed near me?" and to set-jetting itineraries' and provides a prerequisite: 'Geocode the place yourself, then call this with its latitude and longitude.' It lacks explicit guidance on when NOT to use it or which sibling to use instead, but the context is sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_locationsSearch filming locations by nameAInspectFind 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) (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the ordering behavior (by fame rank) and mentions optional filtering, providing good transparency without annotations.
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 concise, two sentences, and directly states the purpose and key behaviors without unnecessary detail.
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 covers the main functionality and ordering but does not specify the return format, though that may be implied for a search tool; overall it is sufficiently complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides detailed descriptions for all parameters, and the tool description does not add significant extra meaning beyond the schema, so baseline 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 clearly states that it finds filming locations by name, with optional filters for country and kind of place, distinguishing it from other location-based 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 implies usage when searching by name but does not explicitly mention alternatives or when not to use it, so it provides only implied usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_productionsSearch films, series and games by nameAInspectFind 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, the description discloses accent/case-insensitive matching, result ordering (best match first, then Wikipedia coverage), and the special set-vs-filmed behavior for games/anime. The mention of the `relation` field adds useful behavioral context beyond a simple search.
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, each earning its place: purpose and matching rules, usage guidance with alternative, and special-case behavior for games/anime. No filler or repetition of schema details.
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 no output schema, the description covers purpose, usage, filters, and a critical exception. It hints at result structure via the `relation` field, but doesn't fully list return fields or pagination behavior. Still, it provides enough context for correct tool invocation.
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 already provides full parameter descriptions (100% coverage), so baseline is 3. The description adds value by explaining the `kind` filter semantics, giving query examples ('bond', 'star wars'), and clarifying the `relation` field concept, which helps distinguish results.
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 'Find productions by name' and specifies substring matching behavior. It distinguishes itself from sibling `where_was_it_filmed` by positioning itself as the pre-step for uncertain titles, and enumerates the kind filter options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use it when you are unsure of a title before calling where_was_it_filmed', giving a direct when-to-use instruction and an alternative. It also clarifies that games/anime are set-based, which prevents misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
top_locationsThe most filmed placesAInspectThe 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) (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that rank is based on the most widely covered production shot, not total credits, and explains sorting by 'productions' yields busiest locations. This adds meaningful behavioral nuance beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and key distinction, no fluff. Every clause adds value, making it highly efficient for agent parsing.
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 tool has only optional parameters and no output schema. The description explains ordering semantics and typical queries, which is sufficient for selecting and invoking correctly. It doesn't detail return format, but that's not required given the complexity.
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%, giving baseline 3. The description adds value by explaining the semantic difference between 'fame' and 'productions' sorting and clarifies that rank 1 is the most famous production used, not the most credits. It also implies country/category usage via the example question.
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 ranks places by fame or productions, worldwide or filtered by country/category. It explicitly differentiates from siblings like search_locations (search vs ranking) and locations_near (proximity), using specific verbs and 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?
The description says it answers 'most famous filming locations in <country>' and instructs to sort by productions for busiest places, providing clear usage context. It lacks explicit when-not-to-use guidance for alternatives, but the context is strong enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
what_was_filmed_hereWhat was filmed at a placeAInspectThe 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?
Since no annotations are provided, the description carries the full burden. It discloses that results are ordered by widest coverage, and importantly notes that each result carries a 'relation' field because some entries (video games, anime) were not filmed but SET there. This adds useful behavioral context beyond simple listing, but doesn't cover other aspects like pagination or error behavior.
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 three sentences, front-loaded with the core purpose, and each sentence earns its place: purpose, usage specifics, and a critical behavioral note. No filler or redundancy.
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 two-parameter tool with rich schema descriptions and no output schema, the description is fairly complete. It explains the query format, the order of results, and a key semantic detail about the 'relation' field. Could mention pagination or limit default, but the schema covers that. Overall adequate for the complexity.
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 already provides 100% coverage with descriptions for both parameters. The description adds a bit of context about slug preference and examples, but mostly reiterates what the schema says. The baseline is 3 because schema coverage is high; the description adds some nuance but not substantial extra meaning.
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 explicitly states the tool answers the inverse question of 'where was it filmed' by taking a place and returning everything recorded as shot there, listing results with most widely covered first. It clearly identifies the verb+resource (returns productions for a place) and distinguishes itself from the sibling tool where_was_it_filmed by framing it as the inverse question.
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 explains that this is the inverse of 'where_was_it_filmed' and specifies that a slug is preferred over a name, offering examples. It doesn't explicitly state when not to use it or list alternatives, but the clear context of the inverse question and the example usage provide adequate guidance. Sibling name helps but no direct comparison to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
where_was_it_filmedWhere a film, series or game was filmedAInspectThe 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 12,772 productions across 15,254 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 warns that video games and anime are 'SET' not 'filmed', introduces the 'relation' field, explains that 'countries_only' indicates coarse geographic knowledge, and states that scene-level detail is never recorded. This is exemplary transparency about data quirks and interpretation.
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 main purpose and then details important caveats. It is somewhat verbose, including statistics (12,772 productions) and multi-sentence warnings, but every sentence contributes valuable context. It earns a 4 rather than 5 due to length.
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 there is no output schema, the description does an excellent job of explaining what the response includes (places with coordinates, countries_only, relation field) and its limitations (no scene-level data). It does not mention pagination or how the limit parameter shapes output, but that is a minor gap given the strong overall context.
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 already documents both parameters (title, limit) with descriptions and constraints, achieving 100% schema coverage. The tool description does not add further semantic value for the parameters beyond what the schema provides, so the baseline 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 clearly states the tool's function: given a film or television title, it returns every place Wikidata records as filmed at, with coordinates, plus countries recorded too coarsely. It is specific about the resource and output, but does not explicitly distinguish from sibling tools like what_was_filmed_here or locations_near, so it falls short of a 5.
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 calls itself 'The main tool' and implies it is the primary entry point for location lookups, but it does not provide explicit when-to-use vs. alternative guidance. It focuses on interpreting results rather than selecting the tool among siblings, so usage guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.