Feat: Switch MCP Server from HTTP to Stdio Protocol for Zero-Server Overhead

[jairandresdiazp]

Problem

The current Engram implementation as an MCP server relies on the HTTP protocol. This architecture introduces unnecessary complexity for the end user:

1. Process Management: The user must manually manage a running local server or ensure a background process is active.
2. Port Conflicts: Using HTTP requires a dedicated port (e.g., 8080), which can lead to conflicts with other local services.
3. Security/Firewall: Local HTTP servers can be blocked by corporate firewalls or require manual permissions.
4. Lifecycle Manual Handling: The server doesn't automatically start or stop with the AI client (Claude Desktop/IDE), leading to "Connection Refused" errors if the server isn't manually toggled.

Proposed solution

I propose migrating (or adding as the default) the MCP Stdio Protocol transport. Since Engram is a Go binary, it is perfectly suited to communicate via stdin/stdout.

Key changes and benefits:

• Lifecycle Autonomy: The AI Client (Claude Desktop) will spawn the Engram binary as a child process and kill it when the session ends. No "server" needs to be running in the background.
• Simplified Configuration: The claude_desktop_config.json entry becomes a simple path to the binary:

"mcpServers": {
  "engram": {
    "command": "/usr/local/bin/engram",
    "args": ["mcp-start"]
  }
}

• No Port Management: Eliminates the need for port allocation and firewall rules entirely.
• Standard Implementation: Leveraging the official [MCP Go SDK](https://github.com/metoro-io/mcp-golang) (or a custom Stdio wrapper) to handle JSON-RPC messages over standard streams.

Alternatives considered

• Maintaining HTTP-only: Requires keeping a persistent daemon running, which increases RAM usage and setup friction for the user.
• WebSockets: Similar to HTTP, it adds overhead and complexity that is overkill for a local persistent memory system.
• Docker-based MCP: Adds massive overhead (container engine) for what should be a simple binary communication.