get_report_template

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

No annotations are provided, so the description carries the full burden. It clearly indicates this is a read operation (retrieving template content) and describes the return value structure (success, template_name, category, content, or error). No hidden behaviors are mentioned, but the description is adequate for a simple retrieval.

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 front-loaded with the main purpose and uses a structured docstring format. It is fairly concise, though it repeats argument descriptions that are already in the input schema. The line breaks and separate sections (Args, Returns) make it easy to parse.

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?

Despite the contradiction regarding caller_agent_id, the description covers all essential aspects: purpose, parameters (with format guidance for template_name), usage instructions, and return value structure. Since an output schema exists, the Returns section provides additional clarity. The description is complete for this simple retrieval tool.

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 coverage is 0%, so the description must compensate. It adds value for 'template_name' by specifying format (no extension) and examples. However, it incorrectly states that 'caller_agent_id' is required, while the schema shows it is optional with a default of null. This inconsistency reduces clarity.

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 purpose: 'レポートテンプレートの内容を取得する' (get content of a report template) and explains it returns the full template text. This distinguishes it from sibling tools like 'list_report_templates' which only list templates, not retrieve content.

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 instructions on how to use the template (copy and replace placeholders) and lists the arguments. However, it does not explicitly state when to use this tool versus alternatives like 'list_report_templates', though the context implies it.

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