Nightscout MCP Server

analyze_meal

Assess post-meal glucose response by locating the meal bolus, tracking glucose before, during, and after, and calculating peak, rise, and recovery metrics to determine bolus adequacy.

Instructions

Automatically analyze post-meal glucose response. Finds the meal bolus/carbs entry, tracks glucose before, during, and after the meal. Calculates: pre-meal glucose, peak value, time to peak, rise amount, time to return to range. Assesses bolus adequacy.

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": "analyze_meal"
  }
}

Input Schema

Name	Required	Description	Default
`meal_time`	No	Meal time (ISO 8601 or 'YYYY-MM-DD HH:mm'). If omitted, finds the most recent meal bolus.
`hours_after`	No	Hours to analyze after the meal (default 3)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.0Sep 6, 2026

TDQS

A4/5.0

Behavior4/5

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

No annotations are present, so the description carries the full behavioral burden. It clearly discloses the analysis workflow: locating the meal/carbs entry, tracking glucose before/during/after, computing specific metrics, and assessing bolus adequacy. It does not explicitly state that the operation is read-only or describe no-meal-found behavior, but it is far more transparent than a minimal description.

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?

The description is four tight sentences with no filler. The core purpose is front-loaded, the workflow is summarized clearly, and the metric list is compressed into an efficient enumeration. Every sentence contributes functional information.

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 no output schema and no annotations, the description does a good job of explaining the workflow and the main computed outputs. It lacks explicit details about return format and edge cases like missing meal entries, but for a tool with two optional parameters it is largely complete.

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%, and the schema already documents both meal_time and hours_after with defaults, formats, and bounds. The description adds no parameter-specific detail, but it does not need to because the schema handles parameter semantics adequately.

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?

The description states a specific verb ('analyze') and a specific resource ('post-meal glucose response'), then enumerates the exact workflow and calculated metrics. This makes it easy to distinguish from related siblings such as glucose_at_time or overnight_analysis without opening their schemas.

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 post-meal framing implies when the tool should be used, and the mention of bolus adequacy gives some context. However, it does not explicitly direct the agent away from alternatives or provide exclusions, leaving tool selection partially to inference.

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