Precept.Mcp

An MCP server that lets a coding agent inspect a Precept test project. It answers the questions Precept cannot answer for itself at runtime: why a green build found no tests, which of five sources decided the environment, why raising MaxParallelism changed nothing, what a filter expression will actually select, and how the suite's test data is meant to be written.

This is a tool, not a library — nothing in your test code references it.

It is one of two things Precept ships for an agent. The other is a set of skills, a Copilot agent and an instructions file, installed from autom3tion/precept-skills — see Working with a coding agent.

dotnet tool install --global Precept.Mcp

Then point an MCP client at it. Checked into the repository as .mcp.json, this is picked up by Claude Code and other clients that read it:

{
  "mcpServers": {
    "precept": {
      "command": "precept-mcp"
    }
  }
}

To skip the install entirely, use "command": "dnx" with "args": ["Precept.Mcp", "--yes"] — the package is fetched and run on demand.

What it does#

Tool	Answers
`precept_diagnose_project`	Feature files that generate no code-behind, duplicate scenarios from a stray `.feature` under `bin`, settings that never reach the test binary, test data files that never reach it either, `dotnet test` pointed at the wrong runner, a `.runsettings` nothing reads, an environment with no overlay, a reporter the CI gate will drop.
`precept_explain_environment`	Which of the five sources decided the environment, and which `precept.{environment}.json` that loads.
`precept_explain_parallelism`	The effective width of a run, and why a higher `MaxParallelism` may schedule nothing extra.
`precept_explain_failure`	Maps an error message or symptom onto its known cause.
`precept_explain_module`	What a module is for, its one-line registration, its entry point and settings section with the real defaults, the assertions it adds — and which modules a project already references, registers and configures.
`precept_explain_testdata`	How `Precept.TestData` is used — files and overlays, `{{token}}` generators, the type-to-set convention, factories and pools — plus what the project already has and whether its data files reach the output directory.
`precept_validate_filter`	Parses a filter with the runner's own parser, and catches the leading `@` that the test platform reads as a response file.

Every check is one of Precept's silent failure modes — the ones where the build is green, the run is green, and the answer is quietly wrong. A compiler error needs no help. The explanations are there for the same reason: a convention, a precedence order or a copy step that is nowhere in the project's own source is the thing an agent guesses at, and guesses wrong.

The server is read-only. It reports each finding with the edit that would fix it and leaves the edit to you.

Which Precept is answering#

The server references every Precept package, not just Precept.Core, and reads the answers out of those assemblies: settings sections with their real defaults, the assertions each module adds, the test data naming convention, which {{token}} names are built in. Nothing here is a transcription that a release can quietly falsify.

A tool package bundles its dependencies, so the server carries its own copy of them and answers out of that: the filter parser, the environment order and the settings names it reports are the server's version, not necessarily the project's. A global install is one version for the whole machine, which is how a second repository on a second Precept version gets answered for by the first.

The server says so rather than leaving you to find out. Every answer names the version behind it, and precept_diagnose_project reports PMCP008 when the two are far enough apart to disagree. To pin the server to a project instead, run it per invocation:

{
  "mcpServers": {
    "precept": { "command": "dnx", "args": ["Precept.Mcp@0.10.0", "--yes"] }
  }
}

Part of Precept, a .NET 10 test automation framework. Full documentation: configuration · environments · execution model · filtering · reporting