# Clairvoyance (remote · clairvoyance.fyi)

Software design skills for AI coding agents, inspired by A Philosophy of Software Design.

- Trust score: 85/100 (high trust)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- remote · `clairvoyance.fyi`: 85/100 (this document), [markdown](https://verifymcp.io/servers/fyi-clairvoyance-mcp/clairvoyance.md), [page](https://verifymcp.io/servers/fyi-clairvoyance-mcp/clairvoyance)

## Channel facts

- Endpoint: `https://clairvoyance.fyi/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.3.1`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Endpoint Security**: 74/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - No authorisation is required to call this server. Nothing on it is marked destructive, but we can't show that an anonymous caller can only read: full credit needs the server to list at least one tool and every tool to be verifiably read-only. We use a best-effort check of tool names and descriptions to tell read-only tools from tools that change things, so some genuinely read-only tools may not get full credit. Names that start with a read verb (get, list, read, search and similar) and accurate readOnlyHint annotations help. Meet that to earn full credit, or require authorisation.
  - HTTPS is enforced; there's no plaintext access path.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 88/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 1937 tokens (~113/item across 17 items; 17 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 93/100
  - Stability observed for 28 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Tool Safety**: 75/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 17 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - Manipulation not yet verified: none of the 18 captured unit(s) of tool text has been judged yet, so we will not certify text no model has read as clean.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the Clairvoyance MCP server?

Clairvoyance is a hosted endpoint at https://clairvoyance.fyi/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

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

### Cursor

```json
{
  "mcpServers": {
    "fyi-clairvoyance-mcp": {
      "url": "https://clairvoyance.fyi/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "fyi-clairvoyance-mcp": {
      "type": "http",
      "url": "https://clairvoyance.fyi/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.fyi-clairvoyance-mcp]
url = "https://clairvoyance.fyi/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "fyi-clairvoyance-mcp": {
      "type": "remote",
      "url": "https://clairvoyance.fyi/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add fyi-clairvoyance-mcp --url 'https://clairvoyance.fyi/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  fyi-clairvoyance-mcp:
    url: "https://clairvoyance.fyi/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "fyi-clairvoyance-mcp": {
      "Transport": "http",
      "Url": "https://clairvoyance.fyi/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add fyi-clairvoyance-mcp -t streamable-http -u 'https://clairvoyance.fyi/mcp'
```

### Other

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

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-04 (score 85, +1)

No change was recorded against any check on this day. Stability & Change Management went from 87 to 90. That category is still filling its 30-day observation window: 26 days of observed history at the previous scan, 27 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-11-02 (score 84, +1)

No change was recorded against any check on this day. Stability & Change Management went from 80 to 83. That category is still filling its 30-day observation window: 24 days of observed history at the previous scan, 25 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-31 (score 83, +1)

No change was recorded against any check on this day. Stability & Change Management went from 73 to 77. That category is still filling its 30-day observation window: 22 days of observed history at the previous scan, 23 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-29 (score 82, +1)

No change was recorded against any check on this day. Stability & Change Management went from 67 to 70. That category is still filling its 30-day observation window: 20 days of observed history at the previous scan, 21 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-27 (score 81, +1)

No change was recorded against any check on this day. Stability & Change Management went from 60 to 63. That category is still filling its 30-day observation window: 18 days of observed history at the previous scan, 19 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-25 (score 80, +1)

No change was recorded against any check on this day. Stability & Change Management went from 53 to 57. That category is still filling its 30-day observation window: 16 days of observed history at the previous scan, 17 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-22 (score 79, +1)

No change was recorded against any check on this day. Stability & Change Management went from 43 to 47. That category is still filling its 30-day observation window: 13 days of observed history at the previous scan, 14 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-20 (score 78, +1)

No change was recorded against any check on this day. Stability & Change Management went from 37 to 40. That category is still filling its 30-day observation window: 11 days of observed history at the previous scan, 12 at this one. The score rises as the window fills, whether or not the server changes.

## MCP tools (17)

### `deep-modules` (~76 tokens)

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 whether adjacent layers provide different abstractions (use abstraction-quality) or merging/splitting modules (use module-boundaries).

### `module-boundaries` (~75 tokens)

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. Not for depth within a single module (use deep-modules) or abstraction-layer quality (use abstraction-quality).

### `information-hiding` (~74 tokens)

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 rather than knowledge ownership. Not for merge/split decisions (use module-boundaries) or interfaces over-specialized for one caller (use general-vs-special).

### `pull-complexity-down` (~81 tokens)

Pull Complexity Downwards

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. Not for module depth (use deep-modules), knowledge leakage (use information-hiding), or exception strategy once an error must surface (use error-design).

### `general-vs-special` (~70 tokens)

General vs. Special-Purpose

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 leakage across boundaries (use information-hiding) or auditing configuration parameters (use pull-complexity-down).

### `error-design` (~80 tokens)

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 know about. Not for general caller-burden complexity (use pull-complexity-down); this skill is specifically for exception and error-condition strategy.

### `abstraction-quality` (~75 tokens)

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 module's interface-to-implementation ratio (use deep-modules) or information leakage across boundaries (use information-hiding).

### `naming-obviousness` (~71 tokens)

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 on first read. Not for comment quality or documentation (use comments-docs).

### `comments-docs` (~68 tokens)

Comments & Documentation

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 sentence. Not for naming or code obviousness (use naming-obviousness).

### `strategic-mindset` (~79 tokens)

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 consistently degrades the system. Not for judging whether a specific diff looks designed-in or bolted-on (use code-evolution).

### `design-it-twice` (~115 tokens)

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, APIs, or architecture. Also use when asked how to structure or architect a feature, or when writing the design or alternatives section of an RFC, design doc, or ADR. Not for judging strategic vs. tactical investment in existing code (use strategic-mindset) or whether a change degrades design (use code-evolution).

### `code-evolution` (~83 tokens)

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 designed-in or bolted-on. Not for scanning design smells (use red-flags) or assessing overall design investment (use strategic-mindset).

### `complexity-recognition` (~75 tokens)

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 smells (use red-flags) or evaluating a module's depth (use deep-modules).

### `red-flags` (~151 tokens)

Red Flags Diagnostic

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 checklist, is evaluating unfamiliar code, or asks open-endedly whether anything is off in a named or pasted file, class, or function, or asks you to look it over. Not for a specific bug, error, or failing test the user has already identified. Not for a plain diff or PR review before merge, or whether a PR maintains design trajectory (use code-evolution for both), or diagnosing why code feels complex (use complexity-recognition).

### `design-review` (~117 tokens)

Design Review Orchestrator

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 PR. Not for an open-ended "anything off here?" or "take a look at this" prompt that names no review goal (use red-flags), a plain diff review before merge or analyzing how code changed over time (use code-evolution), or applying one specific lens (use that skill directly).

### `diagnose` (~61 tokens)

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 checklist scan (use red-flags).

### `fetch-reference` (~129 tokens)

Fetch a skill's supporting file

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); comments-docs (comments-first-workflow.md); design-it-twice (pre-mortem-fallback.md); red-flags (flag-interaction-map.md); design-review (workflow-builder.md).

