ActionMesh
ActionMesh is a framework-agnostic TypeScript registry that keeps an operation’s schema, implementation and failure contract in one place while transports stay thin.
The problem
A useful capability is often reimplemented as a backend route, agent tool, MCP handler and CLI script. Those copies gradually disagree on validation, errors, retries and behavior.
How I approached it
- 01Define the operation once with a typed input contract, optional output contract and one run function.
- 02Keep machine-readable failure codes and retryability beside the action itself.
- 03Make MCP-style, HTTP and CLI surfaces thin translation adapters.
- 04Stay framework-agnostic so the action layer can sit inside an existing application rather than replace it.
Key features
- Typed defineAction contracts
- Zod input validation
- Optional output validation
- Machine-readable errors
- Explicit retry semantics
- MCP-style tool adapter
- Node HTTP handler
- CLI invocation helper
Architecture
- Core
- TypeScript
- Contracts
- Zod schemas
- Execution
- Single action registry
- Surfaces
- Agent · MCP-style · HTTP · CLI
- Failures
- Typed codes + retryability
- License
- MIT
What ACTIONMESH is built to preserve.
- One implementation per capability
- Adapters translate; they do not own business logic
- Invalid input never reaches the action body
- Retry behavior should be explicit rather than inferred from prose
Useful answers, without the hunt.
Is ActionMesh another agent framework?
No. It intentionally does not own the model loop, UI, database or queue. It is a small shared-action layer designed to fit inside those systems.
Is its MCP support the official protocol transport?
The current v0.2.0 includes an MCP-style listTools/callTool adapter. An official @modelcontextprotocol/sdk transport is on the roadmap and is not claimed as shipped yet.
What surfaces does ActionMesh support today?
The current project includes the core action registry plus MCP-style tool, Node HTTP and CLI invocation adapters around the same action contracts.