You have a REST API.
AI agents still can't call it.
Agents don't speak REST — they call MCP tools. Merlonix reads your OpenAPI 3.x or Swagger 2.0 spec and generates a runnable MCP server: tool definitions, a .well-known/mcp.jsonmanifest, and a Node (stdio) server built on the official MCP SDK that proxies calls to your real API. Then it grades the result A–F for agent-safety, led by a tool-poisoning check — because an agent trusts your tool descriptions verbatim. Once the server is live, Merlonix monitors it with a real MCP handshake for downtime and silent tool-schema drift.
No credit card either way — start free, or trial the full workspace.
- Outputs: tools + manifest + server
- 3
- Agent-safety grade
- A–F
- Scan leads the grade
- Poisoning
- Converter + one-shot monitor check
- $0
Where a REST API without an MCP server loses agents
Three ways an undocumented-to-agents API stays invisible: no MCP server at all, a hand-rolled one with a hidden tool-poisoning risk, and a tool surface too large — or too write-heavy — for an agent to use safely.
Your OpenAPI spec already describes every endpoint, parameter, and auth scheme your API supports. Turning that into something an agent can call, safely, is a separate step — one most API teams haven't taken yet, and one a naive converter can get wrong in ways that only surface once an agent is already calling the server.
No MCP server, no agents
Your API is fully documented in OpenAPI — and completely invisible to AI agents
Agents don’t call REST endpoints. They call MCP (Model Context Protocol) tools: named, described, JSON-Schema-typed operations an agent can discover and invoke. If you have a REST API with an OpenAPI spec but no MCP server sitting in front of it, every agent-based integration your customers try to build simply can’t happen — not because your API is bad, but because there’s no adapter translating your endpoints into the shape an agent understands. You already wrote the spec that describes every operation, parameter, and auth scheme; that work is sitting unused.
Tool poisoning hides in your own docs
A hand-rolled MCP wrapper can smuggle a prompt injection straight from your OpenAPI summary field
An agent reads a tool’s name and description verbatim before deciding whether to call it — and before deciding what to do with the result. If an OpenAPI `summary` field (yours, a vendor’s, or a compromised upstream) contains a hidden instruction — "ignore previous instructions," a request to read `.env`, an `<important>` block, invisible zero-width text — a naive converter ships it straight into the tool description an agent trusts. A generator that only checks "does this parse" will hand you a working MCP server with a poisoned tool inside it, and you won’t know until an agent does something it shouldn’t.
Too many tools, no eyes on write access
Every endpoint becomes a tool, agent tool-selection degrades, and nobody flagged the DELETE calls
The naive move is to convert every operation in your spec into a tool. Past roughly 40–50 tools, an agent’s ability to pick the right one degrades sharply — you’ve built a server agents can’t use well, not one they can. Worse, a straight conversion doesn’t tell you which of those tools can modify data (POST/PUT/PATCH/DELETE), which inputs are left untyped because a `$ref` didn’t resolve, or which operations are missing a description an agent needs to choose correctly. You need that flagged before you hand the server to an agent, not after.
How it works
Generate an MCP server from your OpenAPI spec, validate it for agent-safety before you ship it, then monitor the live server the way you'd monitor an API.
Merlonix covers the full lifecycle: convert your spec into a runnable MCP server, grade it A–F with a tool-poisoning check leading the score, and — once it's live — watch it with a real MCP handshake for downtime, latency, and silent tool-schema drift.
01
Paste your OpenAPI spec or give us a URL — get a runnable MCP server back
Give the free converter your OpenAPI 3.x or Swagger 2.0 spec as JSON (paste it, or a URL we fetch, SSRF-guarded, 2 MB cap). The transform is deterministic and nothing is stored server-side: each operation’s operationId becomes a tool name, its summary becomes the tool description, its parameters and requestBody become a JSON-Schema inputSchema (with $ref inlining and path-level parameter merging), and its security scheme becomes an auth binding. You get three things back: the MCP tool definitions, a .well-known/mcp.json manifest, and a runnable Node (stdio) MCP server built on the official @modelcontextprotocol/sdk that proxies calls to your real REST API. Download it, set your API base URL and an optional API key, and connect it to your MCP client today.
02
Get an A–F agent-readiness grade before you ship the server anywhere
The same conversion is graded across seven dimensions, led by a tool-poisoning check: we scan every generated tool’s name and description for injection patterns — hidden instructions, requests to read secrets, suspicious block markup, invisible text — and a poisoning flag caps the grade so an unsafe server never reads as ready. The grade also weighs auth posture (no auth vs. static API keys vs. OAuth 2.1), how many tools can write data, how many inputs are left untyped, and whether your tool surface is small enough for an agent to choose well — the generator caps output at 100 tools and warns when your API is over the limit where agent tool-selection degrades. Missing descriptions and write operations are flagged for review.
03
Ship the smallest useful tool surface, not every endpoint you have
Use the grade to trim before you deploy: expose the highest-value read and action operations an agent actually needs, not a 1:1 mirror of your whole API. Fewer, well-described, correctly-typed tools is a better agent experience than a complete-but-unwieldy one — and it’s a smaller surface for a tool-poisoning scan or an auth misconfiguration to hide in. JSON specs are supported today; if your spec is YAML, export or convert it to JSON first.
04
Once it’s live, monitor the MCP server the same way you’d monitor an API
Generating and grading the server is a point-in-time check. Once you’re running it, Merlonix’s MCP-server health monitor runs a real MCP handshake — the JSON-RPC initialize call plus tools/list — against your live endpoint on a schedule, and alerts on downtime, a failed handshake, latency regression, or silent tool-schema drift: a tool added or removed, or an input schema that changed — the breaking change that quietly kills every agent calling it. Run the free one-shot check first at /tools/mcp-health/; continuous monitoring is on a paid plan.
What generate → validate → monitor actually gives an API team
Built for teams that own the API, not just the MCP wrapper — so the spec you already maintain becomes the agent-callable surface, checked for the failure mode that’s specific to agents before it ever ships.
A converter alone tells you your spec parses. A grade tells you whether the server it produced is safe to hand to an agent. Continuous monitoring tells you the moment the live server stops behaving like the one you graded.
Generate
Your OpenAPI 3.x or Swagger 2.0 spec becomes MCP tool definitions, a .well-known/mcp.json manifest, and a runnable Node (stdio) MCP server on the official @modelcontextprotocol/sdk — deterministic, nothing stored.
Validate
A tool-poisoning-led A–F grade checks every tool name and description for injection patterns, plus auth posture, write-operation count, untyped inputs, and tool-surface size — before you ship the server anywhere.
Monitor
Once the MCP server is live, Merlonix runs the real JSON-RPC initialize handshake and tools/list on a schedule and alerts on downtime, failed handshakes, latency, or silent tool-schema drift.
13/13
Merlonix ran its own /v1/openapi.json (13 paths) through the converter and got 23 correctly-named MCP tools — listAssets, createAsset, getAsset, and more — with all 13 write operations correctly flagged.
Pricing
Flat monthly fee once your MCP server is live. Every endpoint — prod, staging, per-region — and its TLS, DNS, and uptime included.
The converter and the agent-readiness grade are free, no signup, for any OpenAPI spec. Monitoring the live MCP server is a paid tier — pick the one that fits how many endpoints you operate.
Starter
For a small API team standing up its first MCP server, who wants downtime, failed-handshake, and tool-drift alerts on that one endpoint alongside its TLS and DNS.
$19/ month
- 15 monitored assets
- 3 seats
- 5 min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Team
For an API company running MCP servers across prod, staging, and per-region environments that need fast checks, latency tracking, and drift alerts on every tool contract they expose.
$79/ month
- 60 monitored assets
- 10 seats
- 1 min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Agency
For a platform team exposing many APIs as MCP servers across customers or business units, with unlimited seats and one correlated alert path for MCP health, TLS, DNS, and uptime together.
$199/ month
- 250 monitored assets
- Unlimited seats
- 1 min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Compliance
For regulated-vertical teams that need continuous, audit-ready evidence.
$699/ month
- 500 monitored assets
- Unlimited seats
- 1 min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Beyond uptime
More than a 200 OK on every client site
The same account also watches the infrastructure and reputation layers a standard uptime check never reaches — each a live check you can turn on.
Turn monitoring into revenue
Resell client-ready reports as your own
Monitoring doesn’t have to be a cost line. Package the branded report and white-label status page as a deliverable in your retainer — the tooling underneath stays invisible, so to the client the work is yours.
Reports under your brand
Hand each client a polished SSL, DNS, and security report carrying your agency’s name and logo — not ours.
Status pages on their domain
Publish a live status page at status.theirbrand.com with automatic TLS and no “Powered by Merlonix” badge.
Your margin to keep
You pay one add-on cost and package it into the retainer you already bill. The markup — and the margin — are yours.
Common questions
Frequently asked questions
Do I need DNS or registrar access to my clients’ domains to monitor them?
No. Merlonix monitors from the outside in — it probes each domain’s public SSL certificate, DNS records, WHOIS/registration data, and HTTP responses the same way a browser or DNS resolver would. You add an asset by its hostname; no access to the client’s registrar, DNS provider, or servers is required.
What does Merlonix actually check on each site?
Every monitored asset gets continuous SSL-certificate (expiry, issuer, and chain changes), DNS-record, domain-registration/expiry, and uptime monitoring by default. You can also enable infrastructure and reputation checks a standard uptime monitor never reaches — security headers, DNSSEC/DANE, domain-hijack/registrar-lock, blocklist, and cron/heartbeat monitoring — each a live check you turn on per asset.
How often does it check, and how do alerts reach me?
Checks run on your plan’s cadence — as often as every 1 min on Team and above, and every 5 min on Starter. When a certificate, DNS record, registration, or response changes, you get an alert by email and Slack. Alerts fire on real state changes between definitive checks, not on a transient blip.
How much does it cost, and is there a free option?
Yes — there is a free $0 plan (no credit card) to watch a small number of assets, and paid plans start at $19/mo (Starter). You can also start a 14-day full-workspace trial with no card. See the pricing grid above for the assets, seats, and check cadence on each tier.
Your spec already describes the API. See what it looks like as an MCP server.
Paste your OpenAPI or Swagger spec and get the tool definitions, manifest, runnable server, and agent-safety grade back in seconds. No credit card, nothing stored.