Tiny update: The EMCP server now supports Prompts, Resources, and ResourceTemplates . You probably won’t use them because e.g. Claude Code doesn’t expose these functions to you, only Tools. Still, with these new features in place, the MCP server is now feature-complete

This is great! Thanks for building it. It’s a much nicer, simpler implementation than other libraries I’ve seen and looks like it will be easy to extend and maintain. A couple of thoughts for feedback:

1. A pluggable session store would be great - many Elixir deployments can’t use clustering, so can’t rely on ETS.
2. It would be nice to have all the config for the server in its own module, rather than global config. This would allow multiple MCP servers to coexist, for example. Perhaps it could use the Ecto Repo pattern of use EMCP.Server, tools: [...] ?

(I might even get a chance to submit a PR for these…)

Certainly!

1. you can use ETS without clustering and as far as I know ETS tables are always per-node and not clustered. For a clustered ETS alternative we’d need to use Mnesia. But which session store would you like to use?
2. Sure, that’s actually a good idea! I’ll look into that refactoring in a few days unless you wanna send a PR before that

We use Redis for session storage in our Phoenix app. I’m imagining the library continues to use ETS out of the box, but there’s a defined behaviour that we can implement and swap in, or contribute to the project.

I was also wondering if you had any thoughts about accessing session/connection information in a tool, such as letting an upstream plug assign a user from an auth header, which is then made available to a tool call?

Ah okay, yes that shouldn’t be too hard to make the session store a behaviour

And for the tools, I could pass the conn into the tool. That way you can assign the user upstream based on e.g. an api key header and reuse it in the tool. How does that sound?

Yeah, I think that’d be great!

Candidly, I would expect the session to have an open-ended (user defined) state that would be passed to the tool. If I choose to assign the Conn to the session state then I would have it available. But passing in the Conn explicitly to the tool would be a bit awkward IMO.

I’m thinking of session state as being similar to GenServer state and the tool call being similar to a handle_call. This is an approach we’ve taken in a proprietary MCP server library and it’s worked well.

BTW, it’s great that you’ve published this. I think it fills a gap in the ecosystem because Tidewave is designed for a specific purpose and Anubis was a steep learning curve for me. Kudos and I wish you luck. I hope to become a user of EMCP one day when the need arises.

Release v0.3.0

I implemented your feedback and made a bunch of breaking changes, so please read the Changelog when updating.

In essence, these are the changes:

• Replace global config with per-server pattern (use EMCP.Server, config_here)
• Pass the conn into all Tool/Prompt/Resource/ResourceTemplate callbacks.
  • This way, you can assign the current_user and use it in the Tool
• Make the SessionStore pluggable. It uses EMCP.SessionStore.ETSby default but you can replace it with your own strategies. Just implement the EMCP.SessionStorebehaviour.
  • I made the SessionStore not per-server since you really only need one, but if you want to have multiple session stores, you can always create two modules (e.g. Store1, Store2) and pass them to each server with session_store: Store1 and session_store: Store2

Please let me know what you think! I’m slowly converging on a stable API, but I’m using EMCP for pretty simple use-cases, so if your edge case isn’t supported (well), please let me know!

Looks interesting. How does this compare to Ash Framework’s UsageRules and Tidewave MCP?

Edit to add: I’m using UsageRules and Tidewave now and want to be sure of where EMCP would fit into my workflow before implementing it.

According to Claude Code:

emcp is an Elixir MCP server library — it lets your Phoenix/Ash apps expose tools, resources, and prompts to AI clients like Claude Code. Your workflow already uses Tidewave for runtime introspection, but emcp serves a different purpose: it lets you define custom domain-specific tools that Claude Code can call.

The killer combination: Tidewave gives Claude eyes into your app; emcp gives Claude hands.

This sounds interesting but I’d also be curious about context window hit. My understanding is that in many cases skills can be better than MCP because skills generally require less context/fewer tokens to use.

Keen to get some folks’ thoughts on this and potential trade-offs. Thanks!

Basically, you can think of the (E)MCP server as a loose API for your LLM. The Tidewave MCP for example uses it to get your logs or fetch files from your codebase. But AFAIK you can’t extend it. With EMCP you can write these Tools (API endpoints) yourself. So, think API endpoint but specifically for LLMs.