Marvel Rivals MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.0.6
Disambiguation4/5
Most tools have distinct purposes targeting different game aspects like heroes, maps, cosmetics, and player data, but some overlap exists: getHeroAbilities and getHeroInfo both provide hero details, and listItems and getItemsByType both handle cosmetics, which could cause minor confusion. Descriptions help clarify, but boundaries are not perfectly clear.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as getHeroAbilities, listHeroes, and searchPlayer. All names use camelCase uniformly, making them predictable and easy to parse for agents without any deviations in style.
Tool Count5/5
With 14 tools, the count is well-scoped for a game API covering heroes, maps, cosmetics, achievements, and player data. Each tool serves a specific function, and the number aligns with the comprehensive domain without feeling excessive or insufficient.
Completeness5/5
The tool set provides complete coverage for the Marvel Rivals game domain, including CRUD-like operations for heroes, maps, cosmetics, achievements, and player profiles. There are no obvious gaps; agents can access all essential data for strategies, customization, and performance tracking without dead ends.
Average 3.3/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It describes what data is returned but doesn't mention critical behavioral aspects like whether this is a read-only operation, pagination/limits on 'recent' matches, rate limits, authentication requirements, or error conditions. The description is insufficient for a tool with no annotation coverage.
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 efficiently structured in two sentences: the first states what data is returned, the second suggests use cases. Both sentences add value, though the second could be more specific. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain the return format (structure of match results), what 'recent' means (timeframe/limit), or behavioral constraints. For a data retrieval tool with rich sibling context, more completeness is needed.
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 100% with the single parameter 'identifier' documented as 'Player ID'. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'recent match results' with specific data elements (heroes played, performance metrics, map details, outcome), which is a specific verb+resource combination. It distinguishes from siblings like getPlayerProfile (likely general info) or listMaps (map catalog), but doesn't explicitly name alternatives for match history.
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 mentions 'tracks improvement and hero performance trends' which implies usage for analysis purposes, but provides no explicit guidance on when to use this tool versus alternatives like searchPlayer or getPlayerProfile. No when-not-to-use or prerequisite information is given.
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 the full burden of behavioral disclosure. It describes what data is returned but doesn't mention performance aspects (e.g., rate limits, latency), authentication needs, or potential errors (e.g., invalid identifier). For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 concise and front-loaded, with two sentences that efficiently convey the tool's purpose and parameter. Every sentence earns its place, though it could be slightly more structured (e.g., separating purpose from parameter info).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (retrieving detailed player stats), lack of annotations, and no output schema, the description is incomplete. It lists data points but doesn't explain the return format, potential limitations (e.g., data freshness, missing fields), or error handling. For a tool with rich data output and no structured support, more context is needed.
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 100%, with the parameter 'identifier' documented as 'Player ID or username'. The description adds value by specifying 'player ID or battletag', which clarifies the format slightly, but doesn't provide additional semantics beyond what the schema already covers. Baseline 3 is appropriate when schema does the heavy lifting.
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 the tool retrieves 'comprehensive player stats' and lists specific data points (rank, main heroes, win rates, etc.), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'getPlayerMatchHistory' or 'searchPlayer', which likely serve related but distinct purposes.
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 provides no guidance on when to use this tool versus alternatives. It mentions 'player ID or battletag' but doesn't clarify if this is for detailed profiles versus match history (getPlayerMatchHistory) or searching players (searchPlayer). No exclusions or prerequisites are stated.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool shows 'unlock methods and rarity distribution' which adds some behavioral context beyond basic listing, but doesn't address important aspects like whether this is a read-only operation, if there are rate limits, authentication requirements, or what format the output takes.
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 a single, efficient sentence that communicates the core functionality. It's appropriately sized for a zero-parameter tool and front-loads the main purpose. Every element (item types, unlock methods, rarity) earns its place in the description.
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 zero-parameter tool with no output schema, the description provides adequate context about what information will be returned (item types, unlock methods, rarity distribution). However, it doesn't specify the scope (all items vs filtered), format, or structure of the output, which would be helpful given the lack of output 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?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and the schema already documents this completely.
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 the tool's purpose: to catalog cosmetic items with specific examples (nameplates, MVP animations, emotes, sprays) and show unlock methods and rarity distribution. It uses a specific verb ('Catalog') and resource ('cosmetic items'), but doesn't explicitly differentiate from sibling tools like 'getItemsByType' or 'listSkins'.
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 provides no guidance on when to use this tool versus alternatives like 'getItemsByType' or 'listSkins'. It mentions what the tool does but offers no context about when it's appropriate, what prerequisites might exist, or when other tools should be used instead.
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 the full burden of behavioral disclosure. While it mentions what data is fetched, it doesn't describe critical behavioral traits such as whether this is a read-only operation, potential rate limits, authentication requirements, error handling, or response format. The description adds some context about the data scope but lacks operational transparency.
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 efficiently structured in two sentences: the first states the purpose and data scope, the second provides usage context. It's front-loaded with core information and avoids unnecessary elaboration, though it could be slightly more concise by merging the two sentences.
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?
Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is minimally adequate. It covers the purpose and data scope but lacks details on behavioral traits, output format, or error handling. Without annotations or an output schema, the description should provide more operational context to be fully 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?
The input schema has 100% description coverage, with the single parameter 'identifier' documented as 'Hero ID or slug'. The description doesn't add any parameter-specific information beyond what the schema provides, such as examples or format details. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Fetch') and resource ('detailed ability kit for a specific hero'), including the scope of data returned (primary fire, abilities, ultimate, passives). It distinguishes this from general hero information tools like 'getHeroInfo' by focusing on abilities, but doesn't explicitly contrast with all siblings.
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 usage context ('Essential for understanding hero mechanics and cooldowns') but doesn't explicitly state when to use this tool versus alternatives like 'getHeroInfo' or 'listHeroes'. No guidance on prerequisites, exclusions, or specific scenarios is provided.
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 mentions filtering and browsing, which suggests a read-only operation, but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, returns paginated results, or what format the output takes. The description is too brief to provide meaningful 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?
The description is extremely concise with two short sentences that directly address purpose and usage. Every word earns its place, and it's front-loaded with the core functionality. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that presumably returns filtered cosmetic items. It doesn't explain what 'cosmetics' are in this context, what fields are returned, or how results are structured. For a filtering tool with zero structured metadata, more context is needed.
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 100%, with the parameter 'type' fully documented in the schema (including enum values). The description adds marginal value by mentioning 'category' and listing the same enum values, but doesn't provide additional semantics beyond what the schema already specifies.
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 the tool's purpose: 'Filter cosmetics by category' with specific categories listed (NAMEPLATE/MVP/EMOTE/SPRAY). It distinguishes from some siblings like 'listItems' by specifying filtering rather than listing all items, but doesn't explicitly differentiate from all potential alternatives like 'getHeroSkins' which might also involve cosmetics.
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 usage context ('Perfect for browsing specific customization options') but doesn't explicitly state when to use this tool versus alternatives like 'listItems' or 'getHeroSkins'. It provides general guidance but lacks specific comparisons or exclusions.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It describes what data is returned (unlock conditions, points, progression tracking) but lacks critical behavioral details such as whether this is a read-only operation, if it requires authentication, rate limits, pagination, or error conditions. The description adds some context but is insufficient for a mutation-free tool with zero annotation coverage.
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 efficiently structured in two sentences: the first states the core functionality and data attributes, and the second clarifies the scope. Every word earns its place with zero redundancy, making it appropriately sized and front-loaded for quick understanding.
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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It explains what data is returned but lacks details on behavioral aspects like authentication or pagination. For a list tool with no structured fields, it meets minimum viability but could be more complete by addressing usage context or operational constraints.
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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description appropriately adds no parameter-specific information, maintaining focus on the tool's purpose and output scope. A baseline of 4 is applied since no parameters exist, and the description doesn't attempt to compensate unnecessarily.
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 the tool's purpose: listing achievements/trophies with specific attributes (unlock conditions, points, progression tracking) and scope (hero-specific and general gameplay milestones). It uses specific verbs ('list') and resources ('achievement/trophy'), but doesn't explicitly differentiate from the sibling 'searchAchievement' tool, which prevents a perfect score.
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 provides no guidance on when to use this tool versus alternatives like 'searchAchievement'. It mentions the scope of coverage (hero-specific and general milestones), but offers no explicit when/when-not instructions or comparisons with sibling tools, leaving usage context implied at best.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the content returned (maps with attributes and strategies) but lacks critical behavioral details such as whether this is a read-only operation, if it requires authentication, rate limits, pagination, or error conditions. For a tool with zero annotation coverage, this is a significant gap.
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 a single, efficient sentence that front-loads the core purpose ('All playable maps with layouts, objectives, and modes') and adds supplementary detail ('Includes map-specific strategies and callout locations'). Every word earns its place with zero waste or redundancy.
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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It explains what data is returned but lacks behavioral context (e.g., safety, performance). Without annotations or output schema, the description should ideally cover more operational aspects to be fully 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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is appropriate here. Baseline is 4 for zero parameters, as no additional semantic detail is needed beyond what the schema provides.
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 the tool's purpose: listing all playable maps with specific attributes (layouts, objectives, modes) plus additional content like strategies and callout locations. It uses specific verbs ('All playable maps') and resources, though it doesn't explicitly distinguish from its sibling 'filterMaps' beyond implying this is a comprehensive list.
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 provides no guidance on when to use this tool versus alternatives like 'filterMaps' or other sibling tools. It implies a comprehensive listing but doesn't specify use cases, prerequisites, or exclusions, leaving the agent to infer usage from context alone.
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 the full burden of behavioral disclosure. It mentions the tool is 'essential for mode-specific strategies,' which hints at its utility but doesn't describe key behaviors like whether it returns a list of maps, how results are formatted, if there are rate limits, or if it requires authentication. This leaves significant gaps in understanding how the tool operates beyond its basic purpose.
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 highly concise and well-structured in two sentences: the first states the purpose and parameters, and the second provides usage context. Every sentence adds value without redundancy, making it easy to scan and understand quickly.
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?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is adequate for basic understanding but incomplete for effective use. It covers the purpose and filter types but lacks details on return values, error handling, or behavioral traits, which are crucial since no annotations or output schema exist to fill these 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 description adds some meaning by specifying the filter criteria ('game mode' and 'queue type') and listing examples ('convoy/convergence' and 'competitive/casual'), which aligns with the enum in the input schema. However, with 100% schema description coverage, the schema already documents the parameter fully, so the description provides only marginal additional context without explaining parameter interactions or usage nuances.
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 the tool's purpose: 'Filter maps by game mode (convoy/convergence) or queue type (competitive/casual).' It specifies the verb 'filter' and resource 'maps' with filtering criteria. However, it doesn't explicitly distinguish this tool from sibling tools like 'listMaps' or 'searchPlayer' that might also involve map-related operations, preventing a perfect score.
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 provides implied usage guidance: 'Essential for mode-specific strategies' suggests this tool should be used when planning strategies based on game mode or queue type. However, it lacks explicit when-to-use vs. when-not-to-use instructions or named alternatives among sibling tools, such as clarifying if 'listMaps' returns all maps without filtering.
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 the full burden of behavioral disclosure. It mentions the search behavior ('partial name match') but doesn't describe other key traits: whether it's read-only or has side effects, what the return format looks like (e.g., list of achievements with details), pagination, error handling, or rate limits. For a search tool with zero annotation coverage, this leaves significant gaps.
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 concise sentences with zero waste. The first sentence states the core functionality, and the second provides usage context. It's appropriately sized and front-loaded, with every sentence earning 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?
Given the tool's moderate complexity (a search function with one parameter), no annotations, and no output schema, the description is adequate but incomplete. It covers the purpose and basic usage but lacks details on behavioral traits and output format. For a search tool, this is minimally viable but leaves the agent guessing about the response structure and other operational aspects.
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 schema description coverage is 100%, with the single parameter 'name' documented as 'Achievement name to search for.' The description adds context by specifying 'partial name match,' which clarifies the search semantics beyond the schema. However, since the schema already provides good coverage, the description only adds marginal value, warranting the baseline score of 3.
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 the tool's purpose: 'Find specific achievements by partial name match.' It specifies the verb ('Find'), resource ('achievements'), and scope ('by partial name match'). However, it doesn't explicitly differentiate from its sibling 'listAchievements' beyond the partial match aspect, which is why it's a 4 rather than a 5.
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 provides implied usage guidance with 'Helpful for tracking progress on particular challenges or hero mastery,' suggesting when this tool might be appropriate. However, it doesn't explicitly state when to use this versus 'listAchievements' (which presumably lists all achievements without filtering) or other alternatives, nor does it mention any prerequisites or exclusions.
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 the full burden. It mentions the tool returns 'matching profiles with basic stats,' which gives some behavioral context (e.g., it's a read operation with limited data). However, it lacks details on permissions, rate limits, error handling, or pagination, which are important for a search tool.
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 front-loaded and efficient: two sentences that directly state the action, input, and output without waste. Every sentence adds value, making it easy to parse quickly.
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?
Given the tool's moderate complexity (search with one parameter) and no annotations or output schema, the description is adequate but incomplete. It covers the basic purpose and output type but lacks behavioral details like result limits or error cases, which would help an agent use it correctly.
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 has 100% description coverage, with the 'username' parameter documented as 'Username to search for.' The description adds minimal value by specifying 'username/battletag,' hinting at the format, but doesn't provide additional syntax or constraints beyond what the schema already covers.
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 the tool's purpose: 'Find players by username/battletag' specifies the verb (find) and resource (players), and 'Returns matching profiles with basic stats for player lookup and comparison' explains the outcome. It distinguishes from siblings like getPlayerProfile (detailed profile) and getPlayerMatchHistory (match data), but doesn't explicitly name them.
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 usage for player lookup and comparison, suggesting it's for initial searches rather than detailed analysis. However, it doesn't explicitly state when to use this versus alternatives like getPlayerProfile or getPlayerMatchHistory, nor does it provide exclusions or prerequisites.
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 the full burden of behavioral disclosure. While it mentions what data is returned, it doesn't describe critical behaviors like whether this is a read-only operation, potential rate limits, authentication requirements, or error handling for invalid identifiers. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operational traits.
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 appropriately sized with two sentences that are front-loaded with key information. The first sentence lists the data types returned, and the second provides usage guidance. There's minimal waste, though it could be slightly more structured for clarity.
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?
Given the tool's complexity (single parameter, no output schema, no annotations), the description is moderately complete. It covers the purpose and usage context well but lacks details on behavioral aspects and doesn't explain return values, which is a gap since there's no output schema. It's adequate but has clear room for improvement in transparency.
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 has 100% description coverage, with the single parameter 'identifier' documented as 'Hero ID or slug.' The description doesn't add any additional meaning about this parameter beyond what the schema provides, such as format examples or valid values. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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 the tool provides comprehensive hero data including stats, abilities, lore, difficulty rating, and role details, which is a specific verb+resource combination. It distinguishes from siblings like getHeroAbilities (specific abilities only) and listHeroes (list overview only), though it doesn't explicitly name these alternatives.
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 provides clear context with 'Best for complete hero overview including gameplay tips and synergies,' which implicitly suggests when to use this tool versus more specialized siblings. However, it doesn't explicitly state when NOT to use it or name specific alternatives for comparison.
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 mentions the tool 'browses' and is 'useful for finding,' implying a read-only operation, but doesn't explicitly state whether it's safe, whether it requires authentication, or any rate limits. For a catalog browsing tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.
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 concise sentences with zero waste. The first sentence states the core purpose, and the second adds practical usage context. It's front-loaded and appropriately sized for a no-parameter tool, making every word earn 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?
Given the tool's complexity (simple catalog browsing with 0 parameters) and lack of annotations/output schema, the description is adequate but incomplete. It explains the purpose and usage but misses behavioral details like safety or response format. For a tool with no structured data, it should do more to cover these aspects, leaving room for improvement.
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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description adds value by explaining the semantic scope: 'across all heroes' and filtering by 'rarity, event, or collection,' which clarifies what the tool does without parameters. This compensates well for the simple schema.
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 the tool's purpose: 'Browse entire game skin catalog across all heroes' specifies the verb (browse) and resource (game skin catalog). It distinguishes from siblings like 'getHeroSkins' by emphasizing 'across all heroes' rather than per-hero, but doesn't explicitly contrast with 'listItems' which might overlap. The purpose is clear but sibling differentiation could be more explicit.
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 provides implied usage guidance: 'Useful for finding cosmetics by rarity, event, or collection' suggests when to use it (for broad skin discovery with those filters). However, it doesn't explicitly state when NOT to use it or name alternatives like 'getHeroSkins' for hero-specific skins or 'listItems' for other item types. The guidance is helpful but not comprehensive.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions what data is included (rarity tiers, unlock methods, visual variants), it doesn't address important behavioral aspects like whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or response format. For a tool with zero annotation coverage, this leaves significant gaps.
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 perfectly concise with a single sentence that efficiently communicates purpose, scope, and included data elements. Every word earns its place, and the structure is front-loaded with the core functionality followed by specific details about what's included.
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?
Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description provides adequate but incomplete coverage. It clearly states what the tool does and what data it returns, but lacks information about behavioral characteristics, error handling, and response structure that would be needed for full contextual understanding.
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 has 100% description coverage with a clear 'Hero ID' parameter description. The tool description doesn't add any parameter-specific information beyond what the schema already provides. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 the specific action ('List all cosmetic skins/outfits'), target resource ('for a hero'), and scope ('available for a hero'). It distinguishes from sibling tools like 'listSkins' by specifying hero-specific filtering and from 'getHeroInfo' by focusing only on cosmetic skins rather than general hero information.
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 implies usage context by specifying 'for a hero' and listing included data (rarity tiers, unlock methods, visual variants), which helps differentiate from broader tools like 'listSkins'. However, it doesn't explicitly state when NOT to use this tool or name specific alternatives for different scenarios.
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 provided, the description carries full burden. It discloses the return content (basic info, roles, identifiers) and hints at pagination/scope ('complete roster'), but lacks details on rate limits, permissions, or error handling. Adequate but not comprehensive.
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, front-loaded with core purpose, followed by return details. Every word adds value without repetition or fluff, making it highly efficient and well-structured.
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 0 parameters and no output schema, the description provides sufficient context for a list operation: purpose, return content, and usage hint. It could benefit from more behavioral details (e.g., pagination), but is largely complete for its complexity.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter details, focusing on output semantics instead, which is correct for this case.
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 the verb ('Retrieve') and resource ('complete roster of playable Marvel heroes'), specifying what information is returned ('basic info, roles, identifiers'). It distinguishes from siblings like getHeroInfo (single hero) and getHeroAbilities (specific 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 implies usage for getting all heroes at once, suggesting alternatives like getHeroInfo for individual details. However, it doesn't explicitly state when not to use it or compare with all siblings, leaving some context gaps.
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:

[![marvel-rivals-mcp MCP server](https://glama.ai/mcp/servers/AImaginationLab/marvel-rivals-mcp/badges/card.svg)](https://glama.ai/mcp/servers/AImaginationLab/marvel-rivals-mcp)

Score Badge

Copy to your README.md:

[![marvel-rivals-mcp MCP server](https://glama.ai/mcp/servers/AImaginationLab/marvel-rivals-mcp/badges/score.svg)](https://glama.ai/mcp/servers/AImaginationLab/marvel-rivals-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/AImaginationLab/marvel-rivals-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server