Show HN: emcee – connect agents to APIs (via MCP) | Hacker News Reader

Show HN: emcee – connect agents to APIs (via MCP)

github.com

6 pointscarlpeaslee6 comments

Hi! Mattt and I thought it would be cool (and maybe even useful) if you could easily connect Claude to any API. Well, actually we thought it would be cool if we could order pizza and shitpost directly from our AI-powered IDE.

So we made emcee.

emcee takes a remote (OpenAPI documented) API, generates an MCP server, and exposes the API methods to your agent (or other MCP client) as tools.

The easiest way to try it out is with the Claude desktop app (directions on GitHub).

We think emcee is actually pretty helpful in a startup/SaaS context as an interface to your internal admin APIs. It also provides an easy way to connect realtime data to Claude.

Let us know what you think!

Open articleView on HN

Really interesting project

How are you using emcee?

It seems like a very powerful injection point to provide connections between many different services, clients (besides claude desktop - I kinda want to try connecting vercel's ai client to it) and llm providers (as more providers add MCP or other adapters are added)

Mattt here, co-creator of emcee.

Carl and I are working on a PaaS for deploying agents, and emcee has given us a nice way to quickly prototype these kinds of workflows.

We can take a handful of OpenAPI specs for code deployed on our platform, and have Claude calling tools without any extra setup. That's been really helpful for figuring out how to get the LLM to pick the right tool for the job.

It's also been interesting to see just how far you can get with tool calling on its own. Normally, you have to write some kind of UI or client code to interact with a platform. But with emcee, we've been able to take a tool-driven development approach, using Huma [1] to generate OpenAPI endpoints for our Go web API, and talking to our service first through Claude, before making a UI or SDK.

And to your point, I think MCP could be really powerful as a connection point to various clients, servers, and hosts — a lot like LSP [2] for IDEs and programming languages. I'd love to hook emcee up to Zed, for example, to give the AI assistant even more context to do its thing.

[1]: https://huma.rocks [2]: https://microsoft.github.io/language-server-protocol/

This is awesome. Could this integrate with RapidAPI's list of public API's that use the OpenAPI spec? https://rapidapi.com/collection/list-of-free-apis

Thanks! That's a super helpful list of compatible endpoints. One thing we've discovered is that sometimes it can be a bit of a pain to find the right API, find the OpenAPI schema URL, and then figure out the right auth / get a token. We're thinking through how to make that discovery process easier.

Another related issue we've seen is that sometimes a service will expose hundreds of endpoints... and you really only need a couple of them. Is there a better way to manage that?

So yeah, tool discovery and authentication are two things we're definitely trying to improve upon.

played around a bit with emcee and really impressed. giving claude access to APIs and having it just work is really satisfying.

what are next steps?

Mattt here, co-creator of emcee.

Thanks! Yeah, having everything just work gives me the same goosebumps that I remember from back in the Web 2.0 days.

One of the next steps for us is to expand emcee beyond just tool use. MCP has concepts [1] for prompts and resources (files, db records, etc.), and it'd be great to support those, too. Right now, emcee creates a 1:1 correspondence between OpenAPI operations and tools, but there should be heuristics or annotations to establish that, say, `GET /prompts/{id}` manages a prompt.

[1]: https://modelcontextprotocol.io/docs/concepts/architecture

Reply on news.ycombinator.com