med-lit-mcp

Overview Schema Source Related Servers Discussions Admin

record_report

DestructiveIdempotent

Save an evidence-linked literature review report by validating citations and quotes against stored articles and attaching the run’s methods and study list.

Instructions

Save the report answering the question: citations and quotes are checked against the stored articles, and the methods and study list are added from the run's record. Reply with its message. Rules: guide("report").

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "run_id": "<run_id>",
      "answer": "<answer>",
      "findings": "<findings>"
    },
    "name": "record_report"
  }
}

Input Schema

Name	Required	Description
`body`	No	Markdown '## ' sections: evidence by theme, agreement and disagreement, gaps; cite [uid]
`answer`	Yes	The direct answer to the question, citing studies as [uid]
`run_id`	Yes	Run ID from start_search
`findings`	Yes	Key findings, each with a verbatim quote
`limitations`	No	Plain strings: limits the evidence shows, not those in next_report's limitations_added

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.3.0Oct 29, 2026

TDQS

B3.1/5.0

Behavior3/5

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

The description adds meaningful behavior beyond the annotations by stating that citations and quotes are checked against stored articles and that methods and study list are appended from the run record. However, it does not explain failure behavior if validation fails, what the destructive annotation means in practice, or how the finalization behaves.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loads the main action, but the final phrase 'Rules: guide("report").' is cryptic and the sentence 'Reply with its message' is ambiguous. It avoids bloat but sacrifices clarity in places.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich input schema, output schema, and annotations, the description covers the central validation and enrichment behavior. It is still incomplete for an agent because it does not clarify workflow sequencing relative to next_report or what to do if the guide/report rules conflict with validation failures, but it is adequate as a minimum viable definition.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all five parameters thoroughly, including nested findings fields. The description mentions citations, quotes, and the run record but does not add syntax or constraints beyond what the schema provides, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource ('Save the report answering the question') and explains the core action: citations and quotes are checked and methods/study list are added from the run record. It does not explicitly distinguish this final report-recording step from a sibling such as next_report, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only usage guidance is the cryptic 'Rules: guide("report").' There is no explicit statement of when to use this tool versus siblings like next_report, record_synthesis, or record_evaluation, and no prerequisites or exclusions are given.

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