Your AI can think. Now let it act: meet Glxymesh

Abhishek Mourya — Wed, 14 Oct 2026 11:45:23 +0000

Cold open: 2:07 AM

The coffee went cold an hour ago.

On one monitor, an AI model that can draft a product spec, refactor a module, and explain quantum tunnelling in the voice of a pirate. On the other, a terminal bleeding red:

401 Unauthorized
x509: certificate has expired or is not yet valid

All you wanted was one sentence to work:

"Get the latest issues from my GitHub repository."

The tool itself? A few lines. But to let an AI client actually run it, you need an MCP server. HTTPS in front of it. OAuth so clients can sign in. A safe place for the GitHub token. And a long night of chasing certificates and 401s every time something drifts.

The tool is a few lines. The plumbing around it is the whole project.

That's the night Glxymesh was built to end.

Act I: Say it out loud

Open the console. Find the Builder. Describe the tool you need, like you'd explain it to a teammate, and if you like, drop in a link to the API's docs.

Then watch.

Glxymesh reads the docs. Plans the tool. Writes it. Tests it. Every step plays out in front of you, and most builds wrap in a minute or two.

Most tools turn out to be a single request described in YAML. No code at all.

Prefer to write the script yourself? A tool is just a tool.yml, plus one run function in Go, TypeScript or Python when it needs real logic. The MCP server tutorial walks that path with the gxmesh CLI.

Act II: The one door only you can open

Here's the twist most AI-builds-your-code stories skip.

The AI that writes your tool cannot give it network access. It cannot hand it keys. It cannot publish.

Every draft arrives with its intentions on the table: these are the hosts I'll call; these are the keys I'll need. You allow each host. You add each key to the project's vault. Then the draft's tests run on a preview, with only what you allowed and nothing more. When they pass, you hit publish.

And the keys? They never touch the code. The egress gateway attaches each key to calls bound for its own host, on the way out the door, so neither the tool nor the AI client calling it ever holds it. The agent that wrote the tool never even sees it.

(The full story: Keeping API keys out of your tool code.)

Act III: One address, every AI

Every Glxymesh project is one MCP server with one address.

Claude. ChatGPT. Cursor. VS Code. They all connect over Streamable HTTP and sign in with OAuth 2.1, so there are no API keys to pass around in Slack DMs. Every tool in the project answers from that single endpoint.

Back to 2:07 AM. You ask your AI the same question from the opening scene.

This time, it answers.

Curious what happens the first time a client knocks? Connecting MCP servers to AI clients walks through it.

Behind the scenes: built in from the first call

Built in	What it does
🔐 Sign-in	Each client signs in to the project with OAuth 2.1
🌐 Network	A tool reaches only the hosts you allowed
🗝️ Secrets	Encrypted in the project's vault and added at egress
🎞️ Traces	Every call recorded with its outcome and timing

Want the director's commentary? How a request moves through Glxymesh follows one call through every layer, and Reading your invocation history shows what the traces tell you.

Roll credits

Your AI can already think. Now let it act.

Spend less time babysitting infrastructure and more on what your AI does next. Start building free · see the pricing page for what the free plan includes.

Questions? Drop them in the comments, or write to support@glxymesh.com.

Originally published on the Glxymesh blog.

I got tired of hosting tiny MCP servers, so I built Glxymesh

Abhishek Mourya — Thu, 08 Oct 2026 17:04:24 +0000

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?

DEV Community: Abhishek Mourya