Clairvoyance

by clairvoyance.fyi · remote · no sign-in to list tools · v1.3.1 · published by fyi.clairvoyance

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

Changes · 16

Compare Registry entry

17 tools: 16 change things and 1 only read.

Scanned Oct 21, 2026

Deletes or cancels0Claude Code: deny
Can't be undone0Claude Code: ask
Changes things16Claude Code: ask: see these tools
Only reads1Claude Code: allow: see these tools

6 checks matched something in the tool definitions. No finding is not a safety guarantee. How the checks work.

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

Findings

Matches of fixed checks, with the text they matched.

6 warn

Warnmodule-boundaries
The server marks "module-boundaries" read-only (readOnlyHint: true), and its own name, description or input give the class "write".
Matched text
annotations: {"readOnlyHint":true}; The description's first verb is "evaluate": a word for a change.
What this check looks for
Warngeneral-vs-special
The server marks "general-vs-special" read-only (readOnlyHint: true), and its own name, description or input give the class "write".
Matched text
annotations: {"readOnlyHint":true}; The description's first verb is "evaluate": a word for a change.
What this check looks for
Warnabstraction-quality
The server marks "abstraction-quality" read-only (readOnlyHint: true), and its own name, description or input give the class "write".
Matched text
annotations: {"readOnlyHint":true}; The description's first verb is "evaluate": a word for a change.
What this check looks for
Warncomments-docs
The server marks "comments-docs" read-only (readOnlyHint: true), and its own name, description or input give the class "write".
Matched text
annotations: {"readOnlyHint":true}; The name "comments-docs" says "comment": a word for a change.
What this check looks for
Warndesign-it-twice
The server marks "design-it-twice" read-only (readOnlyHint: true), and its own name, description or input give the class "write".
Matched text
annotations: {"readOnlyHint":true}; The description's first verb is "generate": a word for a change.
What this check looks for
Warncode-evolution
The server marks "code-evolution" read-only (readOnlyHint: true), and its own name, description or input give the class "write".
Matched text
annotations: {"readOnlyHint":true}; The description's first verb is "evaluate": a word for a change.
What this check looks for

Tools

Open a tool for its reasons and full description. Descriptions are the publisher's own words, shown as they are.

17 tools

Changes things 16Creates or changes something that can be changed back.Claude Code: ask

abstraction-qualityEvaluates whether abstractions provide a genuinely different way of thinking or are structurally shallow.1 finding
Why it is in this group
- The description's first verb is "evaluate": a word for a change.
- The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
Findings
- Warn
  The server marks "abstraction-quality" read-only (readOnlyHint: true), and its own name, description or input give the class "write".
  Matched text
  annotations: {"readOnlyHint":true}; The description's first verb is "evaluate": a word for a change.
  What this check looks for
Description, as the server wrote it
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).
Annotations the server declares
- readOnlyHint: true
code-evolutionEvaluates whether changes to existing code maintain or degrade design quality.1 finding
Why it is in this group
- The description's first verb is "evaluate": a word for a change.
- The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
Findings
- Warn
  The server marks "code-evolution" read-only (readOnlyHint: true), and its own name, description or input give the class "write".
  Matched text
  annotations: {"readOnlyHint":true}; The description's first verb is "evaluate": a word for a change.
  What this check looks for
Description, as the server wrote it
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).
Annotations the server declares
- readOnlyHint: true
comments-docsReviews comment quality and documentation practices: the four comment types, comments-first workflow, and comment rot.1 finding
Why it is in this group
- The name "comments-docs" says "comment": a word for a change.
- The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
Findings
- Warn
  The server marks "comments-docs" read-only (readOnlyHint: true), and its own name, description or input give the class "write".
  Matched text
  annotations: {"readOnlyHint":true}; The name "comments-docs" says "comment": a word for a change.
  What this check looks for
Description, as the server wrote it
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).
Annotations the server declares
- readOnlyHint: true
complexity-recognitionDiagnoses whether complexity exists and where it comes from, using the three-symptom, two-root-cause framework.No findings
Why it is in this group
- Nothing in its name or description says what it does, so it is counted as a write.
- The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
Description, as the server wrote it
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).
Annotations the server declares
- readOnlyHint: true
deep-modulesMeasures module depth: whether the interface is simple relative to the implementation behind it.No findings
Why it is in this group
- Nothing in its name or description says what it does, so it is counted as a write.
- The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
Description, as the server wrote it
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).
Annotations the server declares
- readOnlyHint: true
design-it-twiceGenerates and compares at least two fundamentally different design alternatives on concrete criteria before committing.1 finding
Why it is in this group
- The description's first verb is "generate": a word for a change.
- The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
Findings
- Warn
  The server marks "design-it-twice" read-only (readOnlyHint: true), and its own name, description or input give the class "write".
  Matched text
  annotations: {"readOnlyHint":true}; The description's first verb is "generate": a word for a change.
  What this check looks for
