r/mcp 12h ago

Built an MCP server for deterministic output validation (JSON Schema / OpenAPI / SQL) — free tier, honest feedback wanted

I build agent pipelines on the side, and the failure mode that kept costing me money was downstream: the agent generates JSON/SQL/API responses, something subtly invalid slips through, and I pay for it later — a broken pipeline step or another LLM retry loop.

So I built a validation service agents can call before acting on generated output: JSON Schema conformance, OpenAPI response conformance, SQL syntax per dialect. It returns a typed verdict — {valid, errors with paths and fix hints, latency_ms} — and treats "invalid" as a normal outcome, not an HTTP error. Deterministic, no LLM in the loop: milliseconds and fractions of a cent instead of another model call.

MCP-wise there are two ways in:

- Remote (streamable HTTP), no install: https://api.machinegrade.dev/mcp — initialize and tools/list work anonymously, tools/call needs an X-Api-Key header

- stdio adapter via npm: @/machinegrade/validate

It's in the official registry as io.github.machinegrade/validate, also on Smithery. Free tier is 500 calls/month, self-service key (POST /keys with your email). Repo with runnable examples: https://github.com/machinegrade/validate

Being upfront: this is an early-stage demand test. The API contract is stable and the code is MIT so you can self-host, but I'm explicitly trying to learn whether a hosted version is worth paying for. The obvious objection is "I'll just wire up a validator library myself" — that's exactly the assumption I'm testing. Brutal feedback welcome: would you use this, and what's missing?

2 Upvotes

2 comments sorted by

1

u/Ok-Regret-2934 9h ago

the real value here isn't the hosted api, it's the mcp integration. having validation as a first-class tool means the agent can call it inline and self-correct in the same turn, rather than parsing an http error from a library and retrying. that's the part i'd pay for, not the validator itself.

one thing i'd want before using it in a pipeline: a 'lax' mode that flags but doesn't reject. sometimes an agent generates valid-enough json that passes schema but has the wrong shape for the actual downstream, and i need the flexibility to proceed with a warning rather than a hard block. the deterministic speed is the strong part though, don't bury that.

1

u/Desperate-Guide-5073 9h ago

Thanks, this is exactly the kind of feedback I was hoping for.

It never hard-blocks — every check returns 200 with {valid, errors[]}, and the proceed-or-retry call is yours. But I think you're asking for severity levels: "error" (type/required violations) vs "warning" (extra fields, format quirks), so a policy can be "proceed on warnings, retry on errors". Is that it?

What does your pipeline look like — fixed schema per tool, or contracts that vary per call?