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 (3)
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.
You need to complete account verification.Link in the profile.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.