Lists a save's preset points with their IDs, names, positions, rotations, and player start point. Use this read-only tool to inspect spawn and teleport locations before editing or playtesting.
List the preset points (预设点) of a save: id, name, position, rotation, and which one players start at. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/destructiveHint=false, so 'Read-only' is largely redundant. However, the description does add genuine value by disclosing the exact fields returned — including which preset point players spawn at — which matters because there is no output schema. It stops short of noting ordering or pagination.
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?
A single front-loaded sentence that states the action, the resource, the returned fields, and the safety profile with no filler. Nothing repeats or pads.
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?
Return shape is covered and annotations handle safety, which is good for a simple one-parameter list tool. But the description never addresses the optional mapPath argument — whether omitting it lists the current map — which is the one behavioral question an agent will actually have.
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 description coverage is 0% for mapPath, so the description must compensate and it does not: it never explains what mapPath should contain (map name vs. file path) or what happens when it is omitted (it is not required). 'Of a save' actually adds confusion rather than clarifying the parameter.
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?
Names a specific verb and resource ('List the preset points') and even enumerates the returned fields (id, name, position, rotation, spawn point), which clearly separates it from scene_add_preset_point. The only wrinkle is 'of a save', which doesn't line up cleanly with the single mapPath parameter, leaving mild ambiguity about what scope is being listed.
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?
The description tells you it is read-only but never says when to call this versus siblings such as scene_list_respawn_points or scene_list_entities, nor what to do first. Usage is only inferable from the tool name; there are no stated conditions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.