mmoagent-mcp
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation5/5
Each tool has a clearly distinct purpose: dashboard, conversion, farming advisor, trend analysis, portfolio, and search. No overlap.
Naming Consistency5/5All tools follow the 'mmo_' prefix with descriptive snake_case names, e.g., mmo_economy_dashboard. Consistent pattern.
Tool Count5/56 tools cover a specialized domain (MMO economy) without being too many or too few. Well-scoped.
Completeness5/5Covers macro dashboard, currency conversion, farming advice, trend analysis, portfolio, and unified search. Comprehensive for cross-game economy.
Average 3.5/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavior. It suggests a read-only analysis but does not explicitly state read-only nature, authentication needs, rate limits, or whether it modifies data. The description gives a general sense but lacks necessary behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, with the core purpose front-loaded. The second sentence is a question that adds tone but not essential information. Slightly more could be achieved without the question, but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 simple parameter enums and no output schema, the description provides a good overall context but lacks details on what the response contains, how to interpret results, and does not cover parameter options. It is incomplete for a tool with no other documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with enums but no descriptions, and the description does not mention or explain them. With 0% schema description coverage, the description should compensate but fails to provide any parameter semantics beyond the enum values themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is for cross-game meta trend analysis, specifically identifying items spiking across all MMOs and detecting global patterns. This distinguishes it from sibling tools like mmo_economy_dashboard (likely single-game) or mmo_gold_conversion (specific conversion).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for global trend analysis but does not explicitly state when to use this tool versus alternatives. It lacks guidance on when not to use it or which specific contexts it is best suited for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, leaving the description to cover behavioral traits. It indicates a read operation with prerequisites, but it does not disclose rate limits, data freshness, side effects, or behavior when 'games' parameter is used versus default (ALL).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's function, outputs, and a key prerequisite. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of aggregating across multiple MMOs and the lack of an output schema, the description omits critical details like return format, error handling, pagination, and whether the default is all games or filtered. Incomplete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33%). The description adds value for the overall purpose but does not explain the 'games' filter or 'include_history' parameter. The phrase 'ALL connected MMOs' contradicts the filtering capability, causing confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool aggregates a player's assets across MMOs, providing net worth, liquidity breakdown, and diversification recommendations. It uses specific terms and distinguishes from sibling tools like mmo_unified_market_search and mmo_economy_dashboard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the prerequisite 'Requires linked accounts' but does not explicitly state when to use this tool versus alternatives or provide when-not scenarios. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description must disclose behavioral traits. It only lists output items but does not state whether the tool is read-only, has side effects, or requires specific permissions. The agent must assume it is non-destructive, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a bullet list of outputs. It is front-loaded with the main action ('Get a macro-economic dashboard') and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not clarify parameter usage, return format, or typical response structure. For a tool with two parameters and no schema descriptions, more context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain the two parameters. The 'metric' and 'games' parameters are not described; the listed output items only partially overlap with the metric enum. The agent cannot understand how to use these parameters from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving a macro-economic dashboard across all supported MMOs. It lists specific metrics (inflation, currency valuations, RMT indices, etc.), distinguishing it from sibling tools like gold conversion or player portfolio by its broad overview nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a macro-economic overview, but does not explicitly state when to use this tool versus alternatives. No mention of exclusions or when-not scenarios, leaving the agent to infer based on other tools' names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 states the tool uses real-money equivalents and shows conversion rates, but fails to disclose behavioral traits like whether rates are real-time, if authentication is needed, idempotency, or any side effects. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core action, and wastes no words. It provides examples and output format efficiently. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 4 parameters, the description covers the core function and output (conversion amounts) but omits details on the region parameter, error handling, and example inputs/outputs. It is adequate but has clear gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (amount, from_game, to_game described; region not). The description adds context by listing specific currencies (e.g., WoW Token) that align with from_game and to_game, but does not elaborate on parameter formats or constraints beyond the schema. The third sentence explains the output, not parameters. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Convert in-game currency values across MMOs using real-money equivalents.' It uses specific verbs and resources, and lists example currencies (WoW Token, FFXIV Mog Station, etc.), making the purpose unambiguous and distinct from siblings like mmo_economy_dashboard or mmo_unified_market_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but provides no explicit guidance on when to use it versus alternatives. While the context is implied (convert currencies), it lacks exclusions or comparisons to sibling tools, such as when to use mmo_unified_market_search for detailed market data instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states 'Returns normalized results with cross-game price comparisons' and indicates simultaneous search across games. However, it does not cover authentication, rate limits, error handling, or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence states the action and scope, the second lists supported games and output type. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters and no output schema, the description covers the main purpose and output but lacks details on parameter usage (e.g., realm interaction, limit behavior) and normalization specifics. It is minimally complete for a search tool but could be richer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% (3 of 4 params have descriptions), and the description adds no additional meaning for parameters beyond what the schema already provides. It does not explain the 'realm' or 'limit_per_game' parameters, or how the 'games' filter default works.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Search' and a clear resource 'ALL supported MMO marketplaces simultaneously', listing six specific games. This distinguishes it from sibling tools like dashboards or conversions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use this tool: for multi-game market searches with cross-game price comparison. It implies coverage of all listed games but does not explicitly state when not to use it or mention alternatives for single-game searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 burden. It only says 'The AI compares ALL your games and tells you exactly where to farm for maximum ROI.' This hints at the behavior but lacks specifics about data sources, real-time updates, or authoritative backing. It is adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, and wastes no words. The example immediately engages the user and clarifies usage. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters with nested objects and no output schema, the description covers the main function and usage scenario well. It could be improved by describing the output format or limitations, but for a recommendation tool, it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and all parameters have descriptions, so baseline is 3. The description adds value by contextualizing parameters through an example, showing how player_games, time_minutes, and target value interact. This goes beyond the schema's individual descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is an 'AI farming advisor' that compares all user games to recommend the best farming location for maximum ROI. The concrete example 'I have 2 hours, I play WoW and OSRS, I want to make 50k gold equivalent' makes the purpose unmistakable. It distinguishes from siblings like mmo_economy_dashboard (likely data-focused) and mmo_gold_conversion (currency exchange).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear scenario for when to use the tool: when you have constraints (time, target currency) and want cross-game advice. It implicitly tells the user to describe their situation. However, it does not explicitly state when not to use it or mention alternatives, though sibling tools are listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/CSOAI-ORG/mmoagent-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server