Every time I wanted an AI agent to call a real API, I ended up writing a small MCP server for it. Then I had to host it, handle auth, store secrets and redeploy it, all for what was often a single HTTP call.
Glxymesh is my attempt to remove that work. You describe the tool, and Glxymesh builds it, hosts it and gives your agents one authenticated endpoint.
How you create a tool
There are two ways.
1. Let it draft the tool for you. Point Glxymesh at an API's docs and it drafts the tool. You review it, approve which keys it can use, and publish.
2. Describe it yourself. Write the tool in a few lines of YAML. If it needs real logic, add a run function in Go, TypeScript or Python. Most tools that wrap an API don't need any code at all.
How you ship it
The CLI has three commands you'll use:
gxmesh init # start a project
gxmesh new # add a tool, then edit it in any editor
gxmesh push # build, test and put it live
Each tool runs in its own isolated AWS Lambda function. Secrets and access control are handled for you.
How your agents use it
You get one authenticated MCP endpoint for the whole project. Point Claude, ChatGPT or Gemini at it and every tool you've published is available.
Pricing
Pricing is flat with no overage billing:
- Free: 10 hosted tools
- Pro: $29/month, 250 tools
- Team: $79/month, 2,500 tools
I chose flat pricing on purpose. Per-request billing makes agent costs hard to predict, because you don't control how often an agent decides to call a tool.
Try it
It's live at glxymesh.com. It's early, and I'd love feedback in the comments, especially on two questions:
- Is YAML the right way to describe tools, or would you rather write code from the start?
- What would stop you from moving an MCP server you host yourself onto something like this?
Top comments (5)
YAML seems a reasonable default for thin wrappers if the approval screen shows the resolved HTTP method, destination and key scope, rather than making me infer them from the config. What would stop me moving is uncertainty about what happens to that approval after an update.
A useful fixture: publish a read-only tool approved for key A, then push a revision that changes the host or turns it into a write using the same key. Does that revision require fresh approval, and can the old revision continue serving until it's approved? A failed deployment should also leave a clear active version. I haven't tried Glxymesh; these are migration questions based on the review/key-approval/push flow in the post.
MCP server sprawl is a real pain — I’ve seen teams run a dozen tiny containers just to expose a handful of REST endpoints, each with its own auth, logging, and deployment pipeline. The operational tax adds up fast: health checks, secret rotation, version skew between the agent and the server, debugging why a tool call timed out because the sidecar crashed.
Curious how you’re handling a few things:
Auth propagation — when the agent calls a tool, does the gateway forward the original user’s credentials (OAuth token, API key) to the upstream API, or does it use a service account? The former is ideal for per-user data access but gets messy with token refresh and scopes.
Schema drift — if an upstream API changes its contract, how does that surface to the agent? Do you regenerate tool definitions on a schedule, or is there a webhook / CI step that pushes updates?
Observability — with multiple APIs behind one gateway, tracing a single agent request across hops (gateway → upstream → response) is critical. Are you emitting OpenTelemetry spans or relying on structured logs?
Rate limiting / quotas — different upstreams have wildly different limits. Do you enforce per-upstream policies at the gateway layer, or push that down to each MCP server?
The "one gateway, many tools" model makes sense if the gateway stays thin — routing, auth, observability — and doesn’t become a monolith that needs its own scaling strategy. Keen to see how the project evolves — found it via LabAgent, site: labagent .tech
Some comments may only be visible to logged-in visitors. Sign in to view all comments.