Delx Living Body
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| living_body_agent_manifestA | Machine-readable install and operating instructions for AI agents. Call first when onboarding. |
| living_body_connection_statusA | Ready/not-ready snapshot of local connector detection without calling vendor APIs or child data tools. |
| living_body_data_inventoryA | Static inventory of composed domains, known connectors, privacy modes and recommended first calls. No live child calls. |
| living_body_statusA | Detect which Delx Wellness connectors are installed locally. Safe, no subprocess spawning. |
| living_body_askA | Ask a wellness question; composes detected connectors in parallel and returns a synthesized answer + reasoning trace. Spawns subprocesses — requires explicit_user_intent. |
| living_body_daily_briefB | Synthetic daily briefing aggregating each detected connector's daily summary/context. Spawns child MCP processes — requires explicit_user_intent: true. |
| living_body_compose_contextA | Return the normalized delx-wellness-context/v1 shape merged across all detected sources. Spawns child MCP processes — requires explicit_user_intent: true. |
| living_body_health_checkA | Returns status for every known connector — including missing ones — with install hints. |
| living_body_capabilitiesA | Self-description of this MCP, including the per-connector availability matrix. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| living_body_daily_checkin | Compose a daily readiness brief across installed connectors, then recommend training intensity. |
| living_body_triage_setup | Diagnose which wellness connectors are missing and how to install them. |
| living_body_ask_compose | Answer a wellness question by composing installed MCP connectors. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| living_body_data_inventory | Static inventory of composed domains, known connectors and recommended first calls. |
| living_body_agent_manifest | Machine-readable install and operating instructions for AI agents. |
| living_body_capabilities | Self-description and per-connector availability matrix. |
| living_body_connection_status | Live detection snapshot of installed wellness connectors (no child data tools). |
TDQS
Scored across 9 tools
Three tools—connection_status, status, and health_check—all report connector availability and can be easily confused. Similarly, agent_manifest, data_inventory, and capabilities all serve self-description/onboarding purposes, making the tool boundaries unclear.
All tools share the living_body_ prefix and snake_case, which is helpful, but the pattern is mostly noun phrases with occasional verb forms like ask and compose_context. The naming is readable but not a consistent verb_noun convention.
Nine tools is within the ideal range, but several status and metadata tools overlap significantly, making the set feel slightly padded. The count is not excessive overall.
The core workflows—discovering connectors, checking health, asking wellness questions, and composing context—are covered. Minor gaps like direct per-connector data access or configuration tools exist, but agents can likely work around them.