get_report

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool reads task progress, that the default response excludes content and sources, and that including them can result in a large return payload. This is adequate for a simple read operation, though it omits details like error conditions or authentication requirements.

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 concise sentence with the main verb and resource front-loaded, followed by relevant parameter guidance. Every word earns its place, and there is no redundant or filler content.

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?

For a low-complexity read tool with only three simple parameters and an output schema, the description provides enough context to call the tool correctly. The only minor gap is a slight ambiguity around what 任务进度 means exactly, but the reference to 正文 and 来源 helps clarify the tool's scope.

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 0%, so the description must compensate. It does so by mapping 正文 and 来源 to include_content and include_sources, and by indicating the default behavior through the phrase 避免默认返回过大. The report_id parameter is not described, but it is required and self-evident from the parameter name.

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, 读取 (read), and resource, 任务进度 (task progress), which clearly identifies this as a retrieval tool. It distinguishes itself from siblings like create_report_plan, update_report_outline, and generate_report by being the only read-oriented operation.

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 clearly implies this tool should be used to read task progress and optionally include content/sources. It does not explicitly name alternatives or exclusion conditions, but the sibling tools are all mutating or generation-oriented, making the proper usage context obvious.

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