get_skill

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

With no annotations the description must carry behavioral load, and it does disclose substantive content: the skill catalog, including that 'operating-limits' covers rate limits, the breaker, and what the tool refuses to do, and that 'privacy' carries a versioned notice. It omits call-side traits such as return format (prose vs structured) and any caching/cost behavior, leaving a modest 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?

Purpose and the routing rule are front-loaded in the first and last sentences. The middle is a dense run-on of semicolon/em-dash fragments that is information-rich but harder to parse than a bulleted list would be; nothing is purely wasteful.

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?

A one-parameter enumeration tool with no output schema does not need return-value documentation, and all five skill names are accounted for. What remains thin is the mapping from user scenario to the three skills besides apartment-search, so an agent still has to guess which of the others to fetch.

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%, so the description must compensate, and it does by explaining the meaning of every enum value rather than merely listing them — e.g. criteria-coverage is 'the gap map by buyer persona', freshness-and-history covers 'using price_history and diff_report'. It reinforces the invocation form ('Call with the skill name') but adds no format detail beyond the enum itself.

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 and resource ('Fetch usage guidance for this server') and immediately distinguishes itself from the search/tracking siblings by enumerating the five concrete skills it serves. An agent can tell this is the meta-documentation tool and not a data tool 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?

Gives a clear trigger ('before composing non-trivial queries') and an explicit rule for one skill ('call apartment-search before any multi-criteria search'). It stops short of stating when not to call it (e.g., trivial/single-tool queries) or which skill to pick for the other four scenarios, so it is strong context without full exclusion logic.

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