Nova

Log a dose

log_medication

Record medication doses as taken or skipped using names, purposes, or pill descriptions, prevent double doses, and let caregivers log for others.

Instructions

Record that a medication dose was taken (or skipped). Understands names, purposes and how pills look ('my blood pressure pill', 'the pink one', 'my morning pills'). Guards against double doses: if the dose was already logged it says so instead of logging again. Caregivers can log on the elder's behalf.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "log_medication"
  }
}

Input Schema

Name	Required	Description	Default
`status`	No	taken or skipped	taken
`medication`	No	Medication name, purpose, or description; empty means all doses due now
`time_of_day`	No	morning, evening, bedtime, or a time like '8 AM'; empty means now

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 24, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Adds behavior beyond the annotations: fuzzy recognition of medication names/purposes/appearance, double-dose guarding, and caregiver proxy logging. These are meaningful operational details not present in the readOnlyHint, idempotentHint, or destructiveHint fields.

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

Conciseness5/5

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

Three short sentences, front-loaded with the core action and followed by the most important behavioral safeguards. No sentence is wasted.

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

Completeness5/5

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

For a mutation tool with full schema coverage, annotations, and an output schema, the description covers the action, fuzzy matching, duplicate prevention, and caregiver use. It provides enough context for an agent to invoke it 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 coverage is 100%, so the parameters are already fully documented. The description reinforces that medication values can be natural-language descriptions like 'my blood pressure pill' or 'the pink one,' but it does not add syntax or default behavior beyond the schema.

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

Purpose5/5

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

States a specific verb and resource: 'Record that a medication dose was taken (or skipped).' This clearly distinguishes the write action from read-oriented siblings like check_medication.

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?

Gives clear context for when to use it: recording a taken or skipped dose, including for fuzzy medication references and caregiver logging. It does not explicitly name alternatives such as check_medication, so the routing guidance is strong but not exhaustive.

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