Loading ToolBench
Myco v0.9 substrate daemon binary (L4 M6). Listens on stdio for operator requests (e.g. from operators/claude), drives the metabolic cycle, and orchestrates the Python kernel/tropism worker via the kernel/bridge/rust M5 protocol. Exposes 25 tools to Claude Code via MCP for gradient lifecycle, introspection, immune checks, mutation, ingestion, reproduction, and perception operations.
This MCP server exhibits critical gaps across nearly all definition quality dimensions. While 22 tools are registered, the source code provided does not include actual tool implementations, schema definitions, or parameter documentation. All tool definitions appear to be declarations only, no JSON Schema input objects are visible, no parameter descriptions exist beyond the generic tool descriptions, and output schemas are entirely undocumented. The tool descriptions themselves, though present, are domain-specific (metabolic, substrate, gradient language) and do not follow LLM-optimized patterns. None of the 54 agentic tool patterns are evident in the provided code sample. The TypeScript MCP server file (operators/claude/src/mcp_server.ts) is referenced but not included in the source. Without seeing actual parameter schemas, input validation, error handling code, or response structures, this evaluation is heavily constrained.
Advance the metabolic cycle (part of gradient lifecycle)
Query the current intent of the substrate (part of introspection/handshake)
Declare an owner objective (P14 §3.2 owner-objective declaration)
Enumerate DAG nodes since a given point (part of immune/integrity)
Evolve the substrate schema (part of mutation/evolution; v0.9 keyless — no owner-attestation surface)
Ingest raw material into the substrate (part of ingestion; P2)
Perturb an appetite axis with a delta value (part of gradient lifecycle)
NO INPUT SCHEMAS VISIBLE: All 22 tools lack visible JSON Schema definitions. Per hard scoring rule, schema score for each tool MUST be 0. No input parameter types, constraints, enums, or validation rules are documented in the provided source.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2026-07-28+ | v2 |
Perturb an axis using raw material input (part of ingestion; P2)
Query immune system events from the substrate (part of immune/integrity)
Query pending migrations in the substrate (part of introspection/handshake)
Query raw material from the substrate (part of ingestion; P2)
Query recent DAG nodes from the substrate (part of introspection/handshake)
Query self-euthanasia proposals (part of reproduction/mortality; P7)
Query substrate self-derived ID (P8 §5.6 self-derived id; v0.9 keyless; perception/substrate self-knowledge)
Query substrate observatory vital signs (Phase α M24.5 vital signs; perception/substrate self-knowledge)
Register a new appetite axis with the substrate gradient system (part of gradient lifecycle)
Run an immune system check on the substrate (part of immune/integrity)
Shutdown the substrate daemon (part of introspection/handshake)
Take a snapshot of the current substrate state (part of gradient lifecycle)
Sprout a child cultivar (part of reproduction/mortality; P8)
Submit a mutation to evolve the substrate (part of mutation/evolution; v0.9 keyless — no owner-attestation surface)
Retrieve information about the substrate (part of introspection/handshake)
TOOL DEFINITIONS NOT VISIBLE: The actual MCP tool registration code (operators/claude/src/mcp_server.ts) is referenced but not included in the provided source. Per hard scoring rule, tools with only inferred existence must be capped at 50 overall. This rule applies to all 22 tools, their definitions are inferred from file paths, descriptions, and risk labels only, not from actual code inspection.
NO PARAMETER DOCUMENTATION: Tool descriptions reference functionality (e.g., 'Register a new appetite axis', 'Perturb an appetite axis with a delta value') but contain no parameter details, no names, types, constraints, defaults, or usage guidance. LLMs cannot infer what parameters each tool accepts or how to structure calls.
DOMAIN-SPECIFIC JARGON WITHOUT GROUNDING: Descriptions use substrate/mycology domain language ('appetite axis', 'metabolic cycle', 'gradient lifecycle', 'cultivar', 'euthanasia proposals', 'sprout child') without explaining what these concepts mean in practical tool terms. An LLM without substrate documentation cannot determine when or why to call these tools or what results to expect.
NO OUTPUT SCHEMA DOCUMENTATION: No response schemas are documented. Descriptions do not state what fields are returned, their types, or which fields can be used for downstream tool calls. This violates the pattern:response-shaper rule and makes tool chaining impossible for an LLM.
NO ERROR HANDLING GUIDANCE: No descriptions state what errors are possible, what they mean, or how to recover. Destructive tools like myco_shutdown_substrate lack warning or confirmation patterns. Per pattern:recovery-guide and pattern:confirmation-request, agents need actionable error recovery steps.
WRITE/DESTRUCTIVE OPERATIONS LACK IDEMPOTENCY DECLARATION: Tools marked WRITE (register, perturb, submit, evolve, ingest, sprout, declare) do not document whether they are idempotent. Per pattern:idempotent-operation, agents must know whether repeated calls with identical input are safe or risk duplicates.
NAMING LACKS ACTION VERBS OR CLARITY: Some tools use vague verb patterns (query_*, run_*) or domain-specific names (sprout_child, euthanasia) that do not clearly signal the action to an LLM. Per pattern:tool naming rules, verbs should be clear and action-oriented (e.g., 'get', 'create', 'update', 'delete', 'search'). 'myco_declare_owner_objective' is unclear, does it register, update, or queue an objective?