Nova

Read discharge or visit papers

read_care_document

Read-onlyIdempotent

Extracts medication lists from photos of after-visit summaries or discharge papers and reconciles them with the current care plan as start, stop, change, or continue actions for approval.

Instructions

A photo of an after-visit summary or discharge papers. Nova extracts the medication list (Amazon Nova multimodal) and reconciles it with the current plan as change / start / stop / continue. Nothing changes until someone approves it with apply_care_changes.

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": {
      "image_base64": "<image_base64>"
    },
    "name": "read_care_document"
  }
}

Input Schema

Name	Required	Description	Default
`mime_type`	No	Image MIME type	image/png
`image_base64`	Yes	The photo as base64 or a data URL

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 24, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is lower; the description still adds real behavioral context by saying the output is a proposed reconciliation (change/start/stop/continue) and that no state mutates until apply_care_changes is called. It doesn't mention latency, image quality constraints, or failure modes on unreadable photos, which would be the remaining useful disclosures.

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

Conciseness4/5

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

Three short sentences, front-loaded with the input type, then the processing, then the safety gate. Little waste; the parenthetical "(Amazon Nova multimodal)" is implementation trivia that doesn't help an agent decide or invoke, but it costs only a few words.

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

Completeness4/5

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

With an output schema present, the description needn't document return values, and it instead covers the piece the schema can't: the two-step flow where this tool only proposes changes and apply_care_changes commits them. That is the key thing an agent needs to sequence calls correctly.

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% with only two simple parameters, so the schema already explains image_base64 and mime_type fully. The description adds only the notion that the input is "a photo" — no size limits, data-URL format, or MIME expectations beyond the schema. Baseline 3 is 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 names the resource precisely (after-visit summary / discharge papers) and states the concrete operation: extracting the medication list and reconciling it against the current plan as change/start/stop/continue. It is clearly distinct from siblings like apply_care_changes and check_pill_photo. It lacks an explicit leading verb ("Reads/Extracts..."), which keeps it just 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 Guidelines4/5

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

Usage is strongly implied: call this when a user supplies a photo of discharge or visit papers. The description also draws the boundary with apply_care_changes by stating nothing changes until someone approves it there. It stops short of an explicit "use this when / not when" sentence, so a 4 rather than 5.

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