check_include_guard

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. While it states what the tool does (checks include guards) and mentions the return format ('检查结果，包含是否符合规范、详细说明和建议' - check results including compliance, detailed explanation, and suggestions), it doesn't describe important behavioral aspects like error handling, performance characteristics, or what constitutes 'correct' include guards. For a code analysis tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.

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 extremely concise and well-structured. It opens with the core purpose, then clearly lists parameters and return values in separate sections. Every sentence earns its place by providing essential information without redundancy. The bilingual presentation (Chinese purpose with parameter/return labels) is efficient and clear.

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 (2 parameters, 1 required), the presence of an output schema (which handles return value documentation), and the clear parameter explanations in the description, this is reasonably complete. The main gap is the lack of behavioral context about how the analysis works, but the output schema reduces the need to describe return values in the description itself. For a code analysis tool, this provides adequate context for basic usage.

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 description provides meaningful parameter information beyond the schema. While schema description coverage is 0%, the description explains that 'code' is '头文件的完整代码' (complete header file code) and 'file_path' is '可选的文件路径，用于生成建议的保护宏名' (optional file path used to generate suggested guard macro names). This adds crucial semantic context about what each parameter represents and how they're used, compensating well for the lack of schema descriptions.

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 purpose: '检查 C++ 头文件的包含保护是否正确' (Check if C++ header file include guards are correct). It specifies the verb ('检查' - check), resource ('C++ 头文件' - C++ header files), and scope ('包含保护' - include guards). This distinguishes it from sibling tools like 'check_const_correctness' or 'suggest_modern_cpp' which focus on different aspects of C++ code analysis.

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 implies usage context (when working with C++ header files that should have include guards), but doesn't explicitly state when to use this tool versus alternatives. It doesn't mention prerequisites, limitations, or comparisons with sibling tools. The context is clear but lacks explicit guidance on when this specific check is appropriate versus other code analysis tools.

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