mcdev-mcp

Server Quality Checklist

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

Latest release: v2.2.1
Disambiguation5/5
Each tool has a clearly distinct purpose, from game state snapshots (mc_snapshot) to entity/block details (mc_entity_details, mc_block_details) and texture rendering (mc_get_item_texture variants). Even similar tools like mc_get_item_texture and mc_get_entity_item_texture differ by target. No ambiguity.
Naming Consistency5/5
All tools follow the consistent pattern 'mc_verb_noun' using snake_case (e.g., mc_block_details, mc_join_server, mc_screenshot). There are no deviations or mixed conventions, making the naming predictable and easy to navigate.
Tool Count4/5
With 31 tools, the set is larger than average, but the server's scope—covering runtime debugging, static analysis, video recording, and connection management—justifies the count. Each tool earns its place, though a few could potentially be merged without loss of clarity.
Completeness4/5
The toolset covers the core Minecraft development and debugging workflow comprehensively, including player state, entity/block interaction, inventory inspection, item textures, chat history, video capture, class browsing, and version management. Minor gaps exist, such as no direct tool for reading player inventory without scripting, but these are manageable.
Average 4.3/5 across 31 of 31 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 4 of 4 community issues answered or closed in the last 6 months
- 22 commits in the last 12 weeks
- Last stable release on June 12, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the two actions and the prerequisite for 'set', but does not describe return values, side effects, or behavior when setting multiple times. Without an output schema, the agent lacks information on what 'list' returns.
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 short and directly states the purpose followed by a bullet list of actions. It is front-loaded with the overall goal and efficiently conveys the core functionality without extraneous text.
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 tool with two actions and two parameters, the description is mostly adequate but lacks return value details and prerequisites like needing to connect first (suggested by sibling 'mc_connect'). Without an output schema, the description should have explained what each action returns.
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 100% with descriptions for both parameters. The tool description adds minimal value beyond the schema—it repeats the action enum and version example. Since the schema already documents the parameters clearly, the description does not significantly enhance understanding.
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 it manages Minecraft versions for static analysis tools, with two actions 'set' and 'list' that define the resource and verb. The context distinguishes it from sibling tools which deal with blocks, entities, screenshots, etc.
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 mentions that 'set' is required before using other static tools, giving a clear usage context. However, it does not provide explicit when-not-to-use or alternatives among siblings, leaving some ambiguity about when to use 'list' versus other tools.
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 exist, and the description lacks details on failure modes (e.g., missing entity, empty slot), side effects, or authentication needs. It only states the output is a viewable PNG.
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 one sentence plus a short recommendation, using minimal words. It is front-loaded with the core purpose and slot enumeration.
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?
No output schema exists, yet the description omits return structure (e.g., URL or data format). It does not mention error handling or prerequisites, leaving gaps for an agent.
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 coverage is 0%, so the description must compensate. It explains the slot enum values but does not clarify the entityId parameter beyond suggesting a source (nearby_entities). More details on entityId source would improve.
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 specific verbs and nouns: 'Render an item carried by another entity' and enumerates slot options. It distinguishes from sibling tools like mc_get_item_texture by focusing on entity-attached items.
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?
It advises pairing with mc_nearby_entities to find entity IDs, indicating typical usage. However, it does not explicitly state when to avoid this tool or contrast with other rendering tools.
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 partially addresses behavioral traits: it mentions output format (PNG) and the fact that no inventory slot is required. However, it does not disclose error handling, permission needs, or limits, leaving some gaps for the 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?
Two concise sentences that front-load the action and a key constraint. Every word adds value 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 tool with one parameter and no output schema, the description covers the essential purpose, input, output format, and a usage nuance. It lacks only minor details about error conditions.
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 100% and the description adds a concrete example and context ('registry id'), slightly enriching the parameter meaning beyond the schema. However, the added value is modest, consistent with baseline 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 renders the default texture for an item registry id as a PNG, with a concrete example. It distinguishes from siblings by specifying 'default texture' and 'no inventory slot required', although the difference from mc_get_item_texture is not fully explicit.
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 like mc_get_item_texture or mc_get_entity_item_texture. The description implies a specific use case but does not provide context for when-not or alternative 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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns source code with context and implies a read-only operation, but does not detail what 'surrounding context' entails, error behavior, or any access requirements.
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 followed by a short utility note. Every word adds value, with no redundancy or filler.
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 and 3 simple parameters. The description explains purpose and utility but omits details about return format (e.g., string of code) and potential errors (e.g., method not found). It 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra semantic detail beyond the schema; it only mentions the tool's output context, not the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'source code for a specific method in a class', and includes the nuance 'with surrounding context'. It distinguishes from siblings like mc_get_class (whole class) and mc_search (broad search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage ('useful for understanding method implementation details') but does not provide explicit guidance on when to use this tool versus alternatives like mc_get_class or mc_find_refs. No when-not-to-use or alternative mentions.
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, the description carries the full burden. It discloses version-specific behavior (honors CustomModelData, fallback on older versions) and output format (PNG + caption). It does not cover permissions or side effects, but for a read operation this is acceptable.
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 action and output, no unnecessary words. Highly concise.
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 only one parameter and no output schema, the description covers version differences, output format, and return content. Complete enough for a simple tool.
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 100%, and the description adds no extra meaning beyond the schema's field description for 'slot'. Baseline 3 applies.
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 renders an item in a specific inventory slot as a PNG, with version-specific behavior. It distinguishes from siblings like mc_get_entity_item_texture and mc_get_item_texture_by_id by focusing on player inventory slot.
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 siblings (e.g., mc_get_item_texture_by_id). There is no mention of when not to use it or alternative 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?
Discloses that 'full' views may exceed the response budget for large classes, and describes the variations in information returned for each view. Without annotations, it carries the full burden, but it does not mention error cases (e.g., class not found) or version-dependent 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?
Description is concise at about 10 lines, front-loaded with the core purpose, and uses a clear bullet-like list for the view parameter options. Every sentence adds value without 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?
Given no output schema, the description explains the return types for each view sufficiently (e.g., 'hierarchy + counts + one-line method/field signatures'). It does not detail the exact response structure or error handling, but provides enough for the agent to choose appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by detailing what each view option returns (e.g., 'summary' gives one-line signatures, 'methods' gives method signatures) and suggesting an order of use, going beyond the schema's enum descriptions.
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 'Get info about a Minecraft or Fabric API class' which clearly identifies the action and resource. It distinguishes from sibling tool mc_get_method by focusing on classes rather than methods, though it doesn't explicitly exclude other class-related tools like mc_list_classes.
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?
Provides explicit guidance on using the 'view' parameter: start with 'summary' as it always fits the budget, and only use 'full' when needed. This helps the agent avoid exceeding response limits. However, it does not discuss when to use this tool versus alternatives like mc_get_method.
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 provided, so description carries full burden. It discloses result capping (default 100, max 5000) and the effect of the limit parameter, but does not mention whether the operation is read-only, or any required permissions 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 two sentences, front-loaded with the core purpose, and contains no extraneous information. Every sentence contributes meaning.
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 5 parameters and no output schema, the description covers core purpose and capping behavior. It could mention return format or error cases, but overall is adequate for a relatively simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying the default and maximum for the limit parameter, and implies the direction parameter's enum values. However, other parameters are adequately described in 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?
Description clearly states the tool finds callers or callees using the callgraph database, with a specific verb and resource. It distinguishes between two reference directions, making purpose 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 understanding code dependencies but does not explicitly state when to use this tool over sibling tools like mc_find_hierarchy or mc_get_method. No direct comparison or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions result caps (default 500, max 5000) and the ability to widen with 'limit'. This adds behavioral context beyond the schema, but does not disclose other potential behaviors like permissions 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?
Three short sentences: purpose, filter option, and limits. Every sentence earns its place with no fluff. Front-loaded with the core action.
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 (3 optional params, no output schema), the description covers the core behavior and parameters. It could mention the return structure (e.g., list of package names/IDs) but is adequate for a discovery tool.
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 100%, baseline 3. The description adds context for 'limit' (results capped, default/max, widening) and 'namespace' (minecraft or fabric), but largely reiterates schema info. No added meaning for 'version'.
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 'list' and resource 'packages', and specifies optional filtering by namespace. It distinguishes from sibling tools by focusing on package discovery.
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 context: 'Use this to discover package structure.' It implies when to use but does not explicitly state when not to use or provide alternatives. However, no similar sibling tools exist, so the guidance is sufficient.
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 provided, so description carries full burden. It mentions range and default but does not disclose other behavioral aspects like prerequisites (player must be in world) or failure modes. It is adequate but lacks depth.
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, front-loaded with purpose. No redundant information; every word adds value.
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?
Simple tool with one optional parameter and no output schema. Description covers purpose, null case, and usage hint. Could mention return type, but overall adequate for the 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?
Schema coverage is 100% (one parameter with description). Main description does not add extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns entity ID player is aiming at, or null. It distinguishes from siblings by specifying the target (what the player is looking at) and suggests pairing with mc_entity_details, which covers a different use case.
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?
Description explicitly states usefulness for 'what is that thing?' questions and recommends pairing with mc_entity_details. It implies when to use but does not explicitly state when not to use or list alternatives like mc_block_details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the return data but does not explicitly state whether the tool is read-only or has side effects. However, it implies a safe read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the main purpose and adding useful details without any redundant or unnecessary text.
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 no parameters and no output schema, the description adequately covers the return data but uses 'etc.' which implies incompleteness. Still, it provides sufficient context for an agent to understand the tool's output.
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?
With zero parameters, the schema coverage is 100% by default. The description adds value by listing expected return fields, providing context beyond the empty 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 provides a structured snapshot of the game state, listing specific data like player position, health, and weather. It distinguishes from siblings by focusing on a broad overview rather than specific details.
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 a quick overview and mentions no scripting needed, but does not explicitly state when to use it versus alternatives like mc_nearby_blocks or mc_entity_details.
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, the description provides transparency about result limits (default 200, max 5000) and the limit parameter. It does not mention side effects, but as a query tool, this is adequate. No contradiction with annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The purpose is front-loaded, and important constraints are in the second sentence. Every sentence serves a 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?
Given that there is no output schema, the description does not specify the return format (e.g., list of class names). However, the tool's simplicity and the fact that it's a search tool make this acceptable. It covers purpose, parameters, and limits well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds context beyond the schema: it explains the default and max for limit, and gives examples for className. The direction parameter is clarified with examples. This adds meaningful value to the schema descriptions.
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 'find' and the resource 'classes that extend or implement a given class/interface'. It distinguishes between 'subclasses' and 'implementors', which differentiates it from sibling tools like mc_find_refs and mc_list_classes.
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 says 'Useful for understanding class inheritance relationships', which implies when to use the tool, but does not explicitly state when not to use it or provide alternatives. Sibling tools are not mentioned, so guidance is only implied.
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, the description carries full burden. It discloses a key side effect: glow may 'stick' to a stale entity ID if its chunk unloads, but states it is harmless. Also clarifies client-side nature.
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?
Every sentence adds value: purpose, usage context, and a harmless side effect. No redundant or wasteful phrasing.
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 no output schema, the description adequately covers purpose, usage, and side effects for a simple set toggle tool. It could mention return behavior but is not essential.
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 100%, so the schema already documents both parameters. The description adds context for entityId by referencing mc_nearby_entities, but does not provide additional semantic depth beyond the schema descriptions.
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 makes an entity render with a team-color outline or removes it. This is distinct from sibling tools like mc_set_block_glow which handle block glows, not entity glows.
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 recommends pairing with mc_nearby_entities to find entity IDs and notes that the tool is client-side only with no server authority needed. This provides clear context but does not explicitly exclude alternative usage scenarios.
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, description carries full burden. Discloses exclusion of plain terrain, return fields, and that it is for debugging. Does not mention read-only nature or performance, but covers key behavioral aspects.
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 paragraphs: first states purpose and exclusion, second details return fields and suggests follow-up tool. No fluff, well-structured.
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?
Despite no output schema, description explains all returned fields (x,y,z, blockId, type, distance). Mentions sibling tool for deeper investigation. Complete for a simple query tool.
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 100% with descriptions for both parameters. The tool description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Get nearby' with specific resource 'block-entities', lists examples (signs, chests, etc.), and explicitly states plain terrain is excluded. Distinguishes from sibling mc_nearby_entities by focusing on blocks versus entities.
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?
States use for debugging and points to mc_block_details for details. Implicitly excludes plain terrain but does not explicitly contrast with mc_nearby_entities or provide when-not-to-use 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?
With no annotations, description carries full burden. It discloses that the tool returns {gone: true} when no block-entity is present. Does not mention error handling or side effects, but for a simple read 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?
Two sentences, no redundancy, front-loaded with the tool's purpose. Every word adds value.
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 3 numeric params and no output schema, the description covers the main use case and a special condition. Could add more on return format or coordinate system, but adequate for use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description must compensate. It explains that parameters are coordinates (x,y,z) and frames them as the position of the block-entity. Adds meaning beyond the schema's type-only definition.
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 clearly states the tool retrieves details for a block-entity at a specific position, listing concrete examples (sign lines, chest contents). This distinguishes it from siblings like mc_entity_details and mc_nearby_blocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly explains when to use (to get block-entity details) and what to expect if no block-entity exists (returns {gone: true}). Implies use after mc_nearby_blocks. No explicit alternatives but context is clear.
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?
Describes result cap (default 200, max 5000), the effect of limit parameter, and that it matches exact packages and subpackages. No annotations provided, so description carries full burden; it does a good job disclosing relevant behaviors without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first defines purpose, second adds return details, third explains limit behavior. No fluff, every sentence adds value. Front-loaded with the core action.
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 no output schema, it explains return format (class names and source locations) adequately. Could mention potential errors or more detail on the result structure, but for a list tool this is sufficient. The cap and version context help completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions; description adds context like default/max for limit, version fallback, and subpackage matching. These details go beyond the schema fields, providing meaningful additional guidance.
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?
Clearly states 'List all classes under a specific package path' and differentiates from siblings like mc_list_packages (packages) and mc_get_class (single class). The description specifies the verb (list), resource (classes), and scope (under a package).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to discover classes in a package hierarchy,' giving clear context. However, it does not explicitly mention when not to use or alternatives, though the sibling set implies them. Could be improved with a direct comparison to mc_get_class or mc_list_packages.
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, the description carries the full burden. It discloses the return structure ({plain, addedTime} per message), ordering (newest-first), and the effect of includeJson. It does not mention error conditions, rate limits, or authentication, but for a read-only tool with local client data, these omissions are acceptable. The description is transparent about the data and options.
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 no wasted words. It is front-loaded with the main purpose in the first sentence, then provides technical details and usage tips. Every sentence contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional parameters, read-only), the description is complete. It explains what the tool returns (including format), how to control output with parameters, and a practical use case for includeJson. No output schema is needed as the description already covers the return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by stating the default limit (50) and explaining the purpose of includeJson ('preserves colors, styles, click events, hover events' and 'handy for parsing colored command output'). This goes beyond the schema's descriptions, providing practical usage context.
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 'Get the most recent client-side chat messages' and specifies what is included (system messages, command output). It distinguishes from a potential alternative approach (walking Groovy's getChat) and implies it is the preferred method for this data. The specific verb 'get' and resource 'chat history' make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool: when you need recent chat messages. It provides guidance on using includeJson for parsing colored command output. While it does not explicitly exclude other scenarios, it gives clear context and an advantage over a known alternative. There are no sibling tools with similar functionality, so no need for differentiation.
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?
Indicates a destructive clearing action. No annotations exist, but the description adequately conveys behavior, though it could mention any prerequisites like being connected.
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?
Single sentence that is front-loaded and contains all necessary information with zero waste.
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 parameterless tool, the description fully explains its purpose and relation to mc_set_block_glow, omitting nothing essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage is 100% and description adds no parameter info, which is sufficient. Baseline for 0 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'clear' and specific resource 'block highlights' are provided, with explicit reference to its counterpart mc_set_block_glow, distinguishing it from siblings.
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?
States clear purpose to undo mc_set_block_glow, implying when to use. No explicit when-not, but the context is clear as a complementary tool.
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 provided, but description explains port scanning, reset behavior, and auto-connect. Could detail session info more, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently structured with primary purpose first, then optional uses, then parameter-specific guidance. No extraneous 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?
Adequately covers connection behavior for a simple tool with full schema coverage. Missing detail on what 'session info' entails, but reasonable given no output schema.
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?
Adds meaning beyond schema by explaining port scanning range and reset usage. Schema descriptions are already good, and description reinforces them with examples.
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?
Clearly states 'Connect to a running Minecraft instance with the DebugBridge mod.' and differentiates from siblings like mc_quit_client and mc_leave_server.
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?
Provides context on when to use manually (non-default port, reconnect, get session info) and mentions auto-connect behavior. Lacks explicit when-not to use but is sufficiently informative.
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?
Given no annotations, the description fully bears the burden of behavioral disclosure. It accurately describes the fire-and-acknowledge semantics (ack does not mean disconnect finished) and the config requirement. No omissions or contradictions.
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 short paragraphs. The first sentence captures the core action, followed by edge cases, usage guidance, and behavioral notes. No filler or redundancy.
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 tool with no parameters and no output schema, the description covers all essential aspects: what it does, when to use, behavioral nuance (fire-and-ack), and prerequisite config. It feels 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 tool has zero parameters, so per guidelines the baseline is 4. The description does not need to add parameter information.
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 purpose: leaves the current world/server and returns to the title screen. It distinguishes itself from quitting the entire client by specifying 'end the user's current play session' and from other tools like mc_quit_client. The edge case of resetting menu screens is also mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'only do it when asked, or as part of a dev loop the user set up,' providing clear usage guidance. It also notes the required configuration setting (session_control_enabled=true). While it doesn't explicitly state when not to use it, the context is clear enough for an agent.
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 full burden. It discloses result capping, default/max limits, and details what each hit returns (class hits: kind, extends, etc.; method hits: signature, line number; field hits: declaration). This is thorough 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 well-structured: purpose first, then return details, then filtering, then limits. Each sentence adds necessary information without redundancy. It is concise yet comprehensive.
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?
Despite no output schema, the description fully explains return values for all result types. All parameters are covered, and the description provides enough context for an AI agent to use the tool correctly. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 4 parameters. The description adds value by specifying defaults ('defaults to all three') and behavior for non-finite limit values ('Non-positive or non-finite values fall back to default'), which enhances understanding 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 begins with a clear verb+resource: 'Search decompiled Minecraft or Fabric API source code for classes, methods, or fields by name pattern.' It distinguishes from siblings like mc_get_class and mc_get_method by implying this is for searching by pattern, not for fetching specific items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that type filter defaults to all three and that limit can be widened, providing clear context for usage. However, it does not explicitly state when to use this tool versus alternatives like mc_find_refs or mc_find_hierarchy, though the context of searching by name pattern is implied.
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 provided, so description carries full burden. It reveals version-specific behavior (1.19 vs 1.21.11) and the ability to add or remove highlights. Lacks details on persistence or side effects, but sufficient for a simple highlight 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?
Three sentences, front-loaded with core purpose, efficient. No wasted words.
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 tool with no output schema and 4 parameters, description covers purpose, usage, version-specific behavior, and cross-tool references. Complete and self-contained.
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 only 25% (only glow described). Description mentions position parameters implicitly via 'block in-world' and cross-reference to mc_nearby_blocks, but does not add detailed parameter semantics. Some compensation but not full.
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 clearly states the tool highlights a block in-world or removes the highlight, specifying version-dependent visual behavior. It distinguishes itself from sibling mc_clear_block_glow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: useful for pointing out specific blocks, recommends pairing with mc_nearby_blocks for position finding, and directs to mc_clear_block_glow for clearing all highlights.
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 provided, so description carries full burden. It states 'Read-only; doesn't require session control', explains port sweeping and verification logic. However, it doesn't fully detail what happens after connection (e.g., return value or state change), though it is implied.
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?
Concise and well-structured: first sentence states main action, then provides verification details, then usage guidelines. No filler, every sentence adds value.
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?
No output schema, so description should clarify return values. It mentions timeout causes but doesn't specify what the tool returns on success or failure. Given two parameters and simple wait, it's mostly complete but missing output specification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters fully. Description adds context for expectedVersion about overriding previous identity and switching instances, providing extra meaning beyond schema. Timeout is mentioned but without default.
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 clearly states the tool blocks until a freshly launched client's DebugBridge answers then connects. It explicitly distinguishes from polling mc_connect and mentions alternatives, making purpose clear and distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this instead of polling mc_connect yourself' and provides context like after mc_quit_client + launch command, referring to a guide. Also mentions timeout causes, offering clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses what information is included (equipment slots with damage, custom names, mounted vehicle, passengers, attributes, frame contents) and the special return case ({gone: true}) for despawned or unloaded entities. No annotations are provided, so the description carries full burden and does it well.
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: two sentences covering main purpose, included details, and edge case. Every sentence adds value, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers the tool's behavior well but does not specify error handling for invalid ids beyond the gone case. It is fairly complete for a single-parameter tool.
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 covers 100% of the single parameter with a basic description. The tool description adds context by specifying the id sources (mc_nearby_entities or mc_looked_at_entity), adding 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's purpose: 'Get full details for one entity by id'. It specifies the source of the id (from mc_nearby_entities) and distinguishes from sibling tools like mc_nearby_entities (listing) and mc_looked_at_entity (getting looked-at entity).
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 indicates when to use the tool (to get details for a specific entity) and what the id should come from. It does not explicitly state when not to use it or mention alternatives, but the context is clear given sibling tools.
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 full burden. It discloses return structure, special handling for containers, and parameter behavior. No destructive or auth details are needed based on tool nature.
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 yet comprehensive. Every sentence serves a purpose, and the most important information (core function) is front-loaded. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single optional parameter and no output schema, the description covers all essential aspects: what it returns, special cases, and parameter effects. It's complete for an AI agent to use correctly.
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 description adds significant value beyond the schema's parameter description. It explains the icons map format, deduplication, and response size impact, giving the agent a clear understanding of what includeIcons does.
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 takes a snapshot of the currently open screen, distinguishing between no screen, container screens, and others. It uses specific verbs and resource context, and is distinct from sibling tools like mc_screenshot and mc_snapshot.
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: to inspect open screens, especially containers where it's cheaper than iterative slot reading. It could be more explicit about when not to use, but overall it's helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes polling interval (every second), detection logic (player snapshot vs DisconnectedScreen), timeout behavior, and the nuance of requireAbsenceFirst. No annotations, so full burden carried.
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?
Well-structured with main purpose first, then details. Could be slightly more concise but no wasted sentences.
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?
Comprehensive for a polling tool with no annotations or output schema. Covers success, failure, timeout, parameter nuances, and read-only nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100%, but description adds context: default timeout of 60 seconds and detailed explanation of requireAbsenceFirst's purpose. Adds value beyond 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 polls until the player is in a world or join fails, with a specific verb ('poll until') and resource ('player in world'). It distinguishes from siblings by noting usage after mc_join_server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (after mc_join_server with wait=false, after relaunch) and when to set requireAbsenceFirst. No explicit exclusion of alternatives, but context is clear.
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 provided, so description carries full burden. It discloses that the tool returns curated data and an optional icons map, and clarifies deduplication. Lacks mention of rate limits or performance, but is otherwise 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?
Two concise paragraphs: first states core purpose and return, second gives usage guidance and optional feature. No redundant sentences, well-structured.
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?
Despite no output schema, the description sufficiently explains the return shape and optional icons. Combined with full param coverage, it is complete for an agent to use effectively.
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?
All three parameters have schema descriptions (100% coverage). The description adds context: includeIcons explanation and deduplication behavior, enhancing 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 retrieves nearby entities (mobs, items, etc.) and lists returned fields (id, type, position, distance, primaryEquipment). It distinguishes from sibling tools like mc_execute and mc_entity_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to prefer this over iterating via mc_execute, and directs to mc_entity_details for specific entity details. Also explains the includeIcons option as an alternative to per-entity texture calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that capture runs on the render thread, pauses for at most one frame, works while paused, and requires mod and MCP server on the same machine. No annotations are provided, so the description carries full burden and covers it well.
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?
Five sentences, each adding essential information. Front-loaded with core purpose, then behavior, defaults, and requirement. No redundant or unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema (two optional params, no output schema), the description is fully complete. It explains capture behavior, usage path, and default rationale. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes both parameters with coverage. Description adds value by explaining the defaults and suggesting when to override (higher fidelity). This helps the agent choose appropriate values.
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?
Clearly states it captures the Minecraft client framebuffer as a JPEG and returns its absolute path. Distinguishes from sibling tools like mc_screen_inspect and mc_snapshot by specifying the exact operation and output.
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?
Provides guidance on using the Read tool to view the image and notes defaults tuned for low-bandwidth inspection. However, it does not explicitly differentiate when to use this tool over related siblings like mc_snapshot or mc_screen_inspect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description thoroughly covers persistent binding, sandbox restrictions, thread hopping, return value handling, serialization, timeout, and migration from Lua.
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?
Long but well-structured, front-loaded with key usage guidance and progressive detail. Every section earns its place, though minor redundancy possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity, no annotations or output schema, the description covers all critical aspects: return values, error handling, threading, serialization, migration, and sandbox restrictions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds valuable context for both parameters: code is Groovy script with persistence, timeoutMs has default and usage tips.
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 'Execute GROOVY code in the Minecraft session' and distinguishes from sibling tools by listing preferred native tools for specific tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to prefer native tools when possible, lists alternatives for common tasks, and specifies when to use mc_execute (exploring Java API or unsupported cases).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: disconnects current session, pre-accepts resource packs, bridge ack mechanism, polling logic, and handling of wait flag. No contradictory statements.
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?
Well-structured with front-loaded purpose and logical breakdown of behaviors. While detailed, some paragraphs (e.g., bridge ack) could be slightly more concise, but overall efficient for required depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters and no output schema, the description fully covers tool behavior, side effects, prerequisites, and success/failure indicators (snapshot vs DisconnectedScreen). No gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions, but the description adds meaningful context for parameters like 'wait' (explains polling behavior) and 'acceptResourcePacks' (pre-accepted by default). Adds value beyond 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?
Clearly states 'Join a multiplayer server by address', provides scope (disconnects current world), and distinguishes from sibling tools like mc_leave_server and mc_connect by specifying the action and side effects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (joining a server), when not to (don't point without being asked), and provides specific guidance for automated tests (prefer local server), plus mentions required config setting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers behavioral traits: the graceful shutdown process, fire-and-acknowledge mechanism, wait fallbacks, PID resolution, and requirement for session_control_enabled=true.
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 yet comprehensive, with the core purpose front-loaded and all necessary details included without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and two parameters, the description is complete: it covers shutdown process, wait behavior, fallbacks, requirements, and references a guide for deeper context.
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 description adds significant meaning beyond the schema by explaining the wait mechanism, fallback behavior, and recommendations when PID cannot be resolved, enhancing the schema's basic descriptions.
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 purpose: 'Gracefully shut down the entire Minecraft client.' This distinguishes it from siblings like mc_leave_server, which only leaves a server without quitting the client.
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 explicit usage context: 'only do it when asked, or as part of a dev loop...' and references a guide. It implies not to use it casually but does not explicitly name alternatives like mc_leave_server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: output modes, caps (frames, interval, downscale, quality), that request is rejected if caps exceeded, that 'frame' may drop frames and the 'dropped' response field, and file storage location.
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 well-structured with clear sections and front-loads the purpose. It is slightly lengthy but every sentence is informative; minor redundancy in caps listing could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, no annotations), the description covers all necessary aspects: purpose, parameter behavior, output modes, usage guidance, technical constraints, and differential from siblings.
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?
Schema coverage is 100%, but the description adds significant value beyond the schema: recommended interval values, default for downscale (2), default quality (0.75), default gridCols calculation, and that quality applies once in grid mode.
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 captures a short burst of the Minecraft framebuffer for debugging temporal rendering issues, explicitly distinguishing it from mc_screenshot for static captures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use (temporal issues), when not to (use mc_screenshot instead), and provides concrete recommendations like defaulting to 50-100 ms interval rather than 'frame', and notes the requirement for mod/server on the same machine.
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:

[![mcdev-mcp MCP server](https://glama.ai/mcp/servers/use-ai-for-mc/mcdev-mcp/badges/card.svg)](https://glama.ai/mcp/servers/use-ai-for-mc/mcdev-mcp)

Score Badge

Copy to your README.md:

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

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