Loading ToolBench
Meta-MCP server that auto-detects and composes installed Delx Wellness connectors into a unified body data layer.
Server defines 9 tools with explicit schemas and descriptions. Naming follows verb_noun pattern (living_body_*). Descriptions are present (avg ~120 chars) but lack specificity on WHEN to call each tool vs alternatives. Schemas declare enums for response_format and privacy_mode, but lack detail on output structure. Critical gap: no documented return schemas for any tool, LLMs cannot plan downstream calls. Error handling guidance is absent. Tools 1-4 are read-only discovery; tools 5-7 spawn subprocesses and require explicit_user_intent gate, but this safety mechanism is underdocumented. Tool composition is sound (ask → compose_context → daily_brief form a logical chain), but parameter relationships (e.g., when sources array is useful) are not explained.
Machine-readable install and operating instructions for AI agents. Call first when onboarding.
Ask a wellness question; composes detected connectors in parallel and returns a synthesized answer + reasoning trace. Spawns subprocesses — requires explicit_user_intent.
Capabilities and availability matrix across all known connectors. Describes which tools are available per connector and recommended agent flow.
Compose wellness context across all detected connectors in parallel. Returns unified delx-wellness-context/v1 contract. Spawns child MCP processes — requires explicit_user_intent.
Ready/not-ready snapshot of local connector detection without calling vendor APIs or child data tools.
Synthetic daily briefing aggregating each detected connector's daily summary/context. Spawns child MCP processes — requires explicit_user_intent: true.
No documented output schemas for any tool. LLMs cannot infer what fields to expect (e.g., does living_body_status return detected[], total_known, or both?). Smoke tests show structuredContent exists but schema is invisible to agents.
Parameter relationships underdocumented. 'sources' array on tools 5-7 lacks guidance on when/how to use it. 'privacy_mode' enum (raw|structured) has no explanation of what each mode returns or when to choose one.
explicit_user_intent safety gate on subprocess-spawning tools (5-7) is not explained in descriptions. LLMs may not understand why this boolean exists or what happens if false. No error guidance for when intent is missing.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Static inventory of composed domains, known connectors, privacy modes and recommended first calls. No live child calls.
Health check across all known connectors. Reports which are installed, which are missing with install hints, and which failed to initialize.
Detect which Delx Wellness connectors are installed locally. Safe, no subprocess spawning.
No error handling guidance. Tools lack descriptions of failure modes (e.g., what if a connector fails to initialize? What if no connectors are detected?). Agents cannot plan recovery.
Tool selection guidance missing. Descriptions do not explain when to call living_body_ask vs living_body_compose_context vs living_body_daily_brief. LLMs must guess based on names alone.