Lunar.dev: an MCP gateway and API proxy for governing agent traffic

The problem Lunar.dev targets: unmanaged outbound API and MCP traffic

Applications and AI agents call external services constantly, and those calls are usually invisible. The root README frames the gap directly: as agents and autonomous workflows lean on external APIs, there is a need for a mediation layer that acts as a central aggregation point between applications, agents, and the services they depend on. Lunar.dev is that layer. It is aimed at teams running agent workloads that reach multiple APIs and multiple MCP servers, where nobody can currently answer how much a given agent costs, which tools it calls, or what happens when one upstream API starts failing. The README lists five things the platform is meant to deliver: live traffic visibility across outbound calls including LLM and agent calls, AI-aware policy enforcement to control tool access and throttle agent actions, traffic shaping with rate limits, retries, priority queues and circuit breakers, cost and performance optimization, and centralized MCP aggregation that consolidates several MCP servers into one gateway. Note the audience. This is infrastructure for teams that already have outbound traffic worth governing. A single script calling one API does not need a gateway in front of it.

Two components, two jobs: proxy/ and mcpx/

The repository is split into two products that can be adopted separately or together. The README calls Lunar Proxy the core API gateway and control layer, and Lunar MCPX a zero-code aggregator for multiple MCP servers with unified API access. The top-level layout matches that description: proxy/ and mcpx/ sit side by side, next to interceptors/, example-consumer-app/ and readme-files/. The interesting architectural claim is the word aggregator. Instead of registering each MCP server with each client, you point clients at one endpoint and MCPX fans out to the servers behind it. The README says this consolidation improves security, observability and management, which is the standard argument for a gateway and also its main cost: the gateway becomes a component that can fail. The root README does not describe the data flow inside MCPX, the protocol version it speaks, or how it handles a server that stops responding. That detail lives in mcpx/README.md, which the root file links to but does not reproduce.

Installing Lunar.dev and running a first gateway

The root README does not contain install commands. It points to two component READMEs, so the honest first step is to read the one that matches your use case: proxy/README.md for the API gateway, mcpx/README.md for MCP aggregation. From the repository layout, both are TypeScript projects with their own directories, and the root lists an example-consumer-app/ directory that the README does not discuss, which is likely the fastest way to see a working setup. Start by cloning the repository and looking at what each component ships.

git clone https://github.com/TheLunarCompany/lunar.git
cd lunar
ls proxy mcpx example-consumer-app

The listing tells you which of the three directories contains a README with run instructions. Because the root README gives no package manager, no start script and no port, do not guess one. Open proxy/README.md or mcpx/README.md and follow the steps printed there. The README does state the licensing position for self-hosting: the project remains open-source at its core and free for non-production and personal use, while production environments get advanced features through guided onboarding and platform tiers. That sentence matters before you install anything, because it defines where the free path ends.

Where Lunar.dev is the wrong tool

The clearest limitation is stated by the project itself. The README says the open source core is free for non-production and personal use, and that production environments get advanced features through guided onboarding and platform tiers. So a team that wants a fully self-supported production gateway with every feature enabled should treat this as a commercial conversation, not a pure open source install. The second limitation is structural. A gateway that aggregates MCP servers is a single point of failure and a single point of latency for every tool call an agent makes. The README claims reliability benefits from circuit breakers and retries, but those mechanisms protect upstream services; they do not remove the extra hop the gateway adds. Third, the release history is worth reading carefully. The most recent release listed is lunar-proxy-v0.9.2 from 2024-03-21, and the repository's last push was 2026-09-10. Those two facts are not contradictory, since work can land on main without a tagged release, but it does mean the published release line has not moved in a long time and anyone pinning to a tagged version should check what it contains. Finally, if you run one MCP server for one developer, an aggregator adds a component without adding value.

How it compares with putting a general-purpose proxy in front

The obvious alternative is a conventional reverse proxy or API gateway that you already run, configured to sit in front of your MCP servers and third-party APIs. The difference in approach is what the gateway understands. A general proxy routes on host, path and headers; it does not know what an MCP tool call is, so it cannot enforce tool-level access rules, and it cannot report token usage or attribute cost to an agent. Lunar.dev's stated design is AI-aware: the README describes controlling tool access, throttling agent actions and governing agentic traffic with fine-grained rules, plus metrics on latency, errors, cost and token usage across outbound traffic including LLM calls. That is the trade. You accept a TypeScript component with its own release cadence and a production tier behind it, in exchange for policy and metrics expressed in agent terms rather than HTTP terms. If your governance needs are ordinary rate limiting per API key, a general proxy is the smaller commitment.

Licence and the cost of staying current

The repository is MIT licensed, which permits commercial use, modification and redistribution of the code as published. The README adds a product-level distinction on top of the licence: open source at the core and free for non-production or personal use, with advanced features for production environments available through guided onboarding and platform tiers. Those two statements are not in conflict, but they mean different things, and the practical consequence is that the MIT grant covers what is in the repository while the production feature set may not be in it. Whether a given capability you need is in the open source tree is a question for the component READMEs, not the licence file. On maintenance cost: no upgrade guide appears in the repository root, and the root README does not document rollback or version pinning. The absence is itself the risk. Before deploying, check proxy/README.md and mcpx/README.md for a changelog or migration note, and decide how you will pin and revert a version. This is not legal advice; read the LICENSE file and the README's production terms yourself.

Editorial conclusion

Adopt Lunar.dev if you already run several MCP servers or outbound third-party APIs and want one place to observe and throttle that traffic; the MIT licence and the two separate components let you start with only the proxy. Skip it if you need one MCP server for a single developer, where a direct connection is simpler. Before committing, read proxy/README.md and mcpx/README.md in full, because the root README does not state which environment variables the gateway expects, what ports it binds, or how to roll back a configuration change.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. TheLunarCompany/lunar on GitHub