Quell reads your docstrings, Pydantic models, and type annotations, extracts every testable requirement, finds which ones have no test, generates pytest tests via a rule engine, verifies each test through a 5-gate pipeline, and writes only proven tests to disk.

Does Quell require an LLM API key?

The rule engine runs entirely in-process — no source code is ever transmitted. ~75% of edge cases are handled with no network call and no API key. LLM fallback is opt-in and only sends the function signature, never the full body.

What is the 5-gate pipeline?

Every generated test must pass: Gate 1 (AST valid Python), Gate 2 (not already in a test file), Gate 3 (no shell calls or file writes), Gate 4 (passes against original code), Gate 5 (fails when the requirement is violated). Only gate-5-verified tests are written to disk.

What is the Production Readiness Score (PRS)?

PRS = (WRITTEN × 1.0 + SCAFFOLDED × 0.5) / total_requirements × 100. Tiers: 80-100 Production Ready, 60-79 Review Needed, 0-59 Needs Work.

How is Quell different from GitHub Copilot or Qodo for test generation?

Quell reads specifications that already exist in your code — it does not generate tests from scratch. It finds requirements already documented in your docstrings, Pydantic models, and type annotations that have no test. The 5-gate pipeline, especially Gate 5 (violation injection), verifies each test actually catches the bug it claims to catch. This verification step is not present in Copilot, Qodo, or Hypothesis.

Can Quell be used in CI pipelines?

Yes. Run quell ci src/ --threshold 80 to fail CI if PRS falls below 80. Set prs_threshold in pyproject.toml under [tool.quell]. Works with GitHub Actions, GitLab CI, and any system that checks exit codes.

Can Claude Code or Cursor use Quelltest directly?

Yes. Quelltest ships a local MCP server: install with pip install quelltest[mcp], then add {"mcpServers": {"quelltest": {"command": "quelltest-mcp"}}} to your project's .mcp.json. The agent can then call find_edge_cases, write_verified_tests, get_prs_score, prove_file, and reproduce_bug directly — no terminal needed. A Claude Code plugin is also available via /plugin marketplace add quelltest/quelltest-lib.

Does the Quelltest MCP server send my code anywhere?

No. The local MCP server (quelltest-mcp) runs entirely on your machine over stdio — no cloud, no network calls, no telemetry. The separate opt-in Claude.ai connector only ever transmits sanitized metrics (PRS score, bucket counts, test names, flag locations); a sanitizer blocks source code, function bodies, and docstrings structurally.

How do I add Quelltest as a Claude.ai connector?

In Claude.ai, go to Settings, then Connectors, then Add custom connector, and enter https://mcp.quelltest.com. Claude discovers the OAuth endpoints automatically and walks you through authorization.

Quelltest Is Now Agent-Native

Starting today, Quelltest ships a local MCP server inside the pip package. Two steps and your coding agent can operate it directly:

pip install "quelltest[mcp]"

// .mcp.json in your project root
{ "mcpServers": { "quelltest": { "command": "quelltest-mcp" } } }

That's the whole setup. Now ask Claude Code to "find untested edge cases in this project and fix the payment ones" — and it does, in-session, without you touching a terminal.

Why I changed direction

The first version of our Claude integration was a cloud connector: sync your readiness reports up, and Claude.ai could answer questions about your PRS trend. It worked. It also missed the point.

Reading a score in a chat window makes Claude a spectator. What I actually wanted — what I kept doing manually all day — was Claude as an operator: write a function, immediately check what's untested, write the proven test, move on. The loop belongs inside the coding session, next to the code, not in a dashboard.

MCP made the right version almost embarrassingly simple. The server is a thin stdio wrapper over the same SDK the CLI uses. There is no cloud component. There is no network call. The agent spawns a process, the process reads your working tree, results go back over stdio, done.

The five tools

Tool	What the agent gets
`find_edge_cases`	Documented requirements with no test — with file:line locations
`write_verified_tests`	A pytest test per gap, each proven through all 5 gates, written to disk
`get_prs_score`	Production Readiness Score with tier and per-file breakdown
`prove_file`	Coverage ratio for one file or one function
`reproduce_bug`	A natural-language bug description turned into a verified failing test

The important part isn't the tool list — it's what the tools refuse to do. write_verified_tests will not write a test that didn't pass Gate 5, where we inject the violation into your source and require the test to fail. An agent calling this tool cannot flood your repo with decorative tests. The pipeline physically won't let it.

That matters more in the agent era, not less. Agents generate tests at 50x human speed, and unverified tests at 50x speed is 50x more false confidence. Verification is the part that has to stay ruthless.

There's a Claude Code plugin too

If you live in Claude Code, the plugin bundles a skill that teaches Claude the workflows — scan after editing, score before a PR, reproduce bugs as failing tests:

/plugin marketplace add quelltest/quelltest-lib
/plugin install quelltest@quelltest

Then /quelltest find src/, /quelltest score, or plain English.

What about the cloud connector?

Still there, still useful for the team-dashboard case — PRS trends across projects, readiness questions in Claude.ai chat. But it's now the optional add-on, not the story. The story runs on your machine.

Full setup docs: quelltest.com/docs/mcp. If you hit a rough edge, open an issue — this is a fresh surface and I want the bug reports.