MystoraX MCP Server
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| mystorax_routing_guideA | Fetch MystoraX routing doctrine (authors, Hands, Science OS, refusals). Call this before inventing routes. |
| mystorax_surfacesC | List MystoraX capability surfaces with status (wired|guided|inventory|refused|deferred). Optional status filter. |
| mystorax_capability_lookupC | Lookup surfaces/capabilities by id substring or keyword. |
| mystorax_submit_goalC | Submit a goal to Conductor POST /v1/goal. Prefer this over talking to bridges or CLIs directly. job_class may be research|coding|planning|science|ops|voice_frontdoor. |
| mystorax_job_statusC | Poll durable job status by job_id / wait_id. |
| mystorax_wait_stream_hintC | Return the SSE wait-wake recipe so Hands do not burn CLI tokens waiting. |
| mystorax_science_statusB | Science OS / Axiom readiness + MCP proxy status. |
| mystorax_science_resumeC | Resume a Science OS campaign (max_phases budget; auto-stop at EVIDENCE; never auto-CERTIFY). |
| mystorax_axiom_tool_searchA | Search allowlisted Axiom MCP tools (meta-proxy). Does not dump the full bio catalog. |
| mystorax_axiom_tool_callC | Call one allowlisted Axiom tool via Conductor. Fail-closed without MYSTORAX_AXIOM_MCP_TOKEN on the Conductor side. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Most tools target clearly distinct concerns: routing guide vs surfaces vs goal/job lifecycle vs science/axiom operations. However, some boundary overlap exists between mystorax_surfaces, mystorax_capability_lookup, and mystorax_axiom_tool_search—all three concern lookup/discovery of capabilities, and an agent could easily confuse which returns what. mystorax_axiom_tool_search vs mystorax_axiom_tool_call are distinct but could be misselected at the edge.
All tool names follow a consistent mystorax_ snake_case prefix pattern. However, the post-prefix names mix conventions: some are verb_noun (submit_goal, call_tool, search), some are noun-oriented (surfaces, job_status, science_status, routing_guide), and 'wait_stream_hint' and 'capability_lookup' vary in style. There's no consistent verb-first pattern across the set, making it less predictable.
10 tools is a well-scoped count for a platform orchestration server covering routing doctrine, capability discovery, goal/job submission, and science operations. Each tool serves a distinct functional area and the count feels appropriate—not bloated, not thin.
The surface covers the core lifecycle: routing doctrine, capability discovery, goal submission, job status polling, wait-stream handling, science readiness, and tool execution. The main gap is the absence of any cancellation, update, or error-recovery tool for submitted goals/jobs, so agents cannot abort or modify a running job. Minor gaps for resume campaign control, but core workflows are covered.