TOCA 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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| toca.system.healthA | Return deterministic TOCA Core MCP surface and persistence readiness metadata. |
| toca.capabilities.searchB | Search the canonical capability catalog without materializing one MCP tool per capability. |
| toca.capabilities.describeA | Resolve aliases and return the canonical typed, policy and lifecycle contract for one capability. |
| toca.workflow.createB | Create a durable tenant-scoped workflow using the existing workflow engine and transactional outbox. |
| toca.workflow.getA | Read one durable workflow inside the authenticated tenant boundary. |
| toca.workflow.advanceD | Apply one explicit, evidence-bearing transition through the existing durable workflow engine. |
| toca.approval.requestB | Create a formal ApprovalRecord bound to the exact typed execution payload and authenticated requester. |
| toca.approval.getA | Read one ApprovalRecord owned by the authenticated requester. |
| toca.executeC | Resolve identity, capability, typed schema, policy, risk, approval, idempotency, handler, provider read-back and audit before reporting success. |
| toca.verifyB | Verify the immutable audit chain, exact execution descriptor and fresh provider state for side effects. |
| toca.audit.queryB | Read immutable audit-ledger records by correlation inside the authenticated tenant boundary. |
| toca.event.getA | Read one canonical EventRecord inside the authenticated tenant boundary. |
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 12 tools
Most tools have clearly distinct purposes (e.g., toca.workflow.create vs toca.workflow.get vs toca.workflow.advance). The exception is toca.system.health versus toca.verify—both touch on readiness/state but from different angles. Minor overlap is acceptable.
All tool names follow a consistent pattern of 'toca.<domain>.<verb>' with clear verbs (get, create, advance, query) and nouns (capability, workflow, approval, audit, event). No mixing of styles or conventions.
12 tools is well within the ideal 3-15 range. Each tool covers a distinct operation across core domains (system, capabilities, workflows, approvals, audit, events), and the count feels appropriately scoped for the server's purpose.
The server covers key operations but has notable gaps: workflow lacks an update/abort/delete, approval only has create/get (no approve/deny), and there is no event publishing—only reading. The execute tool is comprehensive but may serve as a generic workaround, yet missing lifecycle operations could still cause agent failures in certain flows.