What problem are you trying to solve?
Users want to bring their own agent harness while consuming the capabilities authored in an eve agent. Today there is no native MCP server surface for reading compiled instructions and skills or invoking eligible eve tools. Reimplementing this in a custom channel would duplicate compiler projection, auth, tool execution, sandbox, and deployment behavior.
The first version should stay intentionally constrained: expose static instructions, complete static skill packages, and static executable tools from the root and recursively nested local subagents. Remote subagents must never be exposed.
Proposed solution
Add an explicit mcpChannel() mounted at /mcp using stateless Streamable HTTP. Project compiled instructions and skill files as MCP resources and eligible executable tools as MCP tools, with local subagent paths mapped into deterministic namespaces.
Direct tool calls should use normal eve validation, approval, authorization, output projection, and owning-node sandbox/skill behavior without creating a model run or durable eve session. An optional onRequest hook should let applications project harness session metadata and effective auth into tool context while keeping internal execution and sandbox identity private and call-scoped. The channel should expose defaultMcpAuth() to preserve the admitted route caller, consistent with other eve channels.
The accompanying research plan defines the public API, MCP protocol mapping, execution boundary, sandbox lifecycle, packaging, security constraints, and verification strategy.
Alternatives considered
- Build a standalone MCP server beside eve. This loses eve compiler/runtime guarantees and duplicates deployment plumbing.
- Route every MCP operation through a durable eve model session. This adds model turns, history, and lifecycle semantics that external harnesses do not need.
- Expose only instruction and skill resources forever. Static reads are a useful first boundary, but direct invocation of eligible authored tools is the important follow-on capability and should fit the initial design.
What problem are you trying to solve?
Users want to bring their own agent harness while consuming the capabilities authored in an eve agent. Today there is no native MCP server surface for reading compiled instructions and skills or invoking eligible eve tools. Reimplementing this in a custom channel would duplicate compiler projection, auth, tool execution, sandbox, and deployment behavior.
The first version should stay intentionally constrained: expose static instructions, complete static skill packages, and static executable tools from the root and recursively nested local subagents. Remote subagents must never be exposed.
Proposed solution
Add an explicit
mcpChannel()mounted at/mcpusing stateless Streamable HTTP. Project compiled instructions and skill files as MCP resources and eligible executable tools as MCP tools, with local subagent paths mapped into deterministic namespaces.Direct tool calls should use normal eve validation, approval, authorization, output projection, and owning-node sandbox/skill behavior without creating a model run or durable eve session. An optional
onRequesthook should let applications project harness session metadata and effective auth into tool context while keeping internal execution and sandbox identity private and call-scoped. The channel should exposedefaultMcpAuth()to preserve the admitted route caller, consistent with other eve channels.The accompanying research plan defines the public API, MCP protocol mapping, execution boundary, sandbox lifecycle, packaging, security constraints, and verification strategy.
Alternatives considered