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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds genuine behavioral detail beyond that: the three outcome categories (outdated, current, unknown) and the important scoping caveat that unnamed skills are not evaluated. It omits nothing critical but adds no auth or rate-limit context.

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?

Three short sentences, each load-bearing: purpose first, invocation/input second, output and scope third. No filler or redundancy, and the most decision-relevant information is front-loaded.

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 correctly compensates by naming the return categories (outdated, current, unknown) and the reporting scope. For a single-parameter, non-destructive read tool this is nearly sufficient; only the absence of guidance on versionless skills (covered in the schema, not the prose) keeps it from a 5.

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 100% for the single 'installed' parameter, including per-field docs for name and version. The description restates the same contract ('skills you currently have loaded with their skill-version stamps') without adding format, ordering, or size guidance beyond the schema, so the baseline of 3 applies.

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?

Specific verb + resource ('Check whether installed Muninn skills are up to date') with an added scope statement ('Only reports on skills you name'). An agent can immediately distinguish this read-only freshness check from muninn_skill_create, muninn_skill_update, and muninn_skill_delete without opening any 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?

Sets up the usage context clearly ('Send the skills you currently have loaded with their skill-version stamps') and bounds the scope to named skills, so the agent knows what input scenario triggers it. It stops short of naming an explicit alternative (e.g., muninn_skill_registry) or stating when-not to use it, so it does not reach the top band.

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