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

Annotations already declare readOnly=true and openWorld=true, but the description adds non-obvious traits: the log is global rather than proximity-limited, includes both human and AI messages, and is a snapshot/history rather than a live stream. It does not say whether results are paginated or truncated at the 200 cap, which keeps it short of 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?

Purpose is front-loaded, followed by enumerated use cases and a caution clause; every sentence carries information. It is slightly dense with parentheticals but nothing is wasted.

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?

With no output schema, the description must convey what comes back, and it does specify scope, content type (human + AI messages), and staleness. Lacking only return-shape details such as ordering or pagination, which is a minor gap for a single-parameter read tool.

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 100% – the lone 'limit' parameter already documents its default of 20 and server cap of 200. The description adds no further meaning about the parameter, so the baseline 3 applies.

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?

States a specific verb+resource ('拉取世界聊天日志里最近的若干条消息') and immediately scopes it ('不限于你附近，含真人和 AI Agent'). This distinguishes it from siblings like world_observe (nearby) and world_say (writing), so the agent can tell what it fetches 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?

Gives two explicit use cases: ① guest tier that cannot receive real-time push uses this to check for replies, ② restoring context after a reconnect. The closing caveat ('历史数据，不是实时推送') directly routes the agent away when it needs live data.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds real behavioral context beyond them: no API key is required, the call is a discovery/prerequisite step, and a false agentEnabled value is a hard gate that causes downstream failures.

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?

Front-loaded with what the call returns, then the usage recommendation, then the failure condition — a sensible order. It is a bit dense with parenthetical enumerations, but every clause carries information and nothing is redundant.

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?

With no output schema, the description takes responsibility for describing the return payload (name/ID, agentEnabled, capabilities, access method) and the failure mode. For a zero-required-parameter, read-only discovery tool this is complete enough to call correctly.

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?

There is a single optional parameter (refresh) whose 100% schema coverage already documents the 5-minute cache bypass. The description does not add meaning to it, so the baseline 3 applies.

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 exactly what the document contains: world name/ID, AI-access flag, capabilities (observation radius, rate limits, actions), and client access method. This clearly separates it from the sibling action tools (world_enter, world_observe, world_say, etc.), which it is explicitly a prerequisite for.

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 states usage context directly — '第一次使用建议先调这个' — and gives a concrete decision rule: if agentEnabled=false, AI access is disabled and later actions will fail. It does not explicitly name the sibling tools it gates, but for a first-step discovery call the sequencing condition is clear.

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

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

Annotations only declare readOnlyHint=false and openWorldHint=true; the description adds substantial context beyond that — credential issuance, WebSocket connection, visibility to real players, guest vs key tier capabilities (推流, 200m 观察半径, 自动续期), idempotency on existing connection, and automatic re-entry after server idle timeout.

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?

Single front-loaded sentence gives the core action, then tiers, then edge cases (idempotency, timeout recovery). Dense but every clause earns its place; minor formatting emphasis adds little.

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?

With no output schema and no annotations covering behavior, the description carries the burden well by describing connection semantics, tiers, and recovery. It stops short of describing failure modes or what the session credential response looks like.

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?

The tool takes zero parameters, which is the baseline-4 case. The description correctly implies the invocation is parameterless, gated instead by environment configuration (AGENT_API_KEY).

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?

States a specific verb+resource (进入虚拟世界) and enumerates the concrete effects: 领取会话凭证 and 建立 WebSocket 连接. The scope is unambiguous and clearly distinct from siblings like world_leave or world_observe.

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?

Explains the two entry modes and their conditions (no API Key → 公开游客票 30 分钟拉模式; AGENT_API_KEY → Key 档), plus idempotency and auto-reentry. It gives clear context for when the tool applies, though it never explicitly names a sibling as the alternative.

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

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

Annotations only say readOnlyHint=false and openWorldHint=true. The description adds substantial behavior the annotations cannot convey: polling cadence, stop condition, that it returns immediately as a long-running background task, how to terminate it, and a concrete rate limit. This is rich disclosure well beyond the annotation surface.

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?

Dense but every clause carries necessary information: the mandatory-id warning, the id source, the async nature, termination paths, and the rate limit. The most critical constraint (must pass an id) sits mid-paragraph rather than being front-loaded, which costs it the top mark.

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?

With no output schema, the description still covers the return contract ('returns immediately, then use world_observe to watch position') plus lifecycle and rate limits. An agent has everything needed to invoke and manage this long-running task correctly.

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 100%, so the baseline is 3, but the description adds real meaning: it warns that a world-object id will not work, that names are ambiguous in-world so an id is mandatory, and where to source the id. stopDistance and maxDurationMs are only defined in the schema, not elaborated here, keeping it from a 5.

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 states a specific verb and resource — 'make the avatar continuously follow an entity' — and immediately clarifies the mechanism (server re-polls every 0.1s, stops inside stopDistance). This is clearly distinguishable from world_walk_to (one-shot movement) and world_observe (read-only inspection).

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?

