Skip to main content
Glama

Remove entities

remove_entity
Destructive

Removes Minecraft entities without drops by UUID or type, optionally within a radius; use dry-run mode to count targets before deleting.

Instructions

Remove entities without drops: one by uuid, or many by types, such as dropped items, arrows, or a mob farm's overflow, optionally within a radius of x, y, z. Many at once never touches players, skips named mobs and tamed pets unless includeNamed is true, takes the nearest first up to max, and dryRun only counts. Try dryRun first and tell the user what would go.

Input Schema

NameRequiredDescriptionDefault
xNo
yNo
zNo
maxNoRemove at most this many; the server caps it (1000 by default)
uuidNoOne entity
typesNoEntity keys, such as ["minecraft:item", "minecraft:arrow"]
worldNoWorld name, such as `world`, `world_nether`, `world_the_end`, or a key like `minecraft:the_nether`world
dryRunNoOnly count what would be removed
radiusNoBlocks around x, y, z
includeNamedNoAlso remove named mobs and tamed pets

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.1.0

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial behavior beyond the destructiveHint annotation: no item drops, players are never affected in bulk mode, named mobs and tamed pets are skipped unless includeNamed is set, the nearest entities go first up to max, and dryRun only counts. That is well above the annotation bar. However, with zero required parameters it never states what a bare call (no uuid, no types, no radius) removes, which is the most consequential unknown for a destructive tool.

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?

Front-loaded with the two modes and then the safety rules, with a short actionable closer about dryRun. Every clause carries information about behavior or selection. It is dense and somewhat run-on, packing five safety clauses into one sentence, which costs some parseability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, ten parameters, and a destructive operation; the description covers most behaviors but omits the scope of a no-argument call and never mentions the `world` parameter that governs which dimension is affected. For a tool where every parameter is optional and destructiveHint is true, the unfiltered-call behavior should be stated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 70% and the description reinforces the key semantics: uuid versus types (with example keys), radius relative to x/y/z, and the ordering rule for max ("nearest first up to max"), which the schema's max description does not convey. The `world` parameter is never mentioned in the description, leaving that one to the schema alone.

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?

States a specific verb (remove) and resource (entities) and crisply separates the two operating modes: single-by-uuid versus bulk-by-types, the latter optionally scoped by a radius around x/y/z. It even supplies concrete use cases (dropped items, arrows, mob farm overflow). It does not contrast itself with siblings like list_entities or spawn_entity, so it is clear but lacks explicit sibling differentiation.

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?

"Try dryRun first and tell the user what would go" is explicit procedural guidance for a destructive call, and the stated use cases (dropped items, arrows, overflow) tell the agent when this tool is the right one. It stops short of naming alternatives or stating when not to use the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.