arena-hero-mcp

by vhxubo

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v0.3.1
Disambiguation5/5
Each tool serves a clearly distinct purpose: listing resources, listing obstacles, combining both, providing snapshot metadata, forcing a refresh, and retrieving the userscript. No two tools could be easily confused even without reading descriptions in detail.
Naming Consistency4/5
Tool names mostly follow a verb_noun snake_case pattern (list_resources, get_all_cells, get_userscript) with a few exceptions like snapshot_info (noun_noun) and refresh (bare verb). Still, the naming is consistent in style and readable enough to infer function.
Tool Count5/5
Six tools is a well-scoped count for a specialized server. Each tool earns its place, covering the core read-oriented features and the script installation helper without unnecessary bloat.
Completeness4/5
The server covers the apparent domain of browsing arena-hero memory cells and installing the userscript, but lacks any mutation or configuration tools (e.g., clearing cache, changing namespace via MCP). These are minor gaps for a primarily read-only toolset.
Average 4/5 across 6 of 6 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 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?
No annotations are present, so the description carries full burden. It reveals the tool forces a refresh and pushes a snapshot, but does not disclose side effects, auth requirements, or what happens to existing data. 'Force' implies a mutation, but details are missing.
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, front-loaded sentence with zero waste. It efficiently states the core action without redundancy, appropriate for a parameterless tool.
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?
With no annotations, no output schema, and zero parameters, the description is the only source of context. It fails to explain the return format or the practical effect of the refresh, making it incomplete for an agent to predict what happens.
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 zero parameters, so the baseline is 4. The description adds no parameter information, but none is needed. It is clear that invocation requires no arguments.
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 states a specific action: force the browser to re-read IndexedDB and push back the latest snapshot. This clearly distinguishes it from sibling tools like snapshot_info or get_all_cells, though the phrase 'push back' is somewhat ambiguous.
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 versus alternatives. It does not mention prerequisites, typical scenarios (e.g., after data changes), or exclusions.
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 bears full responsibility for disclosing behavioral traits. It states the content of the return value (snapshot metadata and browser connection status) but does not mention side effects, error handling, or any dependencies. For a read-only info tool, this is a basic disclosure, but it leaves some ambiguity around what 'browser connection status' entails.
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, succinct sentence that leads with the verb and resource, then packs the key fields into a parenthetical list. It is front-loaded and contains no filler or repetition. Excellent conciseness.
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?
This is a simple, parameterless tool with no output schema. The description covers the main return elements (count, namespace, update time, kind distribution, browser connection status). While it could elaborate on the meaning of 'browser connection status' or the format of the output, the low complexity makes this description adequately 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 accepts zero parameters, so there is no parameter semantics to convey. According to the rubric, 0 params gets a baseline score of 4. The description correctly omits any parameter-related details, and no additional meaning is needed.
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 returns the latest snapshot metadata (count, namespace, update time, kind distribution) plus browser connection status. The verb '返回' (returns) is specific, and the resource is well-defined. This distinguishes it from sibling tools like list_resources or get_all_cells, which focus on other types of data.
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 does not mention any prerequisites, exclusions, or comparison with sibling tools. The agent is left to infer usage solely from the purpose statement, which is insufficient for clear decision-making.
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?
There are no annotations, so the description carries the burden of behavioral disclosure. It adds semantic context (permanent terrain, trustworthy) but does not explicitly state that the operation is read-only, nor does it describe potential side effects, performance, or return format. The word 'list' implies a read operation, but more detail would be beneficial.
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, well-structured sentence that immediately states the action and scope, and it adds a brief parenthetical clarification. It is concise, front-loaded, and contains 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?
For a simple tool with no parameters, no annotations, and no output schema, the description adequately covers the essential information: it tells what is listed (all obstacle memory cells) and adds helpful clarification. It could be slightly more complete by explicitly stating the return type, but the description is sufficient for the tool's simplicity.
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 zero parameters, so the baseline is 4. The description adds value by explaining what kind=OBSTACLE means, which is not captured in the schema. Since there are no parameters to document, this is sufficient.
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 action ('列出所有' = list all) and the resource (kind=OBSTACLE memory cells), and it further clarifies the meaning of OBSTACLE as 'permanent terrain, trustworthy.' This distinguishes it from sibling tools like list_resources and get_all_cells, which likely handle other cell types or broader scopes.
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 usage context is implied: use this tool when you need to retrieve obstacle cells. However, it does not explicitly mention when not to use it or point to alternatives like get_all_cells for a broader query, so it lacks the explicit differentiation seen in higher-scoring examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of disclosure. It explains that each call uses websocket (ws) to make the browser re-read IndexedDB for the latest data, and warns about stale memory. This adds meaningful behavioral context beyond the schema, though it does not describe the return format or side effects.
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 concise, with two sentences that directly state the purpose, the mechanism (ws re-read), and the key caveat (stale memory). Every sentence earns its place with no redundancy.
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 simple list tool with no parameters and no output schema, the description covers the essential aspects: what it returns (RESOURCE-kind coordinates), how it fetches data (ws re-read), and the important limitation (memory can be outdated). It does not specify the exact return format, but this is not critical given the tool's simplicity.
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 zero parameters, so there is nothing to explain. The description adds no parameter information, but none is needed. The baseline of 4 for a no-parameter tool 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?
The description clearly states it lists all exploration memory cells with kind=RESOURCE in IndexedDB, naming the specific resource (RESOURCE cells) and the context (exploration memory). This distinguishes it from sibling tools like list_obstacles and get_all_cells, so the purpose is unambiguous.
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 viewing explored resource nodes and explicitly warns that the memory may be outdated and should not be treated as currently minable. However, it does not explicitly compare to alternatives or state when to use this tool instead of others, leaving some gap in usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 discloses a meaningful behavioral trait: "不依赖浏览器连接, 随时可调" (does not depend on browser connection, can be called anytime), indicating the tool is always available and performs a read-only retrieval. It also warns about the NAMESPACE caveat. This adds value beyond the name and 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 two sentences, front-loaded with the primary action and immediate usage. Every sentence adds value: the first states what it returns and for what purpose; the second includes the necessary caveat and availability. No wasted 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?
For a simple no-parameter tool with no output schema, the description covers the essential aspects: what it returns, why it's used, a key prerequisite, and the fact that it can be called anytime. It is complete enough for an agent to understand when and how to invoke it.
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 zero parameters, and the schema is empty, so the baseline is 4. The description provides no parameter details but correctly omits them since they don't exist. It instead mentions a user action (changing NAMESPACE) which is not a parameter, which is fine.
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: "返回 Tampermonkey 油猴脚本全文" (returns the full text of the Tampermonkey userscript). It clearly distinguishes this from sibling tools like list_resources, list_obstacles, and get_all_cells by focusing on the script text rather than game state or resources.
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 states the intended use case: "供用户粘贴进扩展安装" (for users to paste into extension installation) and gives a prerequisite: the user must change the NAMESPACE. It does not explicitly exclude any contexts or mention alternatives, but the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It transparently states what the tool returns (all non-EMPTY memory cells of the two types) without hiding any side effects. While it doesn't explicitly say it's read-only, the verb 'list' strongly implies a non-mutating operation, making this adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys all necessary information without redundancy. Every word earns its place, and the structure is clear and front-loaded.
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?
For a simple list tool with no parameters and no output schema, the description is fully complete. It specifies exactly what cells are returned (non-EMPTY, RESOURCE + OBSTACLE), which is sufficient for an agent to decide when to invoke it. No additional context is needed.
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 zero parameters, and the input schema is empty. Per the rubric, a baseline of 4 is appropriate when there are no parameters to describe. The description adds no param-specific information, but none is needed.
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 the specific verb 'list' and clearly defines the resource as 'memory cells' with explicit filters (non-EMPTY, RESOURCE + OBSTACLE). This distinguishes it from sibling tools like list_resources and list_obstacles by covering both types in one call.
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 clearly states the scope (non-EMPTY cells of both RESOURCE and OBSTACLE types), implying it should be used when both types are needed together. It does not explicitly name alternatives or exclusionary conditions, but the context is clear enough for an agent to infer appropriate usage.
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:

[![arena-hero-mcp MCP server](https://glama.ai/mcp/servers/vhxubo/arena-hero-mcp/badges/card.svg)](https://glama.ai/mcp/servers/vhxubo/arena-hero-mcp)

Score Badge

Copy to your README.md:

[![arena-hero-mcp MCP server](https://glama.ai/mcp/servers/vhxubo/arena-hero-mcp/badges/score.svg)](https://glama.ai/mcp/servers/vhxubo/arena-hero-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/vhxubo/arena-hero-mcp'

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