Generate cited Markdown or JSON research reports from a study, including limitations, and return them or save to a new file without overwriting.
汇编带引用和局限的 Markdown 或 JSON 报告。默认返回内容；指定 output 绝对路径时写入新文件，不覆盖现有文件。报告是研究记录，不是模型自动核验。
| Name | Required | Description | Default |
|---|---|---|---|
| format | Yes | markdown | |
| output | No | ||
| study_id | Yes | 研究 ID，由 research_create 返回 |
Changes observed during successful MCP inspections.
v0.4.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real context beyond annotations: default is content return, providing an absolute path writes a new file, existing files are never overwritten, and the report is a research record rather than model-verified output. This explains the write-but-not-destructive nature consistent with readOnlyHint=false, destructiveHint=false, and the non-overwrite claim meaningfully de-risks invocation.
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?
Three tight sentences, purpose front-loaded, then the output-behavior branch, then the disclaimer. 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?
For a 3-parameter tool with no output schema, the description covers the essential behaviors an agent needs: what is produced, where it goes, and the non-overwrite guarantee. The study_id link to research_create is only in the schema, but that is acceptable given its documented pattern and description.
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?
With only 33% schema coverage, the description compensates well: it names the two formats (markdown/json) and describes the output parameter's behavior (absolute path triggers file write, no overwrite). Only study_id is left to the schema, where its description already lives.
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?
States a specific verb and resource: compile a Markdown or JSON report with citations and limitations. An agent can identify the output artifact precisely, though it doesn't explicitly contrast itself with sibling tools like research_get or research_analyze.
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?
Gives one clear behavioral branch: default returns content, specifying an absolute output path writes to a new file. That is effectively a usage rule for the output parameter, but there is no explicit guidance on when to choose this tool over related siblings such as research_analyze or research_get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.