MetricBridge (formerly Health Export AI)

Overview Schema Source Related Servers Discussions Admin

list_events

Read-onlyIdempotent

List merged app and agent health context events sorted by date, with optional type, tag, and date-range filters. Use it to review medication starts, habits, visits, shifts, episodes, and travel.

Instructions

Logged context events: medication starts, habit changes, doctor visits, life events, shift blocks, episodes, travel, and any type a newer app adds. Merges the app's health-events.json with health-events-agent.json (events logged with add_event); every event carries source "app" or "agent". Optional {type, tag, start, end} filters; a range event matches a window it overlaps. Sorted ascending by date. Returns available:false when neither file exists; absence means nothing was logged or exported, not that nothing happened.

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

Input Schema

Name	Required	Description
`end`	No	YYYY-MM-DD
`tag`	No	Match events carrying this tag.
`type`	No	Event type, e.g. medication, habit, visit, life, shift, episode, travel, other. Unknown types pass through and can be filtered by their stored string.
`start`	No	YYYY-MM-DD

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.4.0Aug 21, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: discloses the merge of health-events.json with health-events-agent.json, that every event carries a source of "app" or "agent", the ascending sort order, and the available:false shape when neither file exists. That is exactly the kind of provenance and empty-state context annotations cannot convey.

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?

Front-loads what the tool returns, then provenance/merge, then filters, then ordering, then the empty-state caveat. Dense but every clause carries information an agent needs; nothing is redundant.

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?

With no output schema, the description carries the return-value burden and does so: source field, sort order, and available:false. Combined with the filter overlap rule and the empty-result interpretation, an agent has everything needed to call and interpret it correctly.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: the optional {type, tag, start, end} set is described as filters and the range rule 'a range event matches a window it overlaps' explains behavior the schema does not. It does not detail date format or default window, but the schema already supplies YYYY-MM-DD.

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?

Names a specific verb (list) plus the concrete resource: logged context events across a named set of types. The enumerations (medication starts, habit changes, doctor visits, shift blocks...) make it unmistakable, and it explicitly distinguishes its contents from the sibling add_event by noting agent-logged events.

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?

Explains filter semantics and the overlap rule, and gives the important interpretive caveat that an empty result means nothing was logged/exported rather than nothing happened. It does not explicitly route the agent against alternatives like query_health_data or get_structured_export, so it falls short of full when/when-not guidance.

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