ORP MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ORP_HOME | No | Where the profile, plans and log live (default: platform config dir, e.g. ~/.config/orp) | |
| ORP_CACHE_DIR | No | Public-data HTTP cache (default: platform cache dir) | |
| ORP_OVERPASS_URL | No | Overpass API instance URL (recommended for heavy use) | |
| ORP_NOMINATIM_URL | No | Nominatim geocoding instance URL (recommended for heavy use) | |
| ORP_OPENACTIVE_FEEDS | No | Comma-separated OpenActive RPDE feed URLs (also $ORP_HOME/openactive-feeds.json) | |
| ORP_OPENFOODFACTS_URL | No | Open Food Facts instance URL (recommended for heavy use) | |
| ORP_OPEN_WEARABLES_URL | No | Your own Open Wearables instance URL (optional) | |
| ORP_OPEN_WEARABLES_API_KEY | No | API key for your Open Wearables instance (optional) | |
| ORP_OPEN_WEARABLES_USER_ID | No | User ID for your Open Wearables instance (optional) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| profile_getA | Read the local ORP profile and the readiness gate status. |
| profile_updateA | Create or patch the local profile. Never include diagnoses, medications or conditions. |
| readiness_questionsB | Generic pre-activity screening items, the wellness disclaimer and the red-flag notice. |
| geocodeA | Turn a place label into coarse coordinates (Nominatim). Sends only the label. |
| find_facilitiesA | Gyms, sports centres, outdoor fitness stations, pools, tracks and parks from OpenStreetMap. Defaults to the profile home area and travel radius. Sends only coarse coordinates. |
| find_sessionsB | Classes and bookable facility slots from ORP provider manifests and OpenActive feeds. |
| find_mealsC | Places to eat that fit the diet, from OpenStreetMap and ORP provider menus. |
| food_lookupA | Packaged-food information from Open Food Facts, by barcode or by name. |
| wearable_summaryA | Aggregated sleep, resting heart rate, steps and workouts from the user's own Open Wearables instance. Opt-in; returns aggregates only. |
| plan_validateB | Validate a plan against the schema, the readiness gate and the safety guardrails. |
| plan_saveA | Validate again and store the plan as the current plan. Refuses invalid plans. |
| plan_get_currentA | Return the current plan, or null. |
| log_adherenceC | Append an entry to the adherence log (append-only). |
| adherence_summaryB | 7- and 28-day adherence metrics for the current plan. |
| plan_suggest_adjustmentsA | Evaluate the current plan's adjustment_rules against adherence and wearable aggregates. Returns a proposal (JSON Patch + proposed plan). Never changes the stored plan: ask the user for approval, then call plan_save. |
| estimate_energyA | Opt-in energy ESTIMATES: Mifflin-St Jeor resting energy and Compendium MET values. Refuses unless the profile enables show_energy_estimates. Never a prescription. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| create_weekly_plan | Build, validate and save a one-week routine (locales: en, es-ES). |
| weekly_review | Review adherence and wearable aggregates, propose adjustments, save only with approval. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| profile_resource | |
| plan_resource | |
| adherence_resource |
TDQS
Scored across 16 tools
Each tool targets a distinct resource or action: profile get/update, facility/session/meal discovery, plan lifecycle, and adherence logging/summary. Minor overlap exists between plan_validate and plan_save (save re-validates) and between profile_get and readiness_questions, but the descriptions clarify the boundaries.
Most names follow a verb_noun pattern (find_facilities, estimate_energy, plan_save), but several are noun phrases (readiness_questions, wearable_summary, adherence_summary), one is a single verb (geocode), and food_lookup reverses the verb/object order. The snake_case convention is consistent, but the semantic pattern is mixed.
16 tools is slightly above the ideal 3-15 range, but the domain spans profile management, discovery, nutrition, wearables, plans, and adherence, and each tool has a distinct purpose. No tools feel redundant.
Core workflows are covered: profile get/update, plan validate/save/get, adherence log/summary, and location/nutrition discovery. Obvious gaps include no plan delete/history, no retrieval of raw adherence entries, and no booking action for discoverable sessions or facilities.