Consider reorganizing MCP server as a separate package #646
Description
Context
During review of PR #595, we discussed the architectural placement of the MCP server implementation. While the current implementation integrates the MCP server as an in-process module within omnibus, there are valid concerns about this approach.
Discussion Summary
From PR #595 review comments:
Concerns raised (@ChrisPaprocki):
- MCP server targets a wide audience who may not care about core node implementation details
- Users will want to extend or customize the MCP server for their needs
- Separation would allow users to modify/update the MCP server without rebuilding the entire node
- The most common tech stack for MCP servers is TypeScript/Node, not Rust
- Running an auto-generated MCP server in-process could create stability risks (panics, memory usage, etc.) that affect the entire node
Agreed next steps:
- Create this ticket as a reminder to revisit the discussion
- Consider moving the MCP server into a separate package (but still in the same repo)
- Evaluate the tradeoffs between in-process integration and standalone deployment
Considerations for future design
Pros of separate package:
- Users can extend/modify without touching core node code
- No need to rebuild entire node for MCP server changes
- Isolation prevents MCP server issues from affecting node stability
- Could be implemented in more MCP-friendly tech stack (TS/Node)
- Users could run their own custom MCP servers alongside or instead
Cons of separate package:
- Interface maintenance friction between packages
- Process communication overhead
- Potentially duplicated dependencies or logic
- More complex deployment story
Related architectural consideration:
- Using an NGINX front end to throttle and protect APIs (MCP, Blockfrost) could complement a standalone MCP server architecture
Proposal
Evaluate options for reorganizing the MCP server:
- Separate Rust binary in same repo - Keep it in Rust but as a standalone process
- TypeScript/Node implementation - Rewrite in the ecosystem's preferred stack
- Hybrid approach - Core Rust library with thin TS/Node wrapper
- Status quo with improvements - Keep in-process but add better isolation/resource limits
Each option should be evaluated on:
- Ease of customization for end users
- Deployment complexity
- Performance implications
- Maintenance burden
- Ecosystem alignment
Action Items
- Gather data on how users are actually using/extending MCP servers
- Prototype a standalone version to understand the interface requirements
- Compare resource usage and performance characteristics
- Document decision with rationale
References
- Original PR: feat: Add an MCP server to the running node #595
- Discussion thread: feat: Add an MCP server to the running node #595 (comment)