Get purchase invoice PDF

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

注解已提供readOnlyHint=true、idempotentHint=true、destructiveHint=false，描述额外补充了返回base64字符串、可通过save_path写入文件，以及对应的REST端点。这些信息增加了注解之外的上下文，且与注解不矛盾。

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?

描述简短，包含一句核心功能说明和一行API端点信息。标题与第一句略有重复，但整体信息密度高，没有冗余填充，可快速把握要点。

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?

工具简单，参数完整且带描述，注解覆盖安全属性，描述说明了返回格式和可选的保存路径。虽然缺少输出schema，但base64和save_path已足够代理正确调用，没有明显信息缺口。

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覆盖100%，每个参数（id、save_path、administration）都有清晰描述。描述本身未额外解释参数，但schema已充分承担说明责任，符合基线3分标准。

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?

描述明确陈述了动词“Download”和资源“purchase invoice PDF”，并具体说明输出为base64-encoded string。与兄弟工具get_sales_invoice_pdf通过“purchase invoice”明确区分，无需打开schema即可理解用途。

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?

描述未显式说明何时使用或何时不使用，但隐含了使用场景：当需要下载购买发票的PDF时。没有提及替代工具或排除条件，相比清晰给出when/when-not的基准有所欠缺。

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