Minehut MCP

by Tobralla

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
The tools are clearly separated by prefix: minehut_* for direct API operations and browser_* for dashboard automation. Within each group, actions are distinct (start vs stop vs restart, click vs type vs press). However, there is potential overlap between direct server actions and browser-based equivalents, e.g., minehut_start vs browser_click on a start button, though descriptions hint at the intended use.
Naming Consistency3/5
The minehut_* group uses a mix of nouns (status, servers, logs, help) and verbs (start, stop, restart, command, upgrade_ram), while the browser_* group is more consistently verb-based (open, click, type, press, close, evaluate) but includes nouns (text, screenshot). The prefix system provides structure, but the lack of a uniform verb_noun pattern across all tools is a minor inconsistency.
Tool Count4/5
19 tools is slightly above the typical well-scoped range (3-15), but the dual API/browser design justifies the count. Each tool serves a distinct function, and no tool feels redundant or unnecessary.
Completeness4/5
The server covers essential Minehut operations: status, list, start, stop, restart, command, logs, and RAM upgrades. Missing create/delete server operations, but the browser automation tools can handle dashboard actions, and minehut_help provides guidance. The core lifecycle of managing an existing server is well covered.
Average 3.8/5 across 19 of 19 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
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, the description must disclose behavioral effects, but it only says 'stop and start' without addressing potential downtime, whether the operation is synchronous, or what happens if the server is already stopped. This is insufficient for a mutating action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, but it lacks essential detail, making it under-specified rather than effectively concise. It reads more like a placeholder than a helpful explanation.
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?
For a simple one-parameter tool, the description is incomplete: it doesn't explain the parameter semantics, expected behavior, or return value. With no annotations or output schema, the agent is left with significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema includes a single 'server' string parameter with no description, and the tool description does not clarify whether it expects a name, ID, or other identifier. At 0% schema coverage, the description fails to compensate.
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 tool's function as 'Stop and start a Minehut server again,' which precisely defines a restart. This differentiates it from the sibling tools minehut_start and minehut_stop.
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 offers no explicit guidance on when to use restart versus start/stop, nor does it mention any alternatives or exclusions. The only hint is the tool's name, which implies the intended use case.
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, so the description carries the full burden. It discloses that the tool changes RAM allocation and notes a plan limit, but it does not mention behavioral consequences like whether the server restarts, whether changes take effect immediately, or if any permissions are required. This is a significant gap for a mutation 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 two sentences, front-loaded with the core function and followed by a relevant constraint. Every sentence contributes meaning, and there is no fluff 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?
The tool is simple but lacks essential context: no information about the server parameter's format or identifier, and no explanation of post-change effects (e.g., restart required, downtime). Given the absence of annotations and output schema, the description is too sparse to fully guide an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 50%, the description only partially compensates. It mentions 'RAM allocation' but does not clarify the 'server' parameter at all, which has no description in the schema. The 'ram' parameter is already documented in the schema as 'New RAM in GB', so the description adds little value.
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: 'Change the RAM allocation of a Minehut server.' This is a specific verb+resource, and it distinguishes the tool from siblings like start, stop, restart, and logs. The added note about plan limits reinforces scope.
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?
Usage is implied: the description tells you what the tool does, so agents can infer it's for adjusting server RAM. However, it does not explicitly state when to use this vs. alternatives or mention any prerequisites/exclusions, such as whether the server must be stopped.
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, the description must disclose behavioral traits. It only states the action itself and gives examples. It does not mention whether the key press targets the focused element, whether it triggers navigation (e.g., F5), or any side effects. Minimal behavioral disclosure beyond the obvious.
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 sentence with examples, front-loaded and free of filler. Every word earns its place, making it exemplary in conciseness.
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 simple one-parameter tool with no output schema, the description is adequate but not complete. It lacks explicit usage guidance and behavioral details, though the simplicity of the tool lowers the burden. Compared to calibration examples, it meets the minimum viable bar.
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 has one parameter (key) with no description, and coverage is 0%. The description compensates by providing example values (Enter, Escape, Tab, F5), giving some meaning. However, it does not explain the expected format or whether combinations like 'Ctrl+A' are supported.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Press' and resource 'keyboard key on the page', with concrete examples (Enter, Escape, Tab, F5). It clearly distinguishes from sibling tools like browser_click (mouse action) and browser_type (text input).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (for key presses) but does not explicitly contrast with alternatives like browser_type or browser_click. No exclusions or conditions are provided, so usage is only implied.
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 carries the burden. It discloses the 'first visible element' selection behavior and the optional Enter press, but omits important traits like whether existing text is cleared, whether the tool waits for visibility, or how it handles no matching element.
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 no unnecessary words. Every clause adds information. It is efficient and well-structured.
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?
The tool has no output schema or annotations, and the description covers only the core action. It lacks details about return values, error handling, timeouts, or waiting behavior, which could be relevant in a browser automation context.
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 references all three parameters in prose ('text', 'selector', 'press_enter' as optional), but it does not specify selector format (e.g., CSS vs XPath) or whether text is appended or replaces. Given 0% schema coverage, it partially compensates but not fully.
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 ('Type') and resource ('text into the first visible element matching a selector'). It distinguishes from sibling tools like browser_click and browser_press by focusing on text entry, and adds specificity with 'first visible element'.
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 such as browser_click or browser_press. It does not mention exclusions, prerequisites, or typical use cases.
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, the description carries the full burden of behavioral disclosure. It only states 'Power off' without mentioning side effects (e.g., data loss, player disconnects), authentication requirements, or whether the operation is reversible. Lacks important safety context for an agent.
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, compact sentence that conveys the purpose and the accepted parameter format. No redundant words or filler; it is appropriately sized for the tool's simplicity.
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 simple one-parameter action tool, the description provides the essential purpose and parameter hint but omits behavioral context (e.g., what happens after power-off, whether the server must be online, or how success is indicated). Given no annotations and no output schema, the description is adequate but not 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 input schema has a single 'server' parameter with no description, but the description adds semantics by clarifying that the parameter can be a name or an id. This helps the agent populate the parameter correctly, though it does not detail exact id formats or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'Power off' with the resource 'Minehut server' and the scope 'by name or id', clearly distinguishing it from siblings like minehut_start and minehut_restart. It directly states what the tool does without ambiguity.
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 explicit guidance on when to use this tool versus alternatives such as minehut_restart or minehut_stop. The intended use is implied by the name and description, but the description does not state prerequisites, exclusions, or alternative tool recommendations.
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 mentions the return format ('image plus the saved file path') and that the AI can read the image, which is useful. However, it does not mention prerequisites (e.g., open browser), potential side effects, or full_page interaction behavior.
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 concise sentences convey the purpose, scope, output, and AI readability. No redundant or filler content; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description adequately explains the main behavior and result. However, it omits contextual details like browser state requirements and full_page semantics, making it slightly incomplete.
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 covers 50% of parameters: selector has a description, full_page only has a default. The description clarifies 'page or of one element' for selector, but full_page behavior is left entirely to the schema's bare default. Description partially compensates for the coverage gap but not fully.
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 ('Take a screenshot') and the resource scope ('page or one element'), directly matching the tool's function. It is the only screenshot tool among siblings, so there is no ambiguity.
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 does not provide any guidance on when to use this tool versus alternatives like browser_text or browser_evaluate. It implies visual inspection ('The AI can read the image contents') but never explicitly states use cases 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, the description carries the full burden. It discloses that it captures the API session automatically and that Cloudflare challenges may require manual wait. However, it does not mention error handling, whether an existing session is reset, or idempotency.
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 the main action, and no fluff. Every sentence adds value: credentials, session capture, and Cloudflare caveat.
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?
It covers the core login action, fallback to env vars, and the Cloudflare caveat. However, without an output schema, it does not describe return values or success/failure indicators, and it omits prerequisites like browser being open.
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 has 0% coverage, but the description adds meaning by explaining that email/password are credentials and that MINEHUT_EMAIL/MINEHUT_PASSWORD can be used as a fallback. This partly compensates, though it lacks details on field format or requiredness.
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: 'Log into the Minehut dashboard in the controlled browser'. It distinguishes itself from sibling minehut status/action tools and generic browser tools by specifying the authentication target and the controlled-browser context.
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?
It implies usage as a prerequisite for other minehut operations and provides a conditional follow-up (browser_wait_manual for Cloudflare), but it does not explicitly state when to prefer this over alternative login methods or when not to use it.
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 carries the transparency burden. 'Read' clearly indicates a non-mutating operation and 'log lines' suggests the return type, but the description does not disclose error handling, default line count, or output format details.
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 sentence with no fluff. It states the action, the target, and the use cases efficiently.
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 read tool without output schema or annotations, the description covers the core behavior, the result type, and typical use cases. It could be improved by mentioning the default line count or error behavior, but it is largely 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 schema already describes 'lines' fully (default 100, max 500) and 'server' is a required string whose purpose is obvious from the tool name and context. The description adds no extra parameter detail, and the 50% schema coverage gap is not compensated, but the missing info is minor.
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 uses the specific verb 'Read' with the resource 'log lines of a Minehut server', making its function clear. It differs from sibling tools like minehut_status or minehut_command by focusing on logs, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(useful to check console output, crashes, errors)' gives clear context for when to use the tool. It implies log inspection use cases and is sufficient for an agent, though it does not explicitly discuss exclusions or alternatives.
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 the full burden. It discloses the important behavior that commands run with operator privileges, which warns about the power of this tool. However, it does not mention potential side effects, prerequisites (e.g., server running), or what the return value will be, leaving gaps in transparency.
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 with illustrative examples. Every element earns its place, and it is immediately clear what the tool does without excess verbosity.
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 simple two-parameter tool with no output schema, the description is mostly complete: it identifies the action and the target. However, it does not explain what the agent should expect in return (e.g., execution confirmation, logs, or errors), which is a notable gap for a command execution tool. The operator privilege note partially mitigates this, but not fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes both parameters (server and command) with 100% coverage. The description adds example command values but does not add meaning beyond the schema, so it meets the baseline for schema-heavy parameter documentation.
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 'Send' with the resource 'any console command to a Minehut server', which is specific and distinguishes this from sibling tools like minehut_start, minehut_stop, and minehut_status. The provision of concrete examples further reinforces the exact purpose.
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 makes it clear that this tool is for arbitrary console commands, and the examples show typical usage. It does not explicitly say when not to use it, but the sibling tool names (start, stop, restart, status, logs) imply those are alternatives for specific operations, providing clear context without formal 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?
No annotations exist, so the description must disclose behavior. It says 'Show a short guide', which implies a read-only, informational action with no side effects, but it doesn't explicitly confirm that no server changes are made or describe the output format. The 'first-time setup' detail adds some content-level transparency but not full behavioral clarity.
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 sentence, front-loaded with the verb and purpose. It is concise and easily scannable, though 'this server' is slightly ambiguous. It earns high marks for brevity without sacrificing the core message.
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 help tool with no parameters and no output schema, the description adequately covers what it does and highlights a key component (first-time setup flow). It does not describe return format, but that is a minor gap for a help command. The description is complete enough for an agent to know when 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, so no parameter explanations are needed. The schema is empty (100% coverage), and the description already conveys that no inputs are required. With 0 params, this fits the baseline of 4.
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 what the tool does: 'Show a short guide about how to use this server' – a specific verb ('show') and resource (guide for server usage). It differentiates from sibling operational tools like minehut_start/minehut_stop and browser tools. Mentioning the 'recommended flow for first-time setup' adds specificity.
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 the tool is for help/guidance, but it does not explicitly state when to use it vs alternatives or when not to use it. A user might infer it should be called first for setup help, but this is not stated. No exclusions or alternative tool references are present.
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 must convey behavioral traits. It only states the action without disclosing consequences like server boot time, idempotency, or error behavior if the server is already running. This is a significant gap for a mutation 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 a single, front-loaded sentence that communicates the action and parameter semantics with no unnecessary words. It earns its place fully.
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 (one parameter, no output schema, no annotations), the description covers the core purpose and parameter meaning. However, it lacks behavioral context such as prerequisites, potential errors, or idempotency, making it only moderately 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 schema lists a single 'server' parameter with no description. The description compensates by specifying that the server can be identified 'by name or id,' which clarifies the accepted values and adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Power on' and clearly identifies the target resource: 'Minehut server by name or id.' This distinguishes it from sibling tools like minehut_stop and minehut_restart, which have opposite actions.
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 that this tool should be used when a Minehut server needs to be started. However, it does not explicitly mention alternatives or conditions when not to use it, such as checking if the server is already running.
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 carry the burden. It discloses the side effect of releasing resources, but does not mention idempotency, behavior when no browser is open, or that subsequent browser commands will fail until reopened.
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?
One concise, front-loaded sentence with no filler. Every word adds value, making it an excellent example of appropriate brevity.
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 zero-parameter, no-output-schema tool, the description covers the core behavior of closing the browser and freeing resources. It lacks edge-case details like error handling, but given the low complexity, it is nearly 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 zero parameters and the schema is empty with 100% coverage. Per the rubric, a baseline of 4 applies; the description does not need to explain parameters that do not exist.
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 ('Close') and the resource ('controlled browser window'), and adds 'release resources' for extra clarity. It distinguishes itself from sibling tools like browser_open and browser_click.
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?
No explicit guidance on when to use this tool versus alternatives, but it is implicitly the terminal operation for a browser session. It doesn't mention when not to use it or what to do 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 carries full responsibility for behavioral disclosure. It mentions returning the result and the dashboard page context, but does not explain potential side effects (e.g., arbitrary code execution, navigation, or state mutation) or any safety/permission considerations. This is adequate but not rich.
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. The first sentence front-loads the core action, and the second adds valuable use-case context without any 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?
The tool has a simple signature (one parameter, no output schema). The description sufficiently covers purpose, use cases, and return behavior. It could optionally mention the result type or the fact that it operates on the currently open dashboard page, but overall it is complete for the tool's complexity.
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 already provides a clear description for the single parameter 'js' ('JavaScript expression or IIFE to evaluate in the page context'). The tool description adds minimal extra parameter meaning beyond that, so it meets the baseline of 3.
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 tool's function: 'Run a small JavaScript expression in the dashboard page and return its result.' It uses a specific verb ('run') and resource ('JavaScript expression in the dashboard page'), and distinguishes itself from sibling tools by highlighting unique use cases like 'reading React state' and 'clicking via JS'.
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 when to use it ('Useful for reading React state, clicking via JS, or advanced automation') and gives context. However, it does not explicitly state when NOT to use it or directly compare with alternatives like browser_click or browser_text, so it falls short of a 5.
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 carries full burden. It explains the return values and the controlled browser context, but does not disclose potential side effects (e.g., navigating away from current page, loading scripts, login requirements). Adequate for a simple navigation 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 a single, well-structured sentence that packs the action, default, and return values without redundancy. It is front-loaded with the main verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the core behavior and return values. It lacks error-handling details, but these are not critical for a navigation tool and the description is complete enough for safe invocation.
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 covers 100% of the parameter (url) with a description and default. The description only reiterates the default value ('defaults to the Minehut dashboard'), adding no further semantic meaning beyond the schema.
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 tool opens a URL in a controlled browser and returns the page title, URL, and visible text. This distinguishes it from interaction tools like browser_click and browser_type, and includes the default behavior.
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: it is for opening a page and reading its content, defaulting to the Minehut dashboard. It does not explicitly mention when not to use it or alternatives, but the context is sufficiently clear for selection among siblings.
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 the burden of behavioral disclosure. It does state what data will be retrieved (status, player count, RAM, MOTD, version, plugins) and that the tool accepts a server name or id, which is helpful. However, it does not explicitly state that this is a read-only operation, what happens if the server is offline, or any authentication requirements. These gaps leave some behavioral uncertainty.
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 long, front-loaded with the primary purpose and a clear list of returned data. Every word contributes meaning, and there is no redundancy or filler. It is concise and well-structured for quick parsing by an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no nested objects), the description is largely complete. It enumerates the return fields, which compensates for the lack of an output schema. It does not mention error cases or response format, but for a simple status tool, the description provides sufficient context for an agent to invoke 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 schema already provides 100% coverage for the single parameter 'server' with the description 'Server name or id'. The tool description repeats this same information ('Accepts the server name or its id.') without adding any new meaning or examples. Since schema coverage is high, a baseline of 3 is appropriate; the description adds no extra semantic value beyond what the schema already provides.
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 tool's function with a specific verb ('Get') and resource ('a Minehut server'), enumerating the exact data fields returned: status, player count, RAM, MOTD, version, and plugins. This distinguishes it from sibling tools that start, stop, command, or log, leaving no ambiguity about its purpose.
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 for when to use this tool: whenever a Minehut server's status information is needed. It does not explicitly mention alternatives or exclusions, but the verb 'Get' and the list of returned fields imply a read-only, status-checking role that is distinct from the mutating sibling tools. There is no alternative guidance, but the context is self-evident.
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 carries the full burden. It discloses the key behavior of clicking only the first visible element and the selector format, but does not mention waiting behavior, failure handling, or what 'visible' means. This is moderately informative but leaves some behavioral 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 a single, well-structured sentence that starts with the action and selector, then provides valuable examples. No extraneous words or repetition — every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter click tool with no output schema, the description covers the core purpose and selector syntax well. It lacks details about error behavior (e.g., no matching element) and waiting, but given the tool's simplicity, it is nearly complete. The 'first visible' constraint is a useful nuance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the 'selector' parameter. The description fully compensates by explaining that the parameter is a CSS selector and providing three illustrative examples, including a :has-text pseudo-selector. This adds essential meaning beyond the bare schema.
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 ('Click') and the resource (the first visible element matching a CSS selector). It provides concrete examples of selector syntax, making it unambiguous and distinct from sibling tools like browser_type or browser_press.
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 clicking elements) but does not explicitly state when to use this tool over alternatives like browser_type or browser_press. It lacks explicit 'when not to use' guidance, but the examples help clarify the intended use case.
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 itself discloses that it returns visible text (not raw HTML) and that omitting the selector returns the whole page. This is useful behavioral nuance, though it does not address potential errors or edge cases like empty results.
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 no redundant information. It efficiently states the core behavior, the optional selector condition, and the intended purpose.
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 read-only tool with no output schema and no annotations, the description covers the essential purpose and behavior. It is complete enough for an agent to understand when and how to invoke it, though it does not describe return format or failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%; the description clarifies the selector's optionality and behavior but does not mention max_chars. However, the schema provides default and maximum boundaries for max_chars, so the description adds only partial value beyond the schema.
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 tool returns visible text of an element or the whole page, using a specific verb ('Return') and resource ('visible text'). It distinguishes itself from sibling browser tools like browser_screenshot (visual) and browser_evaluate (JavaScript execution).
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 phrase 'so the AI can read the current state of the panel' provides clear context for when to use this tool. It does not explicitly mention alternatives or exclusions, but the context is clear enough relative to the sibling set.
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 the behavior of waiting for a specified number of seconds and then capturing session tokens, adding a meaningful side effect beyond just waiting. However, it does not detail what 'capture session tokens' entails or how timeouts are handled, which prevents a perfect score.
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 that includes all essential information—what it does, when to use it, and the post-action—without any fluff. The parenthetical examples are concise and useful.
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 single-parameter tool with no output schema, the description covers the main aspects: purpose (wait), trigger (manual action), and outcome (capture tokens). It lacks explicit timeout/failure behavior or return value details, but those are less critical for this 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 schema description coverage is 0%, so the description must compensate. It does so by explaining 'a number of seconds', directly defining the sole parameter's meaning. While it does not mention the default or range (already in schema constraints), it adds essential semantic context that the raw integer type lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Wait' and references the resource 'seconds' and the context 'manual action in the visible browser' with concrete examples (Cloudflare challenge, 2FA, password manager). It also states a distinct post-action ('capture the session tokens'), which clearly distinguishes it from sibling browser tools like browser_click, browser_type, and browser_evaluate.
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 indicates when to use the tool: when the user needs to finish a manual action in the browser, with specific scenarios listed. It does not explicitly mention alternatives, but no alternative wait tool exists among siblings, and the contrast with automated browser tools is implicit.
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 present, so the description carries the full burden. The verb 'List' strongly indicates a read-only operation, and 'logged-in Minehut account' clarifies authentication requirements. Although the return format is not detailed, for a simple listing operation this is sufficient.
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 entire description is one concise sentence, front-loaded with the verb 'List' and immediately stating scope and output. No unnecessary words or repetition.
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 zero-parameter list tool with no output schema, the description fully conveys what the tool does and what the caller can expect: a list of servers with their current status. This is complete for the tool's 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 is empty with zero parameters, so the baseline score is 4. The description adds context about what the output will include (server statuses) even though no parameters need explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and clearly identifies the resource: 'all servers on the logged-in Minehut account', plus the output detail 'with their current status'. This distinguishes it from sibling tools like minehut_start or minehut_stop, which are action-oriented.
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 use for obtaining an overview of servers before performing actions, but it does not explicitly mention alternatives or exclusions. However, the context is clear from the sibling tool names (e.g., minehut_status for status-only, minehut_start for starting), so the guidance is adequate.
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:

[![minehut-mcp MCP server](https://glama.ai/mcp/servers/Tobralla/minehut-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Tobralla/minehut-mcp)

Score Badge

Copy to your README.md:

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

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