get_registryLists block, item, fluid, entity, and recipe-type registry entries from a running Minecraft game, with optional filtering to inspect available IDs.
列出 blocks / items / fluids / entities / recipe_types 注册表的内容。需要游戏在运行 —— 如果只是想找物品 id，优先用 search_items（它读本地缓存，离线也能用）。
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| limit | No | ||
| query | No | 可选的过滤词 |
Changes observed during successful MCP inspections.
v0.5.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it discloses the key operational trait: this call requires a live game session, unlike the offline cached search_items. It does not state what happens when the game is not running (error vs. empty result) or that results may be truncated by the limit, which keeps it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the first states what it lists, the second front-loads the runtime precondition and then the routing advice. There is no filler, and the most important constraint is not buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should say what 'registry contents' actually returns (ids only, or full entries with namespaces/tags), and it doesn't. Combined with the unexplained `limit` truncation behavior, an agent knows when to call it but not what to expect back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%; `query` is described but `kind` and `limit` are not. The description restates the `kind` enum values in prose, which is redundant with the self-documenting enum, and it says nothing about `limit` (default 100, cap 1000), so an agent gets no signal that results may be silently cut off.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (列出) and resource (注册表), and enumerates the five registry kinds that the `kind` enum accepts, so the scope is unambiguous. It also distinguishes itself from search_items, making it identifiable among its siblings without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the precondition (game must be running) and names the preferred alternative with the condition that selects it: if you only need an item id, use search_items because it reads a local cache and works offline. That is a complete when-to-use / when-not-to-use / alternative triple.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.