MCP tools - Vitalog

Vitalog exposes 27 tools through Streamable HTTP at the API’s /mcp endpoint. Connect a client before calling them. Read tools require health:read; record and goal writes require health:write. API-key administration is REST-only.

Tool	Purpose
`health_get_context`	Read a bounded current snapshot with observation ages, provenance and missingness; no targets or coaching memory.
`health_get_daily_summary`	Read a local day with qualified daily-total precedence, known subtotals and completeness. Studies remain overlapping interval observations.
`health_get_trends`	Read up to 20 catalog metrics over at most 366 days, partitioned by supplied context. Use health_get_catalog for identifiers. No predictions.
`health_list_records`	Page through recorded observations using allowlisted dates, types and source filters; no arbitrary predicates.
`health_get_record`	Retrieve one recorded observation and optionally a bounded page of immutable revisions.
`health_get_catalog`	Discover exact supported keys, panel memberships, nested fields, units and complete schemas. Returns code definitions independently of health data.
`health_log_measurements`	Save an atomic bounded batch of supplied measurement observations. Actual recorded events only. Use health_get_catalog for exact fields and units; do not infer missing values.
`health_log_nutrition`	Save one supplied nutrition observation. Actual recorded events only. Use health_get_catalog for exact fields and units; do not infer missing values.
`health_log_hydration`	Save one supplied hydration observation. Actual recorded events only. Use health_get_catalog for exact fields and units; do not infer missing values.
`health_log_activity`	Save one supplied activity observation. Actual recorded events only. Use health_get_catalog for exact fields and units; do not infer missing values.
`health_log_sleep`	Save one supplied sleep observation. Actual recorded events only. Use health_get_catalog for exact fields and units; do not infer missing values.
`health_log_checkin`	Save one supplied check-in, including optional data.mood (very_low, low, neutral, good, great). Actual recorded events only. Numeric ratings remain separate. Use health_get_catalog for exact fields; do not infer missing values.
`health_log_intake`	Save one supplied intake observation. Actual recorded events only. Use health_get_catalog for exact fields and units; do not infer missing values.
`health_log_lab_results`	Save an atomic bounded batch of supplied lab_result observations. Actual recorded events only. Use health_get_catalog for exact fields and units; do not infer missing values.
`health_correct_record`	Correct one record using a complete replacement and expected version. Preserve history and supplied provenance; a voided record stays voided.
`health_void_record`	Void one record using its expected version and a reason. Exclude it from effective calculations and preserve history; this is not permanent erasure.
`health_get_goal_catalog`	Discover supported goal metrics, canonical units and fixed comparison rules. Goals are explicit user targets, separate from observed records.
`health_set_goal`	Set or reactivate a user-supplied goal from today in the server timezone. Use expected_version=0 for a new metric, otherwise its current version. Weight requires an explicit baseline on creation; it is retained on edits unless supplied. No automatic recommendations.
`health_list_goals`	List current goals, active by default. Use health_get_goal_progress for historical goals and observed progress on a particular date.
`health_get_goal`	Read a goal and optionally a bounded page of its immutable revisions, newest first.
`health_archive_goal`	Archive a goal from today with an expected version. Preserve history and previous-day progress. Reactivate with health_set_goal.
`health_get_goal_progress`	Compare goals effective on a local date with qualified observed values. Unknown stays null. Nutrition uses limit utilization; water and exercise use target completion; weight uses an explicit baseline. Daily totals take precedence, gross calories are excluded, and elapsed time is never inferred as active minutes.
`health_create_attachment_upload`	Reserve one reusable image or PDF attachment (maximum 20 MB / 20,000,000 bytes). Supply its actual filename, MIME type, byte length and SHA-256. Send the original binary file with HTTP PUT to the returned signed URL and headers within 15 minutes; do not send ledger credentials to storage. Then call health_complete_attachment_upload. Files are not automatically transferred by MCP. Never invent a file or checksum.
`health_complete_attachment_upload`	Verify an uploaded file’s bytes, size, SHA-256 and image/PDF type, and make the attachment immutable and ready. Only ready IDs can be supplied in attachment_ids when logging or correcting any record. Reuse one ID across nutrition, measurements or a lab-results batch without uploading again. Retry failures with the same idempotency key.
`health_get_attachment`	Get attachment metadata and upload state. This does not return file bytes or a download URL.
`health_list_attachments`	List reusable attachments with cursor pagination. Optionally filter by a record and its version; without a version, use that record’s current attachments. Omitting record_id lists the ledger’s attachments. No file contents or signed URLs are returned.
`health_get_attachment_download`	Get a private, signed download URL for a ready attachment, valid for five minutes. Treat the URL as sensitive temporary access and do not save it in records. Download the file outside MCP; health data and attachment metadata stay separate.

Mutations require an idempotency_key. Reuse the same key and arguments when retrying. Corrections, voids and goal changes also require the current expected_version. See record contracts and goals.