server_info

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description still adds real behavioral value: the meaning of the versionMismatch flag, and the non-obvious quirk that EasyEDA ignores same-version .eext reinstalls, which an agent could never infer from structured fields.

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-loads the returned fields, then appends the versionMismatch semantics and fix in a single tight second sentence. Dense but every clause carries information; nothing is redundant with the name or annotations.

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 must carry the return contract — and it does, naming each reported field plus the derived versionMismatch flag. For a no-input status tool this is fully sufficient.

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 nothing about inputs and instead spends its words on outputs, which is the right allocation.

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 ('Get MCP server status') and then enumerates exactly what the status payload contains: daemon version, WebSocket port, connection state, connected instances with .eext and editor versions, and allowed origins. An agent can tell this apart from data-manipulation 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?

Implied diagnostic usage and a clear remediation path when versionMismatch is true (reinstall .eext with a bumped version, or bridge_restart). However it never says when to reach for server_info versus the overlapping sibling list_instances, so routing is left partly to inference.

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