Nova

Ask the care notes

ask_care_notes

Read-onlyIdempotent

Answers health questions using what doctors and care team wrote—visit summaries, discharge instructions, and dietitian notes—so you can check details like salt limits or ibuprofen safety.

Instructions

Answer questions from what the doctors and care team actually wrote (visit summaries, discharge instructions, dietitian notes, emergency info). 'What did the doctor say about salt?', 'Can I take ibuprofen?'

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": {
      "question": "<question>"
    },
    "name": "ask_care_notes"
  }
}

Input Schema

Name	Required	Description	Default
`question`	Yes	The question, in the user's words

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 24, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds one genuinely useful behavioral claim - answers are grounded in what clinicians actually wrote rather than general knowledge - but says nothing about what happens when no relevant note exists, whether sources are cited, or that answers aren't medical advice.

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?

Lead sentence front-loads the grounding claim and source scope; the example questions are short and illustrative rather than filler. The parenthetical list of note types is a touch enumerative but earns its place by defining scope.

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?

An output schema exists, so return-value detail is unnecessary, and the single required parameter is fully documented. What is left unsaid is whose notes are being queried in a multi-person care context and whether answers cite the underlying document - relevant given siblings like set_sharing and care_briefing.

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

Parameters4/5

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

With one parameter at 100% schema coverage the baseline is 3, and the description goes beyond it by showing the intended question shape (natural-language, patient-phrased) and the kind of topics in scope. It slightly over-constrains by leaning toward medication/diet questions, but that is a minor cost.

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?

States a specific verb and resource: answers questions sourced from what the care team actually wrote, and enumerates the source types (visit summaries, discharge instructions, dietitian notes, emergency info). That makes it distinguishable from raw-document siblings such as read_care_document, though the description never names that distinction explicitly.

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

Usage Guidelines3/5

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

The example questions ('What did the doctor say about salt?', 'Can I take ibuprofen?') imply when this tool fits, but there is no explicit when-not guidance and no mention of when to prefer read_care_document or care_briefing instead. Usage is inferable rather than stated.

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