Architectural evaluation: packages/wavs-mcp

[Copilot]

@dakom requested an architectural review of packages/wavs-mcp — no code changes, commentary only.

Findings:

• OpenAPI overlap: ~13 of ~16 tools are thin HTTP proxies over the existing REST API. A generic OpenAPI-to-MCP bridge would auto-generate most of them. The only meaningfully differentiated pieces are the direct chain-write tools (which bypass the HTTP API and call EVM contracts via alloy) and the local scaffold/build/WIT tools.

• Private key security: Embedding WAVS_CHAIN_WRITE_CREDENTIAL/WAVS_SIGNING_MNEMONIC in the MCP server is a poor posture — an AI can autonomously sign and broadcast on-chain transactions with no confirmation gate or human-in-the-loop. Chain-write capability either needs explicit approval hooks or should be moved to a human-controlled CLI surface.

• Scaffold quality: wavs_scaffold_component generates generic WASM component boilerplate (Cargo.toml + lib.rs). The WAVS-specific artifact — the service definition JSON that wires triggers to components and declares the service manager — is not generated or explained. The scaffold covers the generic WASM side, not the WAVS-specific deployment configuration.

• Repo placement: With the HTTP-proxy portion largely replaceable by a generic bridge, the remaining unique value is small. Separation is reasonable given the independent release cadence of MCP tooling, though keeping it in the monorepo is defensible while wavs_types coupling remains tight.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[dakom]

@copilot given all the above, if the goal is to expose an MCP server, what do you think about a completely separate repo focused just on that?

[Copilot]

@copilot given all the above, if the goal is to expose an MCP server, what do you think about a completely separate repo focused just on that?

A separate repo makes sense given the evaluation. The main reasons:

• Release decoupling: MCP tooling will iterate faster than the core node. Tying its releases to the core cycle means either holding back useful MCP improvements or bumping the core version for tooling-only changes.
• Scope clarity: The unique value in the MCP server is a thin set of tools — chain-write operations, WIT interface lookup, and scaffold/build helpers. That's a coherent, small surface that fits cleanly in its own repo without pulling in the broader node codebase.
• Security boundary: Moving the chain-write tools to a separate repo makes the security surface explicit. It's easier to add approval gates or strip them entirely when the package isn't embedded in the core release alongside everything else.
• Reduced noise: Contributors and operators who don't use MCP don't need to read MCP changelogs, and MCP-only issues/PRs don't clutter the core tracker.

The one prerequisite is that wavs_types is published to crates.io so the external MCP repo can depend on it without vendoring. Once that's in place, the separation is straightforward. If wavs_types isn't already published, that's a one-time cost worth paying regardless — it also enables other external tooling to consume the shared types.

The HTTP-proxy portion (the majority of the current tools) could potentially be dropped in favor of a generic OpenAPI bridge, which would make the separate repo even leaner — focusing only on chain-write operations and local dev tools that genuinely require custom logic.

[dakom]

@copilot yeah, wavs_types is published on crates.io and docs.rs as wavs-types

[dakom]

was good research, but not a real PR