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

Annotations only cover the safe-read profile (readOnly, idempotent, non-destructive, closed-world). The description contributes behavior the annotations cannot: server sessions live under a separate companion service "<game>.server", so every other tool must be told that service, and findings default to production player sessions unless env or session_type is supplied. No return shape or cost hints, though.

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?

The resource framing is front-loaded, which is good, but the first sentence is an unpunctuated run-on that heaps eight metric groups into one clause chain, making it hard to scan. The companion-service paragraph earns its place; the metric enumeration 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 an aggregate, no-output-schema tool with 8 optional filters, the description covers what is reported and how server data is partitioned. It does not describe the shape of the returned sections or how the tick-budget breakdowns are grouped, but the annotations carry the safety profile and the schema carries filtering.

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 would be 3, but the description adds real meaning for the service parameter — that server sessions are addressed as "<game>.server" rather than the plain game service — which the schema's generic "Game service name" text does not convey. Other params (env, hours, props, version, steam_branch) are left entirely to 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?

The description pins down a specific resource with an explicit scope restriction — dedicated servers running the Glitchless SDK in server mode, naming the Node/Unity/Godot/Unreal entry points — then enumerates exactly what it reports (live servers and connected players, tick time vs budget, CPU/memory/networked objects, crashes, leak suspects, latest runs, findings). The companion-service note separates it cleanly from session-level siblings.

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 routes the agent to the right siblings for drill-down: glitchless_session for a single server run and glitchless_get_error for a crash stack, both with service "<game>.server". It also clarifies that server sessions count as sessions like any other, so other tools remain usable. What's missing is an explicit "use this instead of glitchless_overview/performance for server fleets" exclusion.

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