Clairvoyance MCP server

Which MCP servers are Clairvoyance's own, from the official registry and from asking its own domain, whether they answer, and what they offer. A program checked each of these, nobody copied them from a product page.

read 2026-10-26

← Back to Clairvoyance

Whose server it is

Registry namefyi.clairvoyance/mcpverified in the MCP registry

The registry name sits under clairvoyance.fyi. The registry only lets a publisher use that namespace after proving control of the domain through DNS or HTTP.

When we asked itchecked 2026-10-26

Stateanswerschecked 2026-10-26
Tools17
Server calls itselffyi.clairvoyance/mcp
Server version1.3.1
Protocol version2025-06-18

On 2026-10-26 the server answered initialize and tools/list without a sign-in. First answer in 29 ms.

Should an agent connect itNot proven either way yet

Its tools do every use case we checked: review agent-written code for hidden complexity; check naming and comments for clarity; compare design alternatives before writing code.
Checked on 1 of the 7 days it takes to judge reliability.

Once connected

For "check naming and comments for clarity", the likely first call is naming-obviousness.
For "compare design alternatives before writing code", the likely first call is design-it-twice.

Said by rules from the measurements above. The likely first call is a model's pick from the tool list; read its description before relying on it.

Measured dailydaily checks: 1, the first on 2026-10-26

INITE MCP scoreafter a weeka score needs 7 daily checks: 1 so far
What an agent can do with it3 of 3 use cases
Use14 GitHub stars
Answeredmeasuring1 of the 7 daily checks it takes to print a share
Median first answer204 ms
Space in an agent's context≈ 2,298 tokensthe definitions of all its tools (17), which an agent carries on every turn
Tool definitionsA · 100 of 100
Typed results0 of 17 toolsdeclared outputSchema: results come typed, read once

Every tool passes all six checks.

What an agent can do with it

can do · review agent-written code for hidden complexity
can do · check naming and comments for clarity
can do · compare design alternatives before writing code

Each of the product's use cases, put to Jev against this server's tool list: can an agent do it with these tools?

Worth a look

None of the five warning signs in these definitions.

A program checks the server once a day: initialize and tools/list, no model. Tokens are the definitions' length at about four characters a token. The grade averages six checks of every tool's name, description, schema and annotations; it says how well the tools are described, not whether they work. The score weighs what was measured and nothing else: answering (25%), doing the product's job (25%), definitions (20%), context (10%), use (10%) and how readily a client connects (10%). A part that was not measured is left out, and a hidden instruction caps the score at 40. The state of vendors' MCP servers: method and numbers →

Tools it offers17 tools · read 2026-10-26

deep-modules
Measures module depth: whether the interface is simple relative to the implementation behind it. Use when an interface has too many parameters or methods, many small classes each do too little, or methods just forward calls. Not for…
module-boundaries
Evaluates where module boundaries are drawn and whether modules should be merged or split. Use when deciding whether to combine or separate two modules, when modules are tightly coupled, or when a change to one forces changes to another…
information-hiding
Checks for information leakage across module boundaries, including temporal decomposition and false encapsulation. Use when modules change together, implementation details leak across boundaries, or structure follows execution order…
pull-complexity-down
Checks whether complexity is pushed to callers or absorbed by implementations — the direction complexity flows. Use when callers must do significant setup, handle errors the module could resolve, or configure things they don't understand…
general-vs-special
Evaluates whether interfaces are appropriately general-purpose. Use when checking interface generality, when if-branches or parameters serve only one caller, or when getters/setters expose internal representation. Not for information…
error-design
Reviews error handling and exception design, applying the "define errors out of existence" principle. Use when reviewing error handling, when a module throws too many exceptions, or when callers must handle errors they shouldn't need to…
abstraction-quality
Evaluates whether abstractions provide a genuinely different way of thinking or are structurally shallow. Use when adjacent layers feel redundant, wrappers add boilerplate without depth, or an abstraction feels leaky. Not for a single…
naming-obviousness
Reviews naming quality and code obviousness via the isolation test, scope-length principle, and consistency audit. Use when names feel vague, something is hard to name (a design signal, not a vocabulary problem), or behavior isn't obvious…
comments-docs
Reviews comment quality and documentation practices: the four comment types, comments-first workflow, and comment rot. Use when reviewing comments or docs, when comments just repeat the code, or when something is hard to describe in a…
strategic-mindset
Assesses whether code reflects strategic or tactical thinking, including the 10-20% investment rule and tactical-tornado patterns. Use when evaluating design investment, when code was written under time pressure, or when working code…
design-it-twice
Generates and compares at least two fundamentally different design alternatives on concrete criteria before committing. Use when the user asks to design something twice, or before committing to any significant design of classes, modules…
code-evolution
Evaluates whether changes to existing code maintain or degrade design quality. Use when the user asks to review a diff or PR (for example before merging it), or asks about recently modified files, to judge whether each change looks…
complexity-recognition
Diagnoses whether complexity exists and where it comes from, using the three-symptom, two-root-cause framework. Use when code feels harder to work with than it should but the specific problem is unclear. Not for scanning known design…
red-flags
Scans code against 17 design smells (the book's 14 named Red Flags plus 3 process-stage signals) and produces a structured diagnostic report. Use when the user asks for a red flags or design smell scan, asks to check code against a…
design-review
Orchestrates a structured design review, running the other skills as a diagnostic funnel from complexity triage to a full red-flags sweep. Use when the user asks for a comprehensive or prioritized design assessment of a file, module, or…
diagnose
Routes a vague symptom or complaint to the most relevant Clairvoyance skill via a decision tree. Use when someone describes a problem but doesn't know which skill to reach for. Not for a comprehensive review (use design-review) or a…
fetch-reference
Fetch a supporting file from a Clairvoyance skill's references/ folder, when the skill's instructions point to one. Available: information-hiding (back-door-leakage.md); pull-complexity-down (configuration-parameter-audit.md)…

How to connect

Add the server to your MCP client config. Claude Desktop, Cursor and most other clients read this shape:

{
  "mcpServers": {
    "clairvoyance": {
      "type": "http",
      "url": "https://clairvoyance.fyi/mcp"
    }
  }
}

Add it

Claude Code, in a terminal

claude mcp add --transport http clairvoyance https://clairvoyance.fyi/mcp

Add to Cursor Add to VS Code

claude.ai, ChatGPT and other clients: add https://clairvoyance.fyi/mcp as a custom connector in the settings.

Each line is something a program found when it went looking: the registry entry, the server's own answer, a spec that parses. A missing line means we did not find it, not that it does not exist.