commander_doctrine

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys the purpose but doesn't state whether the operation is read-only, what kind of output to expect (though an output schema exists), or any side effects/requirements. The description adds no behavioral context beyond the basic analysis intent.

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 a single purposeful sentence followed by an organized list of commander–doctrine pairs. Every listed item earns its place, and the key purpose is front-loaded. There is no filler or redundant repetition.

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 a simple single-parameter tool with a default and an output schema, most needed context is present. The major gap is that the description's coverage list excludes sun_tzu and clausewitz even though the schema accepts them, creating ambiguity about valid inputs. This incomplete coverage undermines full completeness.

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 schema parameter description already lists all command names, and the tool description adds meaningful per-value context (e.g., 'Napoleon (corps system, central position)'), which helps an agent select the right commander. However, the description omits two valid values from the schema (sun_tzu and clausewitz), slightly limiting the added value.

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 uses a specific verb ('Analyze') and resource ('a commander's signature tactical innovation — the battle doctrine') and enumerates the covered commanders and their doctrines. This clearly distinguishes it from sibling tools like napoleon_maxims (maxims vs. doctrine) and sun_tzu (general principles vs. specific commander innovations).

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?

No explicit guidance is given on when to use this tool versus alternatives. The description implies it's for historical battle doctrines of specific commanders, but it doesn't state exclusions or mention sibling tools like sun_tzu or apply_strategy. There is no clear 'when to use / when not to use' guidance.

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