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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It explains that the tool 'translates ancient military wisdom' but does not reveal what the output looks like, whether it synthesizes multiple commanders (as hinted by the 'commanders' parameter), or any limitations. For a tool that likely performs analysis and returns a response, the lack of transparency about its operational behavior is a 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?

The description is two sentences long, front-loaded with the main purpose, and every word contributes meaning. It avoids redundancy and fluff. The structure is efficient, directly stating both what the tool does and what the user should specify.

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 (3 parameters, output schema present) and the schema's completeness, the description covers the essential context: it defines the tool's purpose, target domains, and key input directives. It does not explain return values, but the output schema likely covers that. It could be slightly more complete by mentioning the 'commanders' parameter or alternative tools, but it is largely adequate for correct invocation.

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 provides 100% description coverage for the three parameters, so the baseline is 3. The description adds minimal extra meaning by referencing the 'problem domain' and 'analytical lens', which loosely correspond to 'problem' and 'lens'. However, it does not enrich the understanding beyond the schema, such as clarifying the 'commanders' parameter's role. The added value over the schema is marginal.

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 clearly states the tool's function: applying classical military principles to modern strategic problems. It specifies the verb ('apply'), the resource ('classical military principles'), and the scope ('business, technology, organizational, or geopolitical analysis'), distinguishing it from sibling tools that likely focus on specific sources. The purpose is unambiguous and action-oriented.

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 indicates when to use the tool ('modern strategic problem') and what to specify ('problem domain' and 'analytical lens'), but it does not explicitly contrast with sibling tools like sun_tzu or napoleon_maxims. The guidance is implied rather than explicit, leaving the user to infer alternatives. There is no direct 'use this instead of X' statement.

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

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.

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

No annotations are provided, so the description carries the behavioral burden. 'Get' implies a read-only operation, and the description adds context about the maxims' composition, but it does not explicitly disclose side effects, auth requirements, or return behavior. For a simple read tool, this is acceptable but not detailed.

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 three sentences with no filler. It front-loads the purpose, quantifies the content, and then gives use cases. Every sentence earns its place.

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 an output schema present and a simple read-only tool, the description provides adequate context: what the tool returns and when to use it. It does not explicitly mention filtering options, but the schema covers those details, so the description is sufficiently complete.

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 already describes both parameters fully (100% coverage). The description adds thematic context (strategic planning, logistics) that loosely relates to category values, but it does not add significant meaning beyond the schema, so the baseline 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?

The description clearly states the tool retrieves Napoleon Bonaparte's Military Maxims, specifying the resource and content type. It does not explicitly differentiate from sibling tools like sun_tzu, so it falls short of a 5.

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?

Provides explicit use cases ('strategic planning, logistics, speed of decision, and concentration of force'), giving clear context for when to use the tool. No exclusions or alternatives are mentioned, but the guidance is direct and helpful.

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

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

With no annotations, the description carries the full burden of disclosing behavior. It indicates a read-only operation via 'Get' and discloses the returned fields (title, author, date, themes, key insights). However, it doesn't mention pagination, result limits, or the effect of the domain parameter, leaving some behavioral details undisclosed.

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, front-loaded sentence that delivers the core purpose and return fields without fluff. Every clause adds value, and it is short enough to be processed quickly.

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?

The tool has a simple input schema and an output schema, so the description doesn't need to explain return values in detail. It is sufficient for a basic library lookup, though it could benefit from mentioning that the domain parameter expands beyond military philosophy. Overall, the description is complete enough for correct invocation.

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 covers the domain parameter 100%, describing allowed values and default. The description adds no extra meaning about how domain filtering works or how it relates to the 'military and strategic philosophy' scope. Baseline of 3 applies because the schema fully documents the parameter.

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 clearly states the tool gets major works of military and strategic philosophy in the public domain, listing the return fields. This distinguishes it from siblings like sun_tzu or napoleon_maxims, which are specific works rather than a general library. The verb 'Get' and the resource 'public domain works' provide a specific, unambiguous purpose.

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 no guidance on when to use this tool versus siblings such as sun_tzu or commander_doctrine. It doesn't mention that specific works have dedicated tools or that this library is for broader exploration. No exclusions or alternative contexts are provided, leaving the choice to the agent's inference.

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

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

With no annotations present, the description carries the full burden of behavioral disclosure. It states the action ('Get') and the content ('13 chapters'), but does not explicitly describe the return format or any variations in behavior (e.g., chapter selection or concept search). For a read-only retrieval tool the risk is low, yet the description leaves some ambiguity about what exactly is returned, so a 3 is appropriate.

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 two sentences with no filler. The first sentence front-loads the core function and resource; the second adds valuable context. Every sentence earns its place.

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 presence of a full output schema and two well-documented optional parameters, the description covers the essential context: what the text is, its relevance, and its domains of application. Minor gaps exist, such as not explicitly stating default behavior for 'chapter=0', but the schema covers that. The description is complete enough for selection and invocation.

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%: both 'chapter' and 'concept' are fully documented in the schema. The description mentions '13 chapters' which aligns with the chapter parameter but adds no new semantic detail beyond the schema. Baseline 3 applies, as the schema does the heavy lifting.

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 clearly identifies the specific resource and action: 'Get Sun Tzu's Art of War' with the distinct scope of 13 chapters. It differentiates from sibling tools by naming this unique text and by adding contextual positioning, making its purpose unmistakable.

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 provides clear usage context by listing application domains ('competitive analysis, negotiation, organizational strategy'), but it does not explicitly state when not to use the tool or mention alternatives. This is sufficient context without exclusions, so it earns a 4.

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