generate_analysis_report_mdGenerate a structured Markdown report from IDA analysis to quickly understand a binary's core logic via full-function scanning.
一键生成结构化 markdown 报告，帮助快速理解程序核心逻辑（全量函数扫描）。
| Name | Required | Description | Default |
|---|---|---|---|
| instance_id | No | Optional database instance id. If omitted, use the current target. |
Changes observed during successful MCP inspections.
v20261008.0.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful scope context by noting a full function scan, which signals that the operation may be expensive. It does not say whether the report is returned or written to disk, and it gives no cost, time, or output-location details.
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?
A single compact sentence front-loads the action (“一键生成结构化 markdown 报告”) and then states the purpose. There is no redundant or filler text.
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 an annotation covering safety and a fully documented optional parameter. However, with no output schema, the description should clarify whether the markdown report is returned, saved, or shown elsewhere, and should distinguish this tool from the closely related get_analysis_report sibling.
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%, and the sole optional instance_id parameter is fully documented in the schema. The description adds no parameter-level guidance beyond the schema. Baseline 3 is appropriate when the schema already does the work.
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 supplies a specific verb and object, “一键生成结构化 markdown 报告,” which clearly states what the tool produces. It adds “帮助快速理解程序核心逻辑（全量函数扫描）” to set scope. However, it never distinguishes this tool from the sibling get_analysis_report, so the agent cannot tell which one to call.
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 parenthetical “（全量函数扫描）” implies the tool is for a broad analysis pass, and “帮助快速理解程序核心逻辑” suggests a context where the tool is useful. There is no explicit guidance on when to use this tool versus get_analysis_report or analyze_batch, and no exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.