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

With no annotations, the description carries the full transparency burden and does a good job. It discloses a filtering behavior (does not return unverified/suspended strategies), mentions output content (calibrated uncertainty, applicability conditions, negative transfer warnings), and specifies the structured error format. This is meaningful behavioral context beyond the schema.

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 description is well-structured with a clear opening statement, a behavioral caveat, and organized Args/Returns sections. Every part contributes. The only minor weakness is the opaque '§24, §18' reference, which adds little clarification for an AI agent.

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?

Given the tool's moderate complexity, the description covers the main purpose, exclusion behavior, parameter meanings, return content, and error format. Because an output schema exists, return-value details need not be fully repeated. The main gap is the lack of guidance for choosing this tool over closely related sibling tools.

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?

Since schema description coverage is 0%, the description must compensate for all five parameters. It provides useful context for task_structure_id (UUID), model_family (examples), and goal (metric targets), but the definitions for environment ('Environment characteristics') and available_capabilities are thin and add only marginal meaning beyond the parameter names.

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 states a specific action and resource: 'Retrieve applicable validated strategies for a task.' It also clarifies what the tool intentionally excludes (unverified/suspended strategies). However, it does not explicitly differentiate itself from the sibling cognitive_get_strategy / cognitive.get_strategy, so it stops short of full sibling differentiation.

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?

The description gives context for when to use the tool — when validated, applicable strategies are needed for a task — and notes what it will not return. But it never names alternative tools or states conditions for preferring a sibling like get_strategy or propose_strategy. Usage timing is implied rather than explicit.

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