EONYX and MCP: connecting external tools

Model Context Protocol (MCP) is an open standard through which an agent gains access to external systems: databases, APIs, issue trackers and any other services. EONYX has a built-in MCP client based on the official Go SDK (modelcontextprotocol/go-sdk) — servers are described right in eonyx.json and their tools show up for the model alongside the built-in ones.

1 Setup

Connecting an MCP server takes two steps: describe it in the config and grant access to its tools. And for one common case MCP is not needed at all — we will cover that too.

1.1 Configuration

MCP servers are described in the mcp array of the config. There is no separate “type” field — the transport is inferred from the fields: if there is a url it is HTTP, if there is a command it is stdio.

"mcp": [
  {
    "name": "github",
    "command": "npx",
    "args": ["-y", "@modelcontextprotocol/server-github"],
    "env": { "GITHUB_TOKEN": "ghp_..." }
  }
]

"mcp": [
  {
    "name": "tracker",
    "url": "https://mcp.example.com/sse",
    "headers": { "Authorization": "Bearer $TRACKER_TOKEN" }
  }
]

Server fields:

1.2 Permissions

MCP tools are not on the always-allowed list — on the first call EONYX shows an Allow once / Allow always / Deny dialog, just like for any writing tool. So that a trusted tool does not ask every time:

"permissions": {
  "allowed_tools": ["github_search_issues", "tracker_get_task"]
}

1.3 When MCP is not needed

For one common case MCP is not required: EONYX has built-in read-only reporting tools for PostgreSQL. It is enough to set the connection string:

"report": { "database_url": "$DATABASE_URL" }

Leave it empty and the tools are not registered at all; that is the off switch.

2 What the model gets

Once connected, the server’s tools line up alongside the built-in ones. Here is exactly what the model receives.

2.1 Tools

Every tool of a server is registered under the name <server>_<tool>: on the github server the search_issues tool becomes github_search_issues. The argument schema is taken from the server as is, and the result is returned to the model as text.

The path of a single call

sequenceDiagram
    participant M as Model
    participant P as EONYX
    participant S as MCP server
    participant E as External system
    M->>P: github_search_issues call
    P->>S: request over stdio / HTTP
    S->>E: call to the API or database
    E-->>S: data
    S-->>P: result
    P-->>M: result as text

Connecting servers at startup

sequenceDiagram
    participant P as EONYX
    participant A as github server
    participant B as tracker server
    P->>A: connect at startup
    A-->>P: tools registered
    P->>B: connect at startup
    B--xP: server unavailable
    Note over P,B: warning: mcp — skipped
    Note over P: startup continues without it

Connecting is best-effort: working servers register their tools, a failing one is cut off with a warning, and EONYX starts in any case.

2.2 Resources and prompts

If the server declares the corresponding capabilities (EONYX checks this during registration), these appear as well:

Binary resources are not dumped into the context: instead of the content the model sees the marker (binary resource <uri>, N bytes).

2.3 Managing servers on the fly

Active servers are visible in the TUI header — the » mcp segment. Ctrl+K opens the capabilities dialog (Skills / MCP tabs): any server can be turned off and on right in the session — its tools are hidden from the model and stop being called, with no restart and no config edits. The ✓/✗ marks show the state.

3 Summary