A
licenseNot graded
qualityF
maintenanceEnables dynamic creation and code generation of MCP servers using FastMCP, with tools for adding custom tools, resources, and generating runnable Python code.
41
MIT
Minecraft Structure Lab
by ewitulsk
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Minecraft Structure LabGenerate a house structure and capture a view from the front."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Minecraft Structure Lab
A NeoForge 26.2 mod and local MCP server for generating NBT structures, placing each revision into a dedicated superflat world, and returning labeled screenshots rendered by Minecraft.
Version 0.2.0 extends the generate → validate → replace → capture → revise → export loop to large builds. The Nebraska State Capitol example occupies 185 × 130 × 185 blocks and was refined through three real Minecraft capture reviews. It uses one real client camera sequentially. No extra renderer, RCON server, or manual camera cycling is needed.
Install
Download the JAR and MCP wheel from the latest release.
Install the Minecraft mod — Modrinth setup, supported versions, and creating the Structure Lab world.
Install the MCP server — Python setup, Codex registration, generic MCP configuration, and a first capture.
The tested setup is Windows, Minecraft Java 26.2, and NeoForge 26.2.0.79. This release requires NeoForge 26.2.0.77 or newer within Minecraft 26.2, Java 25 for Minecraft, and Python 3.11+ for MCP. Minecraft and MCP run on the same machine. The JAR alone does not install the MCP server.
Get the Capitol model, references, placement instructions, and review history.
The mod exposes a local HTTP bridge; the external Python process exposes MCP over stdio. Codex or another MCP client starts that process automatically. The bridge creates an ephemeral localhost port and bearer token in <instance>/structurelab/connection.json. Keep the connection file private.
Related MCP server: DeepSlate MCP
MCP workflow
Tool | Purpose |
| Read world readiness, origin, resource limits, and active job. |
| Query live registry IDs and legal properties. |
| Build an NBT using JSON |
| Generate the furnished example, revision 1 or 2. |
| Validate NBT coordinates, palette, registry IDs, properties, and limits. |
| Import a file with optional views JSON; replace and capture automatically. |
| Capture the current completed structure again, optionally with revised cameras, without clearing or placing blocks. |
| Poll or cancel a specific revision. |
| List labels and return individual MCP image content. |
| Read authoritative placed block states. |
| Copy the clean NBT and package a vanilla 26.2 datapack ZIP. |
Example calls, using absolute paths:
generate_example_house(output_path="D:/builds/house.nbt", revision=1)
validate_structure(path="D:/builds/house.nbt")
submit_structure(path="D:/builds/house.nbt", views_path="D:/builds/house.views.json")
job_status(revision="<returned UUID>")
list_captures(revision="<returned UUID>")
get_capture(revision="<returned UUID>", view_id="bedroom", angle_id="beds")
export_structure(revision="<returned UUID>", output_path="D:/exports/house.nbt")Wait for completion before exporting or submitting another revision. Overlapping submissions are rejected. Old revision IDs are rejected once a new job becomes current.
Authoring NBT and views
The Python library supports sparse blocks, explicit air, block states, and typed block-entity NBT:
from structurelab import Structure
s = Structure((12, 8, 12))
s.room((0, 0, 0), (11, 6, 11), wall="oak_planks", floor="stone_bricks")
s.set((5, 1, 0), "air")
s.set((5, 2, 0), "air")
position = (5.5, 1, -6)
s.view("spawn", position, [
{"id": "front", **s.look_at(position, (5.5, 3, 5))}
], spawn=True, label="Front entrance")
s.save("D:/builds/my-house.nbt")Views may be a sidecar JSON list, or embedded structurelab:view_pad blocks. Structure.view(..., pad=(x,y,z)) writes a pad with block-entity metadata. Each pad has a unique ID, label, feet position relative to the structure origin, and ordered angles:
[
{
"id": "bedroom",
"label": "Bedroom",
"position": [11.5, 1, 6.5],
"eye_height": 1.62,
"spawn": false,
"angles": [
{"id": "beds", "yaw": -90, "pitch": 10, "fov": 70},
{"id": "window", "yaw": 0, "pitch": 0, "fov": 70}
]
}
]Minecraft yaw 0 faces +Z, yaw -90 faces +X; positive pitch looks down. FOV defaults to 70 and must be 30–110. Eye height defaults to 1.62 and must be 0–4. Optional render_distance is an integer from 4 to 24 chunks on a view; a batch temporarily raises the client distance to the largest requested value and restores the previous setting afterward. IDs must use letters, digits, underscores or hyphens, at most 64 characters. Angle IDs are unique within their view.
For direct NBT authoring, a pad stores the JSON object as the string nbt.view.json. If the JSON omits position, the camera uses the block center in X/Z and its Y coordinate as feet height. Optional nbt.view.replacement is a vanilla palette-style compound with Name and optional Properties. The default replacement is air. Pad metadata is extracted before placement; pad block entities and unused pad palette entries are stripped from the export. A pad replacement does not preserve a separate block entity.
Mark one view spawn: true. Its first angle is captured first and the player returns there after the batch. With no views, an exterior view is generated. With views but no spawn flag, the first view is the return point. An in-game pad configuration screen is not part of this milestone.
Replacement and capture behavior
One structure at fixed origin
(0, -60, 0)above the flat grass layer.Each submission is copied into an immutable revision directory before reading. No partial-file watcher races.
The old/new bounding box is cleared one chunk column per server tick, skipping empty sections. Non-player entities in that box are removed. The template is placed one chunk at a time with native block-entity loading and suppressed incidental placement side effects. Jobs report
clearing/placing,processed, andwork_total.Placement temporarily disables pause-on-focus-loss before beginning the chunk batches; capture restores the earlier setting.
The lab freezes simulation and fixes daylight/weather. This is visual inspection; redstone and mob simulation validation are deferred.
Before each screenshot, the mod waits for the player/camera position and angles, nearby chunks, lighting work, and section rendering to settle. A view has a 60-second readiness timeout.
Captures use Minecraft's actual framebuffer at 1920×1080 PNG, with HUD and view bobbing hidden. A windowed client is resized during the batch and restored afterward. Fullscreen must already be 1920×1080 or the batch reports an error.
Files use
<view-id>__<angle-id>.png. The manifest includes revision UUID, input SHA-256, labels, position, yaw, pitch, FOV and image dimensions.The previous successful revision remains on disk while a replacement is processed. After a successful replacement, its old revision directory and screenshots are removed. Failed revisions are retained for diagnosis and currently need manual cleanup. Explicit exports and the test evidence folders are never automatically deleted.
A placement recovery ledger persists the affected bounding box across world reloads. The next submission clears it. This is recovery on the next submission, not transactional rollback to the previous build.
Instance data lives under structurelab/revisions/<UUID>/; structurelab/latest.json points to the last success. Job polling is in memory: after restarting Minecraft, submit again to make a revision available through MCP.
Current limits
Limits are explicit resource budgets, not claims that every maximum-size combination has been qualified.
Width and length: at most 1024 each. Height: at most the world permits; the default lab origin permits 380 blocks through Y=319.
Bounding volume: 16,000,000 positions, even for sparse NBT. Combined old/new cleanup bounding volume: 32,000,000 positions. At most 1,000,000 explicit block records, 64 MiB compressed input, and a 256 MiB NBT accounting budget. Very different shapes may require a fresh lab world.
Up to 1024 angle definitions are accepted. Tested examples include the five-angle house and the 429,341-record Capitol with 16 angles at 1920×1080. The full 1024-angle limit and maximum volume have not been performance-qualified.
One palette; entity templates and multi-palette structures are rejected. Block entities are supported, but arbitrary mod-specific block-entity behavior is not comprehensively validated.
No disk quota, automatic failed-job pruning, dedicated-server/RCON workflow, or shader compatibility guarantee yet.
Export removes Structure Lab pads. Builds using other mods retain those dependencies;
export_structurereports their namespaces. The example exports with no non-vanilla dependencies.
Vanilla datapack export
export_structure writes the requested .nbt and a neighboring .zip with:
pack.mcmeta
data/lab_export/structure/house.nbtCopy the ZIP into a target world's datapacks folder, run /reload, then:
/place template lab_export:house 0 -60 0Namespace and name can be changed in the export call. The exported format targets Minecraft Java 26.2, DataVersion 4903, datapack format 107.1.
Build and install elsewhere
Java 25 and Python 3.11+ are required. This project compiles against NeoForge 26.2.0.77; the actual Modrinth run was on 26.2.0.79.
.\gradlew.bat build --console=plain
py -3.13 -m venv .venv
.\.venv\Scripts\python.exe -m pip install -e . pytest
.\.venv\Scripts\python.exe -m pytest -qIn a stopped Modrinth NeoForge 26.2 instance, select Content → Upload files and choose build/libs/structurelab-26.2-0.2.0.jar (not the sources JAR), then launch it and create a Structure Lab world.
See MCP installation for release-wheel installation, source installation, and client registration. Set STRUCTURELAB_CONNECTION to the absolute connection-file path when running the integration scripts against an instance other than the default Modrinth NeoForge 26.2 profile.
Verification
The Capitol case study documents three large-build iterations. Generate it with python examples/nebraska_capitol.py --revision 3 --output artifacts/capitol/iteration-3/capitol.nbt, then run python scripts/capture_capitol.py artifacts/capitol/iteration-3 with the lab open. Add --recapture to exercise camera-only recapture of the current build. These commands replace the active lab structure or its capture set.
With the lab world open, these scripts use real MCP initialization and stdio tool calls:
.\.venv\Scripts\python.exe scripts/mcp_probe.py
.\.venv\Scripts\python.exe scripts/verify_milestone.py 1
.\.venv\Scripts\python.exe scripts/verify_failure.py
.\.venv\Scripts\python.exe scripts/verify_milestone.py 2The integration scripts intentionally replace the current lab structure. They generate a furnished house, obtain five images through MCP, inspect block states, and export NBT/datapacks. Revision 2 shrinks the bounds, removes the gold sentinel, and changes blue carpet to red.
Local integration runs save evidence under artifacts/evidence/v1 and v2. These generated files are ignored by Git. The original milestone verification also saved vanilla evidence locally. The vanilla test uses a separate Structure Lab Vanilla Verification instance created and launched through Modrinth, with no mods installed. Its log confirms vanilla loaded lab_export:house; vanilla/exterior.png shows the placed export.
The original local run recorded the installed JAR hash and completed checks in artifacts/evidence/verification.json. A portable summary is in milestone verification. The failure test verifies that an invalid eye height produces a pollable failed job while preserving the previous world and successful images. Visual review also caught a camera on a wall boundary; the example's kitchen viewpoint was moved into open space and recaptured successfully.
License
MIT. This project is not affiliated with Mojang or Microsoft.
Available Tools
13 toolscancel_jobC
Request cancellation of the current revision.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| revision | Yes |
TDQS
C2.4/5.0
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.
export_structureC
Export a verified revision as clean NBT plus a vanilla 26.2 datapack ZIP. No lab blocks survive.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | house | |
| revision | Yes | ||
| namespace | No | lab_export | |
| output_path | Yes |
TDQS
C2.9/5.0
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.
generate_example_houseC
Generate the furnished house fixture. Revision 2 removes the gold sentinel and changes bedroom carpet.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| revision | No | ||
| output_path | Yes |
TDQS
C2.3/5.0
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.
generate_structureB
Generate NBT from set/fill/room operations; no Python code execution required.
set: {op:'set',pos:[x,y,z],block:'minecraft:stone',properties:{}} fill: {op:'fill',start:[x,y,z],end:[x,y,z],block:'minecraft:stone'} room: {op:'room',start:[x,y,z],end:[x,y,z],wall:'oak_planks',floor:'stone',roof:'oak_planks'} A views list uses the submit_structure schema. Use the Python Structure library for typed block entities.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| size | Yes | ||
| views | No | ||
| operations | Yes | ||
| output_path | Yes |
TDQS
B3/5.0
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.
get_captureC
Return a real 1920x1080 Minecraft screenshot as MCP image content.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| view_id | Yes | ||
| angle_id | Yes | ||
| revision | Yes |
TDQS
C2.4/5.0
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.
inspect_blocksA
Read authoritative block states at relative positions, for placement and cleanup verification.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| positions | Yes |
TDQS
A3.7/5.0
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.
job_statusC
Read progress for this exact revision; rejects stale job IDs.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| revision | Yes |
TDQS
C2.9/5.0
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.
lab_statusA
Get world identity, limits, connection readiness, and active job progress.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.5/5.0
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.
list_blocksC
Find up to 200 block IDs and their valid properties from the live game.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | No |
TDQS
C2.6/5.0
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.
list_capturesA
List labeled screenshot metadata without returning all image bytes.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| revision | Yes |
TDQS
A3.5/5.0
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.
recapture_viewsA
Capture the placed build without replacing blocks. Returns a new revision and capture set.
Optional sidecar defines the replacement set of viewpoints; omitted reuses all current views. After success, old screenshots are deleted using the normal retention policy.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| revision | Yes | ||
| views_path | No |
TDQS
A3.8/5.0
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.
submit_structureA
Replace the active structure and automatically capture all angles. Returns a job immediately.
Optional views JSON is a list of {id,label,position:[x,y,z],spawn,angles:[{id,yaw,pitch}]}. Coordinates are relative to structure origin; position is feet height, eye_height defaults to 1.62. Embedded view pads are extracted automatically. Poll job_status until complete or failed.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| views_path | No |
TDQS
A4.4/5.0
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.
validate_structureA
Validate an existing compressed NBT structure against the game's registry and limits.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
TDQS
A3.7/5.0
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
13 tool updates
v0.2.0- First observed
cancel_job - First observed
export_structure - First observed
generate_example_house - First observed
generate_structure - First observed
get_capture - First observed
inspect_blocks - First observed
job_status - First observed
lab_status - First observed
list_blocks - First observed
list_captures - First observed
recapture_views - First observed
submit_structure - First observed
validate_structure
TDQS
B3.2/5.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.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Generate authentic pixel art - sprites, animations, and tilesets - from any MCP client
Generate game-ready 3D models, textures, and audio from natural language, over MCP.
MCP server for developer documentation, generated by doc2mcp.
MCP server for dev documentation, generated by doc2mcp.
Related MCP Servers
- FlicenseNot gradedqualityBmaintenanceAn MCP server that renders Minecraft structure files (NBT / Sponge schematic / Litematic) into PNG preview images using vanilla Minecraft resources.-
- AlicenseNot gradedqualityBmaintenanceEnables AI clients to validate and run Minecraft commands, read chat and tellraw messages, control player movement and GUI, and capture screenshots from within the game, aiding datapack debugging.1MIT
- AlicenseNot gradedqualityAmaintenanceA local-first MCP server for safely creating, inspecting, validating, testing, and packaging Minecraft Java Edition datapacks with guarded file access and deterministic builds.44MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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