Explicit when-to-use and when-to-stop: it names world_walk_to as the action that interrupts following and world_leave as another termination path, tells the agent where to obtain the id (world_observe's nearby-people list), and states the rate limit (guest: 1 per 2s). No alternatives are left to inference.

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

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

Annotations only say readOnlyHint=false and openWorldHint=true. The description adds substantial context beyond that: the avatar is removed from other players' view, and any later tool call (e.g. world_observe) automatically re-registers presence and restores position from the last persisted location. That re-entry/position-restore contract is exactly the kind of side-effect disclosure annotations cannot provide.

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?

Front-loaded with the action and its visible effect, then the re-entry caveat, then the recommendation. Every sentence carries information, though the closing 'don't leave your avatar hanging' remark is chatty relative to the rest.

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?

With no parameters, no output schema, and only two loose annotations, the description carries the full burden and does so: it explains the immediate effect, the visibility to other players, the automatic re-entry behavior, position restoration, and when to invoke it. An agent has everything needed to call it correctly.

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?

The tool takes zero parameters, so the baseline is 4. The description correctly adds no parameter detail because none is needed, only consequence and lifecycle semantics.

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?

States a specific verb and resource: it closes the WebSocket connection to the world, and spells out the visible consequence (your avatar disappears and other players see you leave). This is clearly the inverse of world_enter, so an agent can tell it apart from siblings without opening schemas.

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?

Gives explicit when-to-use guidance (call once after finishing a round of visiting, don't leave your avatar idling in the world) and explains what happens if you instead call another tool. It does not explicitly name world_enter as the manual re-entry alternative, but the auto-re-entry condition is covered well enough that usage is unambiguous.

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

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

Adds substantial behavior beyond the readOnlyHint/openWorldHint annotations: rate limiting, per-tier radius ceilings, a ~2KB default byte budget, the graceful-degradation rule (distant objects downgrade to name-only while nearby descriptions stay complete), and a caveat that the server estimates y as a ground plane so height differences are unreliable.

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?

Front-loaded with the tool's identity and purpose before the constraints, and nearly every sentence carries actionable information for a vision-less agent. It is dense and long, and a few clauses (the distance3D aside) could be trimmed, but nothing is filler.

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?

With no output schema, the description carries the full burden of explaining returned content and it does: field semantics, byte budget, degradation behavior, and what the events section contains. An agent has everything needed to call and interpret this tool.

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 100%, so baseline is 3, but the description goes further: it explains the radius/maxBytes tradeoff and the remediation strategy (shrink radius and observe repeatedly, or raise maxBytes), and clarifies that distance is horizontal while distance3D is only an upper bound. That adds genuine meaning beyond the parameter docs.

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?

States a concrete verb and resource: returns textual descriptions of nearby players, world objects, and portals, framed as 'the AI's eyes' since no 3D rendering is available. The description of what fields come back (object description text, events since last observation) makes the tool's output uniquely identifiable even without naming a sibling.

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?

Gives concrete usage guidance: start with radius 30m, expand or observe in multiple passes when you need distance, and adjust maxBytes to see more. Rate limit (1 per 2s) and tier-based radius caps are stated. However, it never contrasts with siblings like world_discover or world_chat_history, so the agent gets no explicit routing rule.

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

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

Goes well beyond the annotations: discloses rate limits (guest 1 msg/5s, Key tier more lenient), a 200-char cap, etiquette expectations, that the receipt reports the actual recipients count (0 meaning nobody heard), and that guest tier cannot receive reply pushes. This is rich behavioral context an agent cannot get from readOnlyHint/openWorldHint.

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?

Front-loaded with the purpose and bubble radius, then rate limits, etiquette, and receipt semantics. It is somewhat dense/long, but essentially every sentence (rate limit, recipients=0 warning, sibling routing, guest limitation) carries actionable information.

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?

With no output schema, the description correctly explains the return signal (recipients count within 30m) and covers rate limits, audience, and alternatives. An agent has everything needed to decide whether and how to call it and how to interpret the result.

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 100% and the single 'text' parameter is fully documented by the schema, so the baseline is 3. The description's restatement of the 200-char limit and the '≤200 字' note duplicate rather than extend the schema.

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?

States a specific verb (说/say) and resource (a line via current avatar) with precise scope: a chat bubble visible to real players and AI agents within 30m. It distinguishes itself from siblings by naming world_observe (to check who's nearby) and world_chat_history (to read replies).

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?

Gives explicit when-to-use guidance ('先用 world_observe 看看附近有谁，再决定说不说') and routes to the alternative (world_chat_history) for the case where you want to know if someone replied. Nothing about selection is left to inference.

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

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

Annotations only say readOnlyHint=false and openWorldHint=true; the description goes well beyond by disclosing server-side speed limiting (9~12 m/s), the returned reason values (arrived, superseded), guest rate limiting (1 per 2s), and that new moves preempt prior move/follow commands. Strong, though it doesn't say what happens on timeout or failure reasons beyond 'arrived'.

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?

Purpose and the exclusivity constraint are front-loaded, and every sentence carries operational information (speed, reasons, rate limit, preemption). It is dense rather than bloated, though the rate-limit and interruption clauses could be tightened.

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?

For a 3-parameter mutation tool with no output schema, the description covers the prerequisite, the mutation semantics, the terminal return reasons, and the throttling/preemption behavior an agent needs to call it correctly.

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 100%, so the baseline is 3. The description adds real value by explaining where x/z values come from (a position obtained via world_observe) and that timeout is auto-estimated from distance, which ties the coordinates to a concrete workflow.

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?

States a concrete verb+resource+scope: '让形象走到世界坐标 (x, z)'. It also declares exclusivity ('这是唯一的位移方式'), which immediately separates it from world_follow and any teleport-style sibling.

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?

Gives an explicit prerequisite workflow: call world_observe to get a target's position, then pass x/z. It also states when-not (no teleport, coordinates cannot be set directly) and names the interruption condition against follow/move commands, plus per-role rate limits.

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