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

readOnlyHint=true is consistent with a pure introspection call, and the description adds information annotations cannot convey: the response enumerates tools, prompts, and resources, and explicitly states what the server does and does not expose. It omits practical traits such as response size or whether the payload is large enough to matter for context budgeting, which is the main remaining gap.

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?

Two sentences, front-loaded with the highest-value content ('What K2 is, which apps it runs') before the capability-map detail. There is minor overlap between 'every machine-readable surface' and 'the full capability map — every tool, prompt, and resource', but the second phrasing sharpens rather than repeats.

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 input schema, no output schema, and a single readOnlyHint, the description carries most of the burden and does so adequately: it enumerates the categories of information returned. It stops short of describing the shape of the capability map or noting that the response can be large, which would help an agent decide when to call it during a session.

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 there is no parameter semantics to explain and the description is not required to compensate. The baseline for a no-param tool applies and nothing in the description muddies it.

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 resource — K2 itself, the apps it runs, the server's exposure surface, and the full capability map — which is far beyond a restatement of 'get_site_info'. It is phrased as noun fragments rather than an explicit verb+object (e.g., 'returns server metadata'), so the action is inferred rather than stated, and it never explicitly distinguishes itself as the self-discovery entry point versus the domain siblings like list_decks.

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 gives a concrete triggering condition: use it when a client has a 'stale or tools-only roster' and needs to see the whole surface. That is a real use-case context an agent can act on. It stops short of exclusions or naming alternatives (e.g., 'for algorithm details use explain_k2_algorithm instead'), so it is clear context without routing guidance.

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