Vouqis
Know if your MCP server actually works
Start new thread

Vouqis - Know if your MCP server actually works

by•
Vouqis audits MCP servers before they reach production. One CLI command tests every tool call, measures latency, surfaces errors, and logs 90 days of trace history — with replay built in. Ship AI agents knowing your MCP layer is actually safe.

Add a comment

Replies

Best
Maker
📌
Hey PH! I built Vouqis because I kept seeing MCP servers fail in production in ways that were completely invisible to standard monitoring. HTTP 200, no errors in logs — but the server was silently accepting malformed JSON-RPC requests it should have rejected, or timing out on tools 3 and 4 in a 5-tool chain. The math is brutal: if each MCP tool has 71% reliability, a 5-tool chain succeeds only 18% of the time. You need to know your server's actual protocol-level reliability before you ship. Vouqis runs 10 deterministic probes, zero LLM calls, and gives you a trust score you can put in your README and gate on in CI. Happy to audit anyone's MCP server live in the comments — just drop a URL
Maker
Vouqis brings deeper visibility into MCP reliability through structured validation and measurable trust scoring. We're grateful to share this with the community and would truly value your feedback.
Maker

 The five-probe approach makes a lot of sense. I'm curious how the CI gate handles custom weights. Some production environments care more about latency thresholds than error diversity. Can teams adjust these scoring weights inside their workflow files today?

Maker

As Taylor mentioned, the real insight is that “HTTP 200” does not mean MCP success. The product addresses a painful and increasingly common issue: AI agents fail silently while infrastructure dashboards still look healthy. Its strongest positioning advantage is protocol-level trust scoring powered by deterministic probes, giving teams visibility into failures traditional observability tools completely miss.

Maker

  The silent empty array failure is the trickiest one to catch. If a server returns an empty list because a database query genuinely found nothing, that is structurally valid. How does a deterministic probe tell the difference between a true empty state and a silent error without knowing the database state? False positives will break builds in CI for the wrong reasons.

Maker
Building Vouqis also made us realize that traditional uptime metrics alone are no longer enough for MCP ecosystems. A server can appear “healthy” at the infrastructure layer while still failing protocol-level expectations that directly impact agent reliability. That’s why the focus on deterministic probing became important for us — not just detecting outages, but identifying silent trust and validation failures before they reach production workflows. We believe MCP tooling needs the same level of reliability standards that modern CI/CD brought to application infrastructure.
Maker

 This is the real bottleneck. But how do we handle auth-heavy servers without storing customer credentials on the runner? If the probe itself fails due to token expiration, is that a server failure or an environment configuration issue? We need to draw a hard line on what constitutes a protocol error vs an environment error.

Maker
That distinction is extremely important, and we spent significant time thinking about that boundary while designing the probes. Our approach is to separate environmental dependency failures from protocol-level reliability failures. Expired credentials, revoked tokens, or unreachable secret providers are classified differently from malformed JSON-RPC handling, schema violations, timeout behavior, or invalid tool responses. For auth-heavy servers specifically, the goal is not to persist customer credentials inside the runner, but to validate whether the server behaves correctly under the authentication contract it exposes. In practice, a failed probe should only reduce trust scoring when the server violates expected protocol behavior — not when the execution environment itself is misconfigured. Otherwise the scoring system becomes noisy and loses operational credibility. The harder challenge long term is building deterministic trust evaluation while keeping infrastructure assumptions minimal. That’s where most MCP reliability tooling still falls short today.
Maker
An empty response is one of the hardest signals to trust.Did the system correctly return 'nothing found,' or did a timeout, schema mismatch, or hidden failure produce the same result?The value of deterministic probes isn't just detecting errors—it's proving expected behavior under known conditions.How are you preventing silent failures from looking like valid empty states?"
Maker

Most agents fail silently at the protocol layer. Standard infrastructure monitoring tracks transport-layer availability, but it fails to catch malformed schema definitions or corrupted payloads. When an LLM receives a valid HTTP transport envelope containing polluted data, it processes the error as a successful tool execution and behaves unpredictably.

Maker

 Yes thats what most Engineers miss and regret it later after it reaches to the user