Minecraft Structure Lab

Overview Schema Source Related Servers Score Discussions Admin

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Most tools target clearly distinct actions: generation, validation, submission, capture, export, and cancellation are well separated. Minor confusion is possible between lab_status and job_status since both report progress, but the descriptions clarify that one is general and the other is revision-specific.
Naming Consistency4/5
The vast majority of tools follow a clear snake_case verb_noun pattern such as list_blocks, validate_structure, and export_structure. The two status tools, lab_status and job_status, are noun-style deviations, but the pattern is otherwise predictable and easy to navigate.
Tool Count5/5
Thirteen tools is well-scoped for a Minecraft structure lab, covering registry inspection, structure generation, validation, submission, screenshot capture, export, and job control. Each tool serves a meaningful role in the workflow without redundancy or bloat.
Completeness4/5
The toolset provides strong lifecycle coverage: generate, validate, submit, recapture, inspect, export, and cancel. The main gap is the lack of an explicit delete/clear operation for the active structure, though submit_structure effectively replaces it and cancel_job handles in-progress work.
Average 3.2/5 across 13 of 13 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on September 7, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals one behavioral detail: revision 2 removes the gold sentinel and changes bedroom carpet. However, it does not explain broader side effects, required permissions, destructive potential, or what 'generate' entails beyond this revision-specific note.
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 brief and free of redundant phrasing, making it easy to read. It is not overly verbose, though it could be slightly clearer by avoiding the somewhat vague term 'furnished house fixture.'
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and no parameter descriptions, the description leaves many essential details unspecified. An agent would likely have to infer how to call this tool correctly, what the output looks like, and how it differs from sibling tools.
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 has two parameters with zero description coverage. The revision parameter is partially explained by the revision-2 note, but output_path is entirely unexplained, and no parameter-level details such as format, allowed values, or behavior are provided.
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 identifies a specific action ('Generate') and a clear resource ('the furnished house fixture'), which is more specific than a generic verb. However, it does not explicitly distinguish this from the sibling 'generate_structure' tool, leaving some ambiguity about when each is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as 'generate_structure' or other sibling tools. The description does not mention prerequisites, context, or conditions under which this tool should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 says 'Request cancellation,' which implies an action but does not state side effects (e.g., whether the job is permanently terminated, whether it is reversible, or what happens to the revision). This is a significant gap for a potentially destructive operation.
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 with no wasted words, and the core action is front-loaded. However, it is under-specified rather than concisely complete, so it scores slightly below 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimal but does not provide enough context for an agent to decide when to call it. It lacks information about the meaning of 'current revision' and the expected outcome, leaving the tool insufficiently documented.
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 has zero description coverage, and the description does not explain the meaning or format of the 'revision' parameter. An agent cannot infer what value to provide or how it relates to the cancellation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('cancel') and a resource ('current revision'), which clearly indicates the action. However, 'current revision' is ambiguous without additional context, and there is no explicit differentiation from sibling tools, though cancellation is a distinct operation.
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?
There is no guidance on when to use this tool versus alternatives, nor any prerequisites such as checking job status first. The description does not mention any conditions that should trigger cancellation or any prior checks needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states the output type and resolution, but omits any details about cost, side effects, network dependencies, or whether the operation is read-only. This is a significant gap for a tool that likely fetches an image.
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 a single short sentence with no fluff, which is concise. However, it is under-specified—it fails to include necessary context about parameters or usage, so its brevity is not a virtue here. The structure is acceptable but not front-loaded with important constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three required parameters with zero schema coverage, no output schema, and no annotations, the description is severely incomplete. An agent cannot know what inputs to provide or what the returned image content will contain beyond a vague 'Minecraft screenshot.' This tool definition is far from minimally viable.
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 has 0% description coverage for its three parameters (revision, view_id, angle_id). The description does not explain what these parameters mean, how they relate to the screenshot, or what valid values look like. The agent is left completely in the dark about how to fill them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a Minecraft screenshot as MCP image content, specifying a 1920x1080 resolution. However, it does not differentiate itself from sibling tools like list_captures or recapture_views, leaving the agent to infer which tool to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, context, or exclusion conditions, so an agent has no explicit basis for selecting it over similar 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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It reveals a 200-item limit and that data comes from the live game, but it does not explain how the query parameter affects behavior, what 'valid properties' means, or how results are ordered or returned.
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 concise sentence that front-loads the core action and result. It avoids redundancy, though it is somewhat terse and could carry more useful detail without becoming verbose.
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 tool with no annotations, no output schema, and an undocumented parameter, the description is too sparse. Missing details include the purpose of 'query', the structure of returned properties, whether the list is paginated, and how this relates to sibling tools like inspect_blocks.
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 has one optional 'query' parameter with no description and 0% schema description coverage. The tool description does not mention the query parameter at all, leaving the agent without any hint about how to use it or what values are valid.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find' and the resource 'block IDs and their valid properties', with a specific scope ('up to 200') and source ('from the live game'). It is easy to understand what the tool does, though it does not explicitly distinguish itself from the sibling tool inspect_blocks.
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 usage guidance is provided. The description does not say when to use list_blocks instead of alternatives like inspect_blocks or list_captures, nor does it mention any conditions 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?
No annotations are provided, so description carries the burden. It discloses 'clean NBT' and 'No lab blocks survive' indicating cleaning behavior, and specifies version 26.2. However, it does not mention side effects like file overwriting, behavior for unverified revisions, or output path handling.
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 with no wasted words. It efficiently states the core action, output format, and a key behavioral constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters and no output schema, the description is too terse. It does not clarify required fields, what output_path refers to, or how revision relates to verification, leaving an agent to guess from parameter names.
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?
Schema description coverage is 0% and the description does not explain any of the four parameters (name, revision, namespace, output_path). Defaults exist but their meaning is left entirely to schema, so the description adds no parameter value.
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?
Description states a specific verb 'Export' with resource 'verified revision' and output formats (NBT and datapack ZIP). It clearly distinguishes from generating tools, but does not explicitly contrast with siblings like generate_structure or submit_structure.
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. It implies a precondition (verified revision) but does not state when to choose this over generate_structure or submit_structure, nor 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?
The description mentions the tool rejects stale job IDs, which is a behavioral detail. However, without annotations, it does not disclose other potential side effects, error behaviors, or prerequisites beyond that single rejection case.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short clauses—with no redundant information. It is efficiently structured and every word contributes to the meaning.
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 description does not explain what 'progress' means, what the return value looks like, or how the 'revision' should be formatted. Given the lack of an output schema, these missing details make it incomplete for an agent to confidently use the tool.
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 only parameter 'revision' is a string, but its meaning, format, and relationship to 'job IDs' are entirely unexplained. Since the schema provides no description, the tool description must clarify it but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (read progress) and the resource (a specific revision), and the mention of rejecting stale job IDs adds specificity. However, it does not explicitly differentiate from the sibling 'lab_status' tool, so it is not a perfect 5.
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 gives no explicit guidance on when to choose this tool over similar alternatives (e.g., lab_status) or what conditions warrant using it. The intended usage is only implicit from the verb 'read'.
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?
Without annotations, the description carries the burden of disclosing behavior. It mentions no code execution and the use of submit_structure schema for views, but it does not disclose that the tool writes to output_path, potential side effects, or required permissions. The behavior is partially transparent.
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 somewhat fragmented: it starts with a purpose, then lists operation examples, then adds sentences about views and the Python library. It is not poorly written but lacks a clear organization that could make it more concise and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description should clarify what the tool returns or produces. It only says 'Generate NBT' but does not state that it writes to output_path or describe the output format. Critical context about the relationship between operations and the resulting structure is missing.
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?
Schema coverage is 0% and the description does not explain the parameters size, views, operations, or output_path. It provides example operation objects but not their field meanings, nor does it clarify how size or views relate to the generation. Parameter semantics are largely missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates NBT from set/fill/room operations, which is a specific verb and resource. However, it does not explicitly differentiate it from siblings like generate_example_house, though the generality of 'operations' provides some distinction.
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 notes 'no Python code execution required' and references the submit_structure schema and Python Structure library, giving some usage context. But it does not explicitly state when to use this tool over alternatives such as generate_example_house or export_structure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden of behavioral disclosure. It communicates that the tool returns status information and implicitly indicates a read operation via 'Get', but it does not state whether any state is changed, whether authentication or a live connection is required, or how the data is structured beyond broad categories.
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 names the operation and enumerates the main output categories without any filler. Every word contributes to understanding the tool's 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 the tool takes no parameters and has no output schema, the description covers the essential return categories: identity, limits, readiness, and job progress. It is slightly incomplete in not clarifying how this relates to job_status, but for a zero-input status tool it provides enough context for basic invocation.
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 schema description coverage is 100%, so there is nothing meaningful for the description to add about inputs. The description appropriately focuses on what the tool returns rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and a specific resource ('world identity, limits, connection readiness, and active job progress'). It is more than a tautology and conveys the tool's scope, but it does not differentiate lab_status from the sibling tool job_status, which also likely reports job progress.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use lab_status versus alternatives such as job_status. The description implies this is a general status/readiness check, but it never states when this tool should be chosen over a sibling or what conditions favor another tool.
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 convey behavioral traits. It mentions that image bytes are not returned, which is helpful, but it does not disclose whether the operation is read-only, any side effects, pagination behavior, or rate limits.
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, focused sentence with no unnecessary words or redundancy. It is well-structured and immediately conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is too sparse. It does not explain parameter meanings, expected output structure, pagination mechanics, or how this tool fits into common workflows. The agent may struggle to use it correctly.
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 input schema has 0% description coverage. The description does not explain any of the parameters (limit, offset, revision, with revision required). Since the schema only provides names and types, the lack of explanation leaves the agent without enough guidance for correct invocation.
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 action (list), the resource (labeled screenshot metadata), and a distinguishing behavior (without returning all image bytes). This differentiates it from sibling tools like get_capture, which likely returns full images.
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 'without returning all image bytes' implies when to use this tool (when metadata only is needed) and contrasts with tools that return full images. However, it does not explicitly name alternatives or provide more detailed selection 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?
With no annotations, the description carries the full burden. It transparently states this is a read operation ('Read') and emphasizes 'authoritative' block states, implying it returns ground truth rather than a cached view. However, it doesn't disclose the return format or any edge cases, though the simplicity of a read operation limits the gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the verb and resource, then adds purpose within a compact clause. No filler or redundant statements, making it easy to parse quickly.
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?
Despite having only one parameter and no output schema, the description is incomplete for correct invocation. The meaning of 'relative positions' is ambiguous (relative to what?), and the return structure is not described. An agent would need additional context or assumptions to call this tool reliably.
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?
Schema description coverage is 0%, so the description must compensate. It adds the important qualifier 'relative' to 'positions', but it does not explain the coordinate system, what the positions are relative to, or how the nested array structure maps to coordinates. This leaves most parameter meaning to be inferred from 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 states a specific verb ('Read'), a clear resource ('authoritative block states'), and the operational context ('at relative positions, for placement and cleanup verification'). This clearly distinguishes it from siblings like list_blocks by focusing on targeting specific positions rather than enumerating all 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?
The description gives clear context on when to use this tool ('for placement and cleanup verification'), implying it is used for verifying specific block positions. However, it doesn't explicitly mention alternatives or when not to use it, leaving some comparison to siblings to inference.
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 says 'validate' but does not disclose whether the tool is read-only or if it modifies the structure, nor does it mention error behavior 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 a single, clear sentence with no unnecessary information.
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?
There is no output schema or annotation, and the description does not explain what the validation result looks like (e.g., success/failure messages, error codes, or log output). It is adequate for a basic understanding but lacks completeness for an agent to anticipate the tool's full behavior.
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 provides only a 'path' parameter with no description. The tool description mentions 'existing compressed NBT structure', giving some context that path should point to such a file, but it lacks details on file format, required extensions, or any constraints on the path.
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 validates an existing compressed NBT structure against the game's registry and limits, distinguishing it from generation, export, or submission tools.
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 a validation use case but does not explicitly state when to use this tool over alternatives like inspect_blocks or export_structure, nor does it mention 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.
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 a destructive side effect (old screenshots deleted per retention policy) and a non-destructive guarantee (blocks not replaced). It lacks error conditions or prerequisites but covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no redundancy. The main purpose is front-loaded, and the side effect is stated clearly. 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?
For a two-parameter tool without an output schema, the description covers the core purpose and side effect, but leaves gaps about the exact semantics of 'revision' and the structure of 'views_path'. Given the low complexity, it is mostly 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 coverage is 0%, so the description must explain parameters. It explains 'views_path' via the 'optional sidecar' clause (omitted reuses current views), but the 'revision' parameter is not explicitly defined beyond its role in the operation. The format of the sidecar is also unspecified.
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 (capture), the resource (placed build), and a differentiator ('without replacing blocks'). It also specifies the result (new revision and capture set), distinguishing it from sibling capture retrieval tools like list_captures or get_capture.
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 by describing the sidecar behavior and the non-replacement aspect, but does not explicitly mention alternatives or when not to use this tool. The guidance is more about parameter behavior than tool selection.
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 present, the description carries the full behavioral burden. It discloses async behavior ('Returns a job immediately'), the polling requirement, coordinate-space semantics, the eye_height default of 1.62, and automatic extraction of embedded view pads. This is substantial transparency for a mutation-like 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 four information-dense sentences, front-loaded with the core action and async return behavior, then the supporting views JSON format. There is no filler, repetition, or ambiguity caused by loose wording.
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 tool with no output schema and no annotations, it covers the critical operational loop: submit, receive a job, and poll job_status. It also supplies the views JSON layout and defaults. The main gap is the unexplained required path parameter, which prevents full completeness.
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 0%, so the description must compensate. It thoroughly explains views_path through the 'Optional views JSON' format and coordinate details, but it never describes the required path parameter—what it points to or what formats are accepted. One parameter gets rich semantics, while the other remains opaque.
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 first sentence names a specific action ('Replace the active structure') and intended outcome ('automatically capture all angles'). It is clearly distinct from siblings like validate_structure and recapture_views, and 'Returns a job immediately' further frames it as an asynchronous submission operation.
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 establishes a clear workflow: submit the structure, receive a job, then 'Poll job_status until complete or failed.' It does not explicitly name alternative tools or state when not to use this tool, so it stops short of a 5, but the usage context is unambiguous.
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

Minecraft Structure Lab MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![Minecraft Structure Lab MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/ewitulsk/MinecraftStructureInjector/badges/card.svg)](https://glama.ai/mcp/servers/ewitulsk/MinecraftStructureInjector)

Score Badge

Copy to your README.md:

[![Minecraft Structure Lab MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/ewitulsk/MinecraftStructureInjector/badges/score.svg)](https://glama.ai/mcp/servers/ewitulsk/MinecraftStructureInjector)

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/ewitulsk/MinecraftStructureInjector'

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