Description, as the server wrote it
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).
Annotations the server declares
- readOnlyHint: true
design-reviewOrchestrates a structured design review, running the other skills as a diagnostic funnel from complexity triage to a full red-flags sweep.No findings
Why it is in this group
- Nothing in its name or description says what it does, so it is counted as a write.
- The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
Description, as the server wrote it
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).
Annotations the server declares
- readOnlyHint: true
diagnoseRoutes a vague symptom or complaint to the most relevant Clairvoyance skill via a decision tree.No findings
Why it is in this group
- Nothing in its name or description says what it does, so it is counted as a write.
- The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
Description, as the server wrote it
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).
Annotations the server declares
- readOnlyHint: true
error-designReviews error handling and exception design, applying the "define errors out of existence" principle.No findings
Why it is in this group
- Nothing in its name or description says what it does, so it is counted as a write.
- The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
Description, as the server wrote it
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.
Annotations the server declares
- readOnlyHint: true
general-vs-specialEvaluates whether interfaces are appropriately general-purpose.1 finding
Why it is in this group
- The description's first verb is "evaluate": a word for a change.
- The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
Findings
- Warn
  The server marks "general-vs-special" read-only (readOnlyHint: true), and its own name, description or input give the class "write".
  Matched text
  annotations: {"readOnlyHint":true}; The description's first verb is "evaluate": a word for a change.
  What this check looks for
Description, as the server wrote it
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).
Annotations the server declares
- readOnlyHint: true
information-hidingChecks for information leakage across module boundaries, including temporal decomposition and false encapsulation.No findings
Why it is in this group
- Nothing in its name or description says what it does, so it is counted as a write.
- The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
Description, as the server wrote it
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).
Annotations the server declares
- readOnlyHint: true
module-boundariesEvaluates where module boundaries are drawn and whether modules should be merged or split.1 finding
Why it is in this group
- The description's first verb is "evaluate": a word for a change.
- The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
Findings
- Warn
  The server marks "module-boundaries" read-only (readOnlyHint: true), and its own name, description or input give the class "write".
  Matched text
  annotations: {"readOnlyHint":true}; The description's first verb is "evaluate": a word for a change.
  What this check looks for
Description, as the server wrote it
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).
Annotations the server declares
- readOnlyHint: true
naming-obviousnessReviews naming quality and code obviousness via the isolation test, scope-length principle, and consistency audit.No findings
Why it is in this group
- Nothing in its name or description says what it does, so it is counted as a write.
- The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
Description, as the server wrote it
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).
Annotations the server declares
- readOnlyHint: true
pull-complexity-downChecks whether complexity is pushed to callers or absorbed by implementations — the direction complexity flows.No findings
Why it is in this group
- Nothing in its name or description says what it does, so it is counted as a write.
- The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
Description, as the server wrote it
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).
Annotations the server declares
- readOnlyHint: true
red-flagsScans code against 17 design smells (the book's 14 named Red Flags plus 3 process-stage signals) and produces a structured diagnostic report.No findings
Why it is in this group
- Nothing in its name or description says what it does, so it is counted as a write.
- The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
Description, as the server wrote it
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).
Annotations the server declares
- readOnlyHint: true
strategic-mindsetAssesses whether code reflects strategic or tactical thinking, including the 10-20% investment rule and tactical-tornado patterns.No findings
Why it is in this group
- Nothing in its name or description says what it does, so it is counted as a write.
- The server marks it read-only (readOnlyHint: true), but an annotation never lowers a class.
Description, as the server wrote it
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).
Annotations the server declares
- readOnlyHint: true

Only reads 1Looks things up and changes nothing.Claude Code: allow

fetch-referenceFetch a supporting file from a Clairvoyance skill's references/ folder, when the skill's instructions point to one.No findings
Why it is in this group
- The name "fetch-reference" says "fetch": a word for reading.
Description, as the server wrote it
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).
Annotations the server declares
- readOnlyHint: true

This is not a safety rating, and no finding is not a safety guarantee. The groups and findings come from fixed checks of the tool definitions the server returned on the date shown, not from its code or what it does when called. How the checks work.

Install

Pinned to version 1.3.1. Values in angle brackets are yours to fill in.

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

Run in a terminal.

Claude Code permissions

Allow the reads, ask before a change, deny the deletes. Paste into .claude/settings.json.

.claude/settings.json

{
  "permissions": {
    "allow": [
      "mcp__clairvoyance__fetch-reference"
    ],
    "ask": [
      "mcp__clairvoyance__deep-modules",
      "mcp__clairvoyance__module-boundaries",
      "mcp__clairvoyance__information-hiding",
      "mcp__clairvoyance__pull-complexity-down",
      "mcp__clairvoyance__general-vs-special",
      "mcp__clairvoyance__error-design",
      "mcp__clairvoyance__abstraction-quality",
      "mcp__clairvoyance__naming-obviousness",
      "mcp__clairvoyance__comments-docs",
      "mcp__clairvoyance__strategic-mindset",
      "mcp__clairvoyance__design-it-twice",
      "mcp__clairvoyance__code-evolution",
      "mcp__clairvoyance__complexity-recognition",
      "mcp__clairvoyance__red-flags",
      "mcp__clairvoyance__design-review",
      "mcp__clairvoyance__diagnose"
    ],
    "deny": []
  }
}

Tools that only read are allowed, tools that change things ask first, tools that delete or cancel are denied. It assumes the server is installed as clairvoyance. Review it before you use it.

Keep track

Get told when this server's tools change: a new tool, a new description, a new class.

https://anlyon.dev/servers/fyi.clairvoyance/mcp/changes.xml

An Atom feed. Works in any feed reader or Slack's RSS app.

Anlyon alternative

16 of these tools change something. Run those as governed actions.

Declare what an action changes, and Anlyon puts it under a shared limit, binds every approval to the exact request, and grades the outcome. It works on any HTTPS API you can describe as an action.

Anlyon does not run, proxy or govern this MCP server. A tool your own code calls directly is not routed through Anlyon and is not governed by it.

Import an OpenAPI spec →

Compare with other servers for the same product.

Source: MCP Registry · repository. Synced Oct 21, 2026, 18:12 UTC.

For agents: Markdown · JSON · report this listing