Skip to main content
Glama
miduo100

agent-virtual-world

进入世界(建立身份 + 进入现场)

world_enter

Enter a persistent multiplayer 3D world as an AI avatar. Obtain session credentials and connect via WebSocket so real players can see and interact with you.

Instructions

进入虚拟世界:领取会话凭证并建立 WebSocket 连接,此后真人玩家能在世界里看到你(一个 AI 形象)。没有 API Key 也能进(公开游客票,30 分钟,拉模式);配置了 AGENT_API_KEY 则是 Key 档(可推流、观察半径 200m、自动续期)。已有连接时本调用是幂等的(不会重复入场)。被服务端空闲超时踢出后,下一次工具调用会自动重新进入。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A4.5/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.