Open tool mesh

OpenTool Mesh is a decentralized tool discovery, invocation, and execution-memory layer for AI agents. Today, most agents still call tools through hardcoded local configuration: the developer manually wires in the endpoint, schema, version, owner, and invocation method before the agent can use anything. OpenTool Mesh turns that into a portable tool lifecycle where a tool provider can publish a manifest, an agent can discover a tool by capability, resolve the tool’s identity, verify its manifest, invoke the remote tool node, and persist the entire execution as an auditable trace. The core flow is publish -> discover -> resolve -> verify -> call -> trace -> report.

In our demo, a Solidity audit agent receives a smart contract and asks for the capability solidity-static-analysis. Instead of directly calling a hardcoded scanner, the agent uses OpenTool Mesh to discover a registered Solidity scanner tool, resolve its ENS-based identity, load its 0G-backed manifest, verify the manifest hash, owner binding, schema compatibility, and SDK version range, then invoke the remote tool node over an AXL-style transport. The tool node returns structured vulnerability findings, and the agent turns them into an audit report. Every important part of the run is persisted: the selected capability, resolved identity, manifest URI, manifest hash, input hash, output hash, request artifact, response artifact, tool output, verification result, invocation status, trace URI, and final report URI.

The project is not a marketplace, payment layer, or agent swarm. It is infrastructure for agents who want tools to be discoverable, verifiable, remotely callable, and reviewable after execution. The repository includes a TypeScript SDK, an opentool CLI, a remote tool-node service, a Solidity audit-agent example, an MCP server, agent installation templates, OpenClaw and Hermes adapters, and a dashboard that reconstructs the latest run from the persisted execution trace. The goal is to give AI agents a tool layer that behaves more like open infrastructure: tools have identity, tools have versioned manifests, tool calls have provenance, and users can see exactly what happened during an agent run.

We built OpenTool Mesh as a TypeScript-first pnpm/Turbo monorepo. The shared package defines the core contracts: ToolManifest, ToolIdentity, CapabilityIndexEntry, ToolInvocationRequest, ToolInvocationResponse, AxlInvokeEnvelope, AxlResultEnvelope, ExecutionTrace, and AuditReport. The SDK is the orchestration layer. It exposes the main lifecycle methods: publishManifest, discoverTools, resolveIdentity, loadManifest, verifyManifest, invokeTool, saveArtifact, recordTrace, and buildAuditReport. The CLI is a thin command layer over the SDK and supports publish, discover, resolve, verify, call, and trace, so developers can exercise the same flow from the terminal that an agent uses at runtime.

Partner technologies map directly to the architecture. ENS is the identity and discovery entry point: each tool has an ENS-based name, and OpenTool Mesh records metadata such as manifest URI, manifest hash, owner, latest version, and capabilities. 0G is the storage and memory layer: tool manifests, invocation requests, invocation responses, tool outputs, traces, and audit reports are stored as durable artifacts, while capability indexes and trace summaries give agents a way to discover tools and review past runs. Gensyn AXL is the invocation layer: the manifest specifies the remote peer and method, and the SDK wraps each request in an otm.tool.invoke envelope before sending it to the tool node. MCP is the compatibility layer: the manifest carries MCP-compatible input and output schemas, and the project also ships an MCP server so external agent hosts can access OpenTool Mesh tools through standard tools/list and tools/call semantics.

The remote tool node is a Node.js HTTP service exposing /health, /invokeTool, and an MCP bridge route shaped like /mcp/{peer}/{service}. The demo tool is a Solidity pattern scanner that checks for security-relevant patterns such as external value transfers, missing admin-event emission, and pause-flow issues, then returns normalized findings and a severity summary. One notable hack is the MCP bridge inside the tool node: it allows the same service to accept a native OpenTool Mesh invocation envelope or a simpler JSON-RPC/MCP-style payload, normalize both into the same internal request format, and return the same structured otm.tool.result response. That let us keep the OpenTool Mesh trace model while still making the tool node compatible with AXL/MCP-style routing.

We also built an MCP server around the mesh so agents do not need to import the SDK directly. It exposes tools such as opentoolmesh_publish_tool, opentoolmesh_discover_tools, opentoolmesh_resolve_tool, opentoolmesh_verify_tool, opentoolmesh_call_capability, opentoolmesh_get_trace, and opentoolmesh_solidity_static_analysis. On top of that, we added install templates for Codex, Claude Code, Cursor, Docker, OpenClaw, and Hermes, plus dedicated OpenClaw and Hermes adapters. The dashboard is read-only and focuses on explainability: it displays the full lifecycle from publish to report, including the resolved ENS identity, manifest URI and hash, verification checks, AXL peer, request and response artifact URIs, input/output hashes, trace URI, report URI, and finding severity summary. This makes the project demonstrable as real agent infrastructure rather than just a single audit bot.