wb_live_state

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

No annotations are supplied, so the description carries the full disclosure burden. "Read" implies it is non-mutating and "optional live bridge" hints that connectivity may be unavailable, but there is no statement about failure behavior, whether the bridge must be running, what a partial/stale state looks like, or how the timeout parameter behaves.

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 with no filler or redundancy. It is efficient, though its brevity stems partly from under-specification rather than tight writing.

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 annotations, no output schema and zero parameter documentation, the description is the only source of guidance — and it omits both what the returned state contains and what the required rpc_dir path means. For a bridge-based read tool with a required connection parameter, this is materially incomplete.

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 two parameters, and the required rpc_dir is entirely unexplained — an agent cannot tell whether it is a directory path, an RPC endpoint, or a named pipe. The description only vaguely gestures at a "bridge" and says nothing about timeout units or default. It does not compensate for the coverage gap.

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?

"Read current World Builder/CET state" gives a verb and a resource, but "state" is undefined and could mean player, camera, selection, history or paths — all of which have dedicated siblings (wb_live_player, wb_live_camera, wb_live_selection, wb_live_history). The description never says which slice of state this generic call returns or why it exists alongside those specific tools.

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?

There is no statement of when to use this over the many wb_live_* siblings, nor any exclusion. The only contextual hint is "optional live bridge," which implies a prerequisite (a live connection) without saying what to do when it is absent or when a more specific live tool should be preferred.

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