A simplified implementation of the Model Context Protocol (MCP) server using Elixir's Phoenix Framework.
MCPheonix MCP server exists for a simple reason — assistants are far more useful when they can act on MCPheonix directly instead of describing what you should do. A simplified implementation of the Model Context Protocol (MCP) server using Elixir's Phoenix Framework.
MCP server built on Phoenix Framework (Elixir). Exposes Server-Sent Events and JSON-RPC endpoints for MCP clients, with support for managing multiple child MCP servers through JSON configuration.
Setup follows the usual MCP pattern — install or clone the server, register it in your client's configuration file, restart the client.
Once MCPheonix is connected, these are the calls the assistant has available:
Area — StateTransport — HTTP (SSE + JSON-RPC)Framework — Phoenix 1.7, Elixir >= 1.14, Erlang >= 25Tests — ExUnit, 2 test files (Cloudflare DO client, mock websocket)Dependency — VersionElixir — >= 1.14Phoenix — ~> 1.7.0Node.js — >= 18 (for child MCP servers)Integration — What's NeededEndpoint — MethodPackage — Versionphoenix — ~> 1.7.0You will need 6 environment variables: API_KEY, BFL_API_KEY, DART_TOKEN, CLOUDFLARE_WORKER_URL, CLOUDFLARE_ACCOUNT_ID, CLOUDFLARE_API_TOKEN. The server will not start without them, which is usually why the tools fail to appear on a first run. Keep credentials in your client's env block or a secrets manager rather than in a file you might commit.
| Dependency | Version | |-----------|---------| | Elixir | >= 1.14 | | Erlang/OTP | >= 25 | | Phoenix | ~> 1.7.0 | | Node.js | >= 18 (for child MCP servers) | | Python | >= 3.9 (for Flux/Dart integration) |
This sits in the cloud and infrastructure group, where several servers overlap in what they claim to do but differ sharply once you actually set them up. MCPheonix's toolset — Area, Transport, Framework and 11 more — is a fair guide to whether it matches your workflow. It is maintained by jmanhype; worth a glance at recent repository activity before you build anything load-bearing on it.
This entry was verified against MCPheonix's own documentation before publication; SyncDev keeps the directory reviewed rather than auto-generated.
| Tool | What it does |
|---|---|
| Area | State |
| Transport | HTTP (SSE + JSON-RPC) |
| Framework | Phoenix 1.7, Elixir >= 1.14, Erlang >= 25 |
| Tests | ExUnit, 2 test files (Cloudflare DO client, mock websocket) |
| Dependency | Version |
| Elixir | >= 1.14 |
| Phoenix | ~> 1.7.0 |
| Node.js | >= 18 (for child MCP servers) |
| Integration | What's Needed |
| Endpoint | Method |
| Package | Version |
| phoenix | ~> 1.7.0 |
| phoenix_live_view | ~> 0.19.0 |
| ash | ~> 2.9 |
| Dependency | Version | |-----------|---------| | Elixir | >= 1.14 | | Erlang/OTP | >= 25 | | Phoenix | ~> 1.7.0 | | Node.js | >= 18 (for child MCP servers) | | Python | >= 3.9 (for Flux/Dart integration) |
| Variable | Description | Required |
|---|---|---|
| API_KEY | Credential the server authenticates with. | Yes |
| BFL_API_KEY | Credential the server authenticates with. | Yes |
| DART_TOKEN | Credential the server authenticates with. | Yes |
| CLOUDFLARE_WORKER_URL | Endpoint or connection string the server talks to. | Yes |
| CLOUDFLARE_ACCOUNT_ID | Configuration value read at startup. | Optional |
| CLOUDFLARE_API_TOKEN | Credential the server authenticates with. | Yes |
Manage your whole Supabase project in conversation — database, auth, storage, Edge Functions and branches.
Stop letting your assistant hallucinate n8n node parameters — this server hands it the real schemas, templates and validation.
AWS Labs' official server suite — current AWS docs, CDK guidance, cost analysis and service tools.
Cloud browsers for AI agents — automation sessions that run in Browserbase's fleet, not on your machine.
Workers, KV, R2 and D1 by conversation — Cloudflare's official remote servers for building and observability.
Dashboards, Prometheus and Loki queries, incidents and alerts — observability by conversation.