Input parameters:

- `file` (string, required): The file name inside the skill's references/ folder
- `skill` (string, required): The skill the file belongs to

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/fyi-clairvoyance-mcp/clairvoyance#diagnostics

## Score history

- 2026-11-05: 85
- 2026-11-04: 85
- 2026-11-03: 84
- 2026-11-02: 84
- 2026-11-01: 83
- 2026-10-31: 83
- 2026-10-30: 82
- 2026-10-29: 82
- 2026-10-28: 81
- 2026-10-27: 81
- 2026-10-26: 80
- 2026-10-25: 80
- 2026-10-24: 79
- 2026-10-23: 79
- 2026-10-22: 79
- 2026-10-21: 78
- 2026-10-20: 78
- 2026-10-19: 77
- 2026-10-18: 77
- 2026-10-17: 76
- 2026-10-16: 76
- 2026-10-15: 75
- 2026-10-14: 75
- 2026-10-13: 74
- 2026-10-12: 74
- 2026-10-10: 73

## Common questions

### What is the Clairvoyance MCP server?

Clairvoyance is an MCP server listed in the public MCP registry as fyi.clairvoyance/mcp. Software design skills for AI coding agents, inspired by A Philosophy of Software Design. This page covers its hosted endpoint (https://clairvoyance.fyi/mcp).

### Is the Clairvoyance MCP server safe to use?

Clairvoyance scores 85 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Clairvoyance MCP server expose?

Clairvoyance exposes 17 tools: deep-modules, module-boundaries, information-hiding, pull-complexity-down, general-vs-special, and 12 more. Their descriptions and schemas cost roughly 1,480 tokens of context every time the server is loaded.

### Does the Clairvoyance MCP server require authentication?

No. We connected to Clairvoyance without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

### Is the Clairvoyance MCP server still maintained?

Clairvoyance is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What did VerifyMCP test on the Clairvoyance MCP server?

VerifyMCP ran 12 checks on Clairvoyance, covering TLS certificate, Authorization, HTTPS, HSTS header and 8 more. One item could not be completed, a gap on our side rather than a finding about Clairvoyance: Judged manipulation. Supply Chain Security and Provenance & Transparency do not apply to a hosted endpoint, so they were not tested. The score does not measure everything, and the scoring documentation lists what it leaves out.

## Links

- Remote endpoint: https://clairvoyance.fyi/mcp
- Repository: https://github.com/codybrom/clairvoyance
- Website: https://clairvoyance.fyi/mcp
- Changelog RSS feed: https://verifymcp.io/servers/fyi-clairvoyance-mcp/clairvoyance.xml
- Changelog JSON feed: https://verifymcp.io/servers/fyi-clairvoyance-mcp/clairvoyance/changelog.json
- Trust report (JSON): https://verifymcp.io/servers/fyi-clairvoyance-mcp/clairvoyance.json
- HTML version of this page: https://verifymcp.io/servers/fyi-clairvoyance-mcp/clairvoyance