Transit

Showing 25 of 29 from the live probe.

• Get Platform Guide

  Retrieves the high-level Transit platform guide. Use this for product orientation, surface mapping, canonical architecture, and access-model understanding. Do not expect tool-execution policy here; the detailed pre-call and data-completion rules now live directly in each MCP tool description.

• Get User Profile

  Retrieves the canonical Transit profile used for personalization, interpretation, language, unit preferences, and food-goal context. Read this before interpretation or writes that depend on age, sex, language, display systems, or user naming. Do not guess profile-dependent settings when you can fetch them first.

• Update User Profile

  Updates the canonical Transit user profile. Before calling, convert the user request into explicit structured profile fields only. Resolve relative dates into concrete local dates before writing, preserve existing fields the user did not ask to change, and do not hide unrelated state inside free-form notes or prompts.

• Get Medical Context

  Retrieves active medications, conditions, and the medical context summary. Read this before interpreting biomarkers, symptoms, glucose patterns, or intervention outcomes whenever medication or condition context could materially change meaning.

• Upsert Medication

  Creates or updates a medication entry in the canonical medical context. Use only for explicit, bounded medication changes. Convert conversational text into structured medication fields and avoid burying medication changes inside generic notes elsewhere.

• Upsert Condition

  Creates or updates a condition entry in the canonical medical context. Use only for explicit, bounded condition changes. Convert conversational text into structured condition fields and avoid hiding durable medical-state changes inside unrelated notes.

• Delete Medication

  Deletes an existing medication entry from the Transit medical context.

• Delete Condition

  Deletes an existing condition entry from the Transit medical context.

• Get Feelings

  Retrieves feel barometer / diary entries and the current feelings summary. Read this when recovery, mood, stress, or self-reported daily state could change interpretation or recommendations.

• Get Goals

  Retrieves the user goals stored in Transit, including title, type, status, priority, deadline, success metric, target summary, and constraints. Use this whenever the user asks about goals or when a Goal reply context is active so recommendations can stay anchored to the selected goal instead of generic health advice.

• Upsert Feeling

  Creates or updates a feel barometer / diary entry. Before calling, translate the user message into a bounded entry with a concrete local date, structured scores when the user supplied them, and optional free-form title/notes/tags. Do not fabricate scores that are not implied, but do preserve explicit subjective wording in notes when it matters.

• Delete Feeling

  Deletes an existing feel barometer / diary entry.

• Get Food Log

  Retrieves food tracker meals and aggregated day totals for a date or date range. Use this before editing, deduplicating, or summarizing nutrition so the model works from the existing canonical meal history instead of assumptions. Prefer the narrowest relevant date or date range.

• Log Food Intake

  Creates or updates a food tracker meal. Before calling, convert the user request into a structured meal rather than a free-form note. Infer `meal_type`, title, and source when the request makes them reasonably clear. Prefer itemized foods when possible, but if the user only gives totals then send a totals payload and let Transit store a synthetic meal-total item. Complete obvious missing fields from context instead of sending a half-empty meal, but stop and ask when the remaining ambiguity would

• Delete Food Meal

  Deletes an existing food tracker meal and all of its items. Use only when the user explicitly wants a meal removed; do not treat corrections, edits, or uncertainty as delete requests.

• Manage Application

  Lists, retrieves, creates, or updates structured Transit application records. Use `list_applications` or `get_application` before editing an existing application so unchanged fields are preserved. For new applications, provide a clear `title`; for updates, provide `application_id` or `id` and only the fields that should change. Top-level properties are canonical fields, while `fields` stores application-tool-specific custom fields. By default `fields` and `metadata` are merged with existing valu

• Get Health Context

  Retrieves comprehensive Transit health context including biomarkers, wearables, integrations, and recent summaries. Use this as the default joined-up read before giving recommendations or cross-domain interpretation. Pick the narrowest useful timeframe, add a provider filter when relevant, and request raw data only when the answer actually needs row-level evidence.

• Get Biomarkers

  Retrieves biomarker and lab data with category filtering and interpretation metadata. Use this for canonical biomarker history before drawing conclusions from labs or building summaries. Prefer a relevant category and timeframe instead of pulling everything by default.

• Get Health Recommendations

  Provides AI-generated health recommendations based on stored Transit data. Call this only when enough grounded context exists or after reading the relevant health context first. Recommendations must stay tied to actual stored data, provider freshness, and known limitations rather than generic wellness filler.

• Update Health Metrics

  Writes one or more metrics into the canonical Transit dashboard record layer. Before calling, normalize the user request into concrete metric rows with explicit `metricType`, numeric `value`, `unit`, and `timestamp`. Use canonical biomarker names or aliases that Transit can normalize. When a lab panel, report, OCR result, or narrated batch contains multiple values, proactively assemble the full `entries` batch and shared upload context (`groupTitle`, `sourceRef`, `batchId`) instead of sending on

• Get Daily Insight

  Builds a concrete daily action from the latest Transit wearable/activity context and biomarker state. Use this when the goal is a concise next step grounded in current data availability. The result should reflect missing-provider or stale-data limitations instead of pretending absent categories exist.

• Update Biomarkers

  Writes one or more biomarker or lab values into Transit using the canonical biomarker mapping and grouped upload pipeline. Before calling, convert OCR text, report text, or conversational lab data into canonical biomarker rows with normalized marker names, numeric values, units, and dates. If one report contains multiple biomarkers, proactively send a complete `entries` batch instead of fragmented single writes. Fill obvious missing fields such as strongly implied units or canonical marker alias

• Get Active Interventions

  Returns active interventions plus interventions starting in the next 7 days. Use this before daily insight, follow-up guidance, or intervention-aware interpretation so current experiments are treated as active context rather than ignored.

• Create Intervention

  Creates or updates a Transit intervention plan from conversation context. Before calling, turn the request into a concrete, trackable protocol with a clear title, explicit start and end dates, and useful tags. Resolve relative dates into concrete local timestamps, use this only for deliberate experiments or protocols rather than vague aspirations, and include calendar sync only when the user asked for it or clearly confirmed it.

• Review Intervention

  Closes or reviews an intervention with subjective feedback and optional post-lab reference. Before calling, compress the outcome into a concrete results summary plus any user-language feedback that should be preserved. Use this when the user is explicitly evaluating whether an intervention helped, failed, or should be compared against before/after labs.