A
licenseNot graded
qualityC
maintenanceGives LLMs structured access to Warhammer 40,000 (10th edition) game data: faction lists, unit datasheets, stratagems, detachments and enhancements.
MIT
FFT Companion
Server Details
Final Fantasy Tactics game data across the PSX, War of the Lions and Ivalice Chronicles releases
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Available Tools
8 toolscompare_versionsDiff a record across releasesAInspect
Compares the same entity across psx, wotl and ic and reports exactly which fields changed. Answers questions like "was this weapon nerfed in War of the Lions?" or "did Ivalice Chronicles lift the female-only restriction?" that otherwise require holding three datasets side by side. Free while this deployment runs unmetered.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Entity id, present in at least one version. | |
| kind | Yes | ||
| versions | No | Which releases to compare. |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clarifies the tool is read-only (compares, not modifies), reports exact field changes, and requires entity id and kind. Lacks details on edge cases like missing entities but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose and examples, no redundancy. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 params, no output schema, and complexity of cross-version diffing, the description covers purpose, usage, and output format (reports field changes). Examples and sibling differentiation make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (2 of 3 params described). Description adds value through examples and context, but does not significantly expand beyond schema descriptions for id, kind, and versions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it compares an entity across psx, wotl, and ic releases and reports field changes, with concrete examples like weapon nerfs or restrictions. Distinguishes from sibling tools by focusing on cross-version diffing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states when to use (comparing across releases) with examples, and mentions it's free while unmetered. Does not explicitly list when not to use or alternatives, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_item_sourcesFind where an item comes fromAInspect
Reverse lookup: every way to obtain a piece of equipment or a consumable — which outfitter unlocks it and after which battle, which monsters poach into it, and which treasure tiles hold it. This is indexed backwards from the game data and is not readable from the item record alone. Free while this deployment runs unmetered.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| itemId | Yes | Equipment or consumable id, e.g. 'excalibur'. | |
| version | Yes | Which release to read. psx = original PlayStation, wotl = War of the Lions, ic = The Ivalice Chronicles. Data differs meaningfully between them. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full weight. It discloses that the data is indexed backwards from game data and that the tool is free while unmetered. For a read-only lookup tool, this is adequate behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the purpose. Every sentence adds essential information: action, scope, technical detail, and status. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 required params and no output schema, the description sufficiently explains the purpose and parameters. It lacks details on return format, but for a reverse lookup tool the description is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by providing examples (e.g., 'excalibur') and expanding on the version enum with clear explanations of each option and noting data differences between versions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb "Reverse lookup" and clearly states the resource: every way to obtain an item. It lists specific sources (outfitter, monsters, treasure tiles), distinguishing it from sibling tools like get_monster or query_equipment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains this tool is for reverse lookup and is not readable from the item record alone, implying when to use it. However, it does not explicitly state when not to use it or mention alternatives, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_jobGet a job with abilities and equipment accessBInspect
Full job record: raw stat multipliers and growth, static move/jump/evasion, the complete learnable ability set with JP costs, and which equipment types the job can equip. Also returns the version's stat ceilings for normalization. Free while this deployment runs unmetered.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | en | |
| jobId | Yes | Job id, e.g. 'ninja', 'calculator', 'darkKnight'. | |
| version | Yes | Which release to read. psx = original PlayStation, wotl = War of the Lions, ic = The Ivalice Chronicles. Data differs meaningfully between them. |
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavior disclosure and does a reasonable job by enumerating the returned data and mentioning the stat ceilings for normalization. It does not mention failure modes, availability of invalid job IDs, or whether this is read-only, though the content strongly implies a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the record type before the details. The only slightly off-topic sentence is the free/unmetered note, but it is short and not disruptive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a data-fetch tool with no output schema, the description covers the main return fields, but an agent still lacks usage context: when this is preferable to search or query_equipment, how failures are surfaced, and what the lang parameter affects. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents jobId and version with example and enum details, and schema coverage is 67%, so a baseline of 3 applies. The description adds no parameter-specific meaning and does not cover the undocumented lang parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as the job record and enumerates its contents (stat multipliers, stat ceilings, abilities with JP costs, equippable types), making it clear what the tool returns. It is distinguishable from related getters like get_monster, though it lacks an explicit verb such as 'retrieves' or 'returns' at the start.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to prefer get_job over siblings like query_equipment, search, or compare_versions. The 'Free while this deployment runs unmetered' line is a cost note, not a selection criterion, so an agent has no exclusions or alternatives to reason with.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_monsterGet a monster with poach table and spawn locationsAInspect
Full monster record: stat multipliers and growth by rank, poach drops (common and rare), ability set, and the random-battle locations it appears in per chapter — including which map you must travel from. Free while this deployment runs unmetered.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | en | |
| version | Yes | Which release to read. psx = original PlayStation, wotl = War of the Lions, ic = The Ivalice Chronicles. Data differs meaningfully between them. | |
| monsterId | Yes | Monster id, e.g. 'behemoth', 'redPanther'. |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does explain the return content in useful detail and notes that the tool is free/unmetered, but it does not describe the output format, error behavior, or whether the call is read-only. This is acceptable for a retrieval tool but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the tool's purpose and enumerates the returned data, and the second provides cost context. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description appropriately lists the major return segments: stats/growth, poach drops, abilities, and per-chapter spawn locations with travel-from maps. This is enough for a caller to confidently invoke the tool, though it could be slightly richer by mentioning how version affects the record.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, and the schema already documents version and monsterId with helpful descriptions, while lang has an enum and default. The description adds no parameter-specific meaning beyond what the schema provides, but the schema is sufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly identify the resource ('monster') and the action ('get'), and the description enumerates the exact contents of the record: stat multipliers, growth by rank, poach drops, ability set, and spawn locations. This is specific enough to distinguish it from siblings like get_job, query_equipment, and get_records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when a caller needs a full monster record—but it never explicitly states when not to use it or names an alternative tool. There is no exclusionary guidance such as 'for records use get_records' or 'for equipment use query_equipment.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_recordsGet full records by idAInspect
Returns complete records for up to 25 ids of one entity kind, including stats, costs, effects and availability with all cross-references resolved to names. Free while this deployment runs unmetered.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Entity ids from search. | |
| kind | Yes | ||
| lang | No | en | |
| version | Yes | Which release to read. psx = original PlayStation, wotl = War of the Lions, ic = The Ivalice Chronicles. Data differs meaningfully between them. |
TDQS
A3.5/5.0
Behavior4/5
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 does this well by specifying output contents ('stats, costs, effects and availability'), a transformation ('cross-references resolved to names'), a hard limit ('up to 25 ids'), and operational cost context ('Free while this deployment runs unmetered'). It does not state failure behavior or explicitly confirm read-only semantics, but the information given is substantive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core behavior is front-loaded, followed by the batch limit and resolved-reference detail, then a concise operational note about cost. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 provides a decent sketch of returned content but not the actual record structure or error/partial-failure behavior. It also lacks routing guidance for sibling tools. The description is adequate for a straightforward batch read, but visible gaps remain around output format, language effects, and when to prefer specialized siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 2 of 4 parameters (ids and version), leaving kind and lang without schema-level descriptions. The description adds the important constraint that all ids must be 'of one entity kind,' clarifying the relationship between ids and kind. However, it does not compensate for the undocumented lang semantics or describe how kind values map to record types beyond the schema enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Returns complete records') and resource ('up to 25 ids of one entity kind'), and adds meaningful scope details such as included fields and resolved cross-references. It is sufficiently clear to distinguish a batch fetch from the singular get_job/get_monster siblings, though it never explicitly names or contrasts those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of siblings like search, query_equipment, get_job, or get_monster. The schema's ids description says 'Entity ids from search,' which implies a search-then-fetch flow, but the description itself does not state this workflow or any exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_versionsList game versionsAInspect
Lists the three Final Fantasy Tactics releases covered by this server and how many records exist per entity kind in each. Call this first to pick a version.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the tool's output scope (three releases, record counts) but omits other behavioral traits like authentication or cost. Adequate for a simple read-only list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the primary function, the second provides usage guidance. Highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is mostly complete for a simple tool with no parameters and no output schema. It could mention the output format briefly, but the essence is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4 per guidelines. The description adds no param info, which is acceptable given zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists the three Final Fantasy Tactics releases and record counts per entity kind, which is specific and distinguishes it from sibling tools like compare_versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Call this first to pick a version,' providing clear guidance on when to use the tool. Does not elaborate on when not to use it, but the context implies it's a prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_equipmentQuery equipment with filtersAInspect
Filters and sorts the equipment table — by category, weapon/armor type, cost, and stat thresholds. Use this instead of paging through get_records when shopping for "best X under Y gil". Free while this deployment runs unmetered.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | en | |
| limit | No | ||
| sortBy | No | Stat name to sort by, descending. Falls back to cost. | |
| maxCost | No | Maximum shop cost in gil. | |
| minStat | No | Minimum values per stat, e.g. { weaponPower: 10, magicAttack: 2 }. | |
| version | Yes | Which release to read. psx = original PlayStation, wotl = War of the Lions, ic = The Ivalice Chronicles. Data differs meaningfully between them. | |
| category | No | ||
| subCategory | No | Narrower type, e.g. 'katana', 'robe', 'hat'. |
TDQS
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose the core non-mutating behavior (filter/sort) and adds an unusual cost trait ('Free while this deployment runs unmetered'). However, it does not disclose return shape, default limit, sort direction/fallback, or pagination behavior, which matter for a query tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: function, usage guidance with a named alternative, and a cost disclosure. The core scoping statement is front-loaded, and each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately complex tool (8 parameters, nested minStat object, no output schema, no annotations), the description covers purpose, usage routing, parameter mapping, and cost. The version requirement and cross-release data differences are already captured in the schema's version description, so the description need not repeat them. The only real gap is the return shape, which the agent must infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 63%, so most parameters are already documented in the schema. The description adds an intent-level mapping (category → category, weapon/armor type → subCategory, cost → maxCost, stat thresholds → minStat) that helps the agent pick the right filter combination, but it does not add meaning beyond what the schema's per-parameter descriptions already provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Filters and sorts the equipment table') and enumerates the filter dimensions ('category, weapon/armor type, cost, and stat thresholds'), so an agent knows exactly what the tool does. It also differentiates itself from siblings like get_records (paging) and search (general lookup) without requiring schema inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence gives explicit routing guidance: 'Use this instead of paging through get_records when shopping for "best X under Y gil"'. This names the alternative tool and the exact condition that selects this one, leaving no inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch the catalogAInspect
Finds entities by name or id across equipment, abilities, jobs, monsters, bosses, locations and consumables. Returns ids and display names only — use get_records or a specific data tool to retrieve the actual data. Matches English, Japanese, Portuguese, Korean, Spanish, French and German names, and is punctuation-insensitive.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | en | |
| kinds | No | Restrict to these entity kinds. | |
| limit | No | ||
| query | Yes | Name or id fragment, e.g. 'excalibur', 'battle axe', 'ベヒーモス'. | |
| version | Yes | Which release to read. psx = original PlayStation, wotl = War of the Lions, ic = The Ivalice Chronicles. Data differs meaningfully between them. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does well: it discloses the limited return shape, the multilingual matching behavior, punctuation-insensitivity, and the entity scopes. It does not mention default version or limit semantics, but those are already present in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly written sentences: purpose/scope, output/alternative routing, and matching behavior. Every sentence earns its place and the core function is front-loaded with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is complete enough for correct invocation: it explains what is returned, how to get full data, which kinds are searched, and how matching behaves. Remaining details like limit and version are adequately defined in the input schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60%, and the description adds meaning beyond the schema for query, kinds, and lang: it names the seven entity kinds, lists supported languages, and clarifies name/id search. Limit is not described, but the schema already provides default, min, and max.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Finds entities by name or id across equipment, abilities, jobs, monsters, bosses, locations and consumables', a precise verb+resource statement. It also distinguishes itself from siblings by noting that it returns only ids and display names, and directs to get_records or specific data tools for full data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool: if you need ids/display names, use search; if you need actual data, use get_records or a specific data tool. This is a clear condition with named alternatives, though it does not discuss every sibling such as compare_versions or query_equipment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
5 tool updates
- Changed
get_job1 field changed- changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "ja", - "pt", - "ko", - "es", - "fr", - "de" -]New value: +[ + "en", + "ja", + "pt", + "ko", + "es", + "fr", + "de", + "zh-Hans", + "zh-Hant" +]
- Changed
get_monster1 field changed- changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "ja", - "pt", - "ko", - "es", - "fr", - "de" -]New value: +[ + "en", + "ja", + "pt", + "ko", + "es", + "fr", + "de", + "zh-Hans", + "zh-Hant" +]
- Changed
get_records1 field changed- changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "ja", - "pt", - "ko", - "es", - "fr", - "de" -]New value: +[ + "en", + "ja", + "pt", + "ko", + "es", + "fr", + "de", + "zh-Hans", + "zh-Hant" +]
- Changed
query_equipment1 field changed- changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "ja", - "pt", - "ko", - "es", - "fr", - "de" -]New value: +[ + "en", + "ja", + "pt", + "ko", + "es", + "fr", + "de", + "zh-Hans", + "zh-Hant" +]
- Changed
search1 field changed- changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "ja", - "pt", - "ko", - "es", - "fr", - "de" -]New value: +[ + "en", + "ja", + "pt", + "ko", + "es", + "fr", + "de", + "zh-Hans", + "zh-Hant" +]
5 tool updates
- Changed
get_job1 field changed- changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "ja", - "pt", - "ko" -]New value: +[ + "en", + "ja", + "pt", + "ko", + "es", + "fr", + "de" +]
- Changed
get_monster1 field changed- changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "ja", - "pt", - "ko" -]New value: +[ + "en", + "ja", + "pt", + "ko", + "es", + "fr", + "de" +]
- Changed
get_records1 field changed- changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "ja", - "pt", - "ko" -]New value: +[ + "en", + "ja", + "pt", + "ko", + "es", + "fr", + "de" +]
- Changed
query_equipment1 field changed- changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "ja", - "pt", - "ko" -]New value: +[ + "en", + "ja", + "pt", + "ko", + "es", + "fr", + "de" +]
- Changed
search1 field changed- changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "ja", - "pt", - "ko" -]New value: +[ + "en", + "ja", + "pt", + "ko", + "es", + "fr", + "de" +]
5 tool updates
- Changed
get_job1 field changed- changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "ja", - "pt" -]New value: +[ + "en", + "ja", + "pt", + "ko" +]
- Changed
get_monster1 field changed- changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "ja", - "pt" -]New value: +[ + "en", + "ja", + "pt", + "ko" +]
- Changed
get_records1 field changed- changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "ja", - "pt" -]New value: +[ + "en", + "ja", + "pt", + "ko" +]
- Changed
query_equipment1 field changed- changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "ja", - "pt" -]New value: +[ + "en", + "ja", + "pt", + "ko" +]
- Changed
search1 field changed- changed
Input schema / properties / lang / enumPrevious value: -[ - "en", - "ja", - "pt" -]New value: +[ + "en", + "ja", + "pt", + "ko" +]
8 tool updates
- First observed
compare_versions - First observed
find_item_sources - First observed
get_job - First observed
get_monster - First observed
get_records - First observed
list_versions - First observed
query_equipment - First observed
search
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Fantasy TTRPG data: metals, minerals, ingredients, potions, gems, craft rules, music catalogue.
Read-only Interlude and High Five NPC, loot, Soul Crystal and XP reference tools.
MHW MCP — Monster Hunter World data (mhw-db.com, free, no auth)
VALORANT reference data MCP (valorant-api.com).
Related MCP Servers
- FlicenseAqualityBmaintenanceProvides accurate competitive Pokémon information for Pokémon Champions, including damage calculation, type effectiveness, Pokémon data, and regulation legality checks.1210-
- AlicenseAqualityCmaintenanceProvides accurate Pokemon data and Gen 9 damage calculation tools including stats, moves, type effectiveness, damage calculations, and accuracy checks for Pokemon battles.8MIT
- FlicenseCqualityBmaintenanceEnables accurate Castle Clash queries by computing hero stats, skill damage, combat math, builds, and fight simulations from real game data and engine formulas instead of model guesses.47-
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A3.9/5.0
Disambiguation5/5
Each tool targets a distinct resource/action: compare_versions diffs releases, find_item_sources is a reverse-lookup, get_job/get_monster provide deep entity records, get_records is generic batch retrieval, query_equipment filters the equipment table, search resolves names to IDs, and list_versions describes the dataset. The descriptions explicitly call out when one tool should be used instead of another, so an agent should be able to pick correctly.
Naming Consistency4/5
Most tools follow a clear lower_snake_case verb_noun pattern (get_job, get_monster, get_records, list_versions, compare_versions, find_item_sources, query_equipment). The only deviation is the bare verb search, and the retrieval verbs vary (get/find/query/list) rather than being uniform, but the pattern is still predictable.
Tool Count5/5
Eight tools is a well-scoped size for a read-only game-data companion: a global search entry point, version metadata, generic batch retrieval, two deep-dive entity tools, an equipment filter, an item-source reverse lookup, and a cross-version comparator. No tool feels redundant, and every tool has a clear use case.
Completeness3/5
The server covers the main reference workflows well: discovery via search, batch retrieval via get_records, deep job/monster records, equipment shopping, item sourcing, and version comparison. However, there is no way to enumerate or filter non-equipment entity kinds (abilities, jobs, monsters, bosses, locations, consumables) without already knowing names/IDs, and compare_versions cannot identify which entities changed across versions. Those are notable gaps for a comprehensive companion server.