Servidor MCP de Clairvoyance

• Nombre en el registrofyi.clairvoyance/mcpverificado en el registro MCP

El nombre en el registro está bajo clairvoyance.fyi. El registro solo permite usar ese espacio de nombres a quien demuestra control del dominio por DNS o HTTP.

• Estadorespondecomprobado el 2026-10-26
• Herramientas17
• El servidor se llamafyi.clairvoyance/mcp
• Versión del servidor1.3.1
• Versión del protocolo2025-06-18

El 2026-10-26 el servidor respondió a initialize y tools/list sin iniciar sesión. Primera respuesta en 29 ms.

• Sus herramientas hacen todos los casos de uso comprobados: review agent-written code for hidden complexity; check naming and comments for clarity; compare design alternatives before writing code.
• Comprobado 1 de los 7 días necesarios para juzgar su fiabilidad.

Lo dicen reglas a partir de las mediciones de arriba. La primera llamada probable la elige un modelo de la lista de herramientas; lee su descripción antes de fiarte.

• Nota INITE MCPtras una semanala nota necesita 7 comprobaciones diarias: 1 hasta ahora
• Qué puede hacer un agente con él3 de 3 casos de uso
• Uso14 estrellas en GitHub
• Respondiómidiendo1 de las 7 comprobaciones diarias necesarias para mostrar el porcentaje
• Mediana de la primera respuesta204 ms
• Espacio en el contexto del agente≈ 2298 tokenslas definiciones de todas sus herramientas (17), que el agente lleva en cada turno
• Definiciones de herramientasA · 100 de 100
• Resultados tipados0 de 17 herramientasdeclaran outputSchema: el resultado llega tipado y se lee de una vez

• Todas las herramientas pasan las seis comprobaciones.

Un programa comprueba el servidor una vez al día: initialize y tools/list, sin modelo. Los tokens son la longitud de las definiciones, a unos cuatro caracteres por token. La nota promedia seis comprobaciones del nombre, la descripción, el esquema y las anotaciones de cada herramienta; dice lo bien descritas que están, no si funcionan. La nota pondera solo lo medido: si responde (25%), si hace el trabajo del producto (25%), definiciones (20%), contexto (10%), uso (10%) y lo fácil que es conectarse (10%). Lo que no se midió queda fuera, y una instrucción oculta limita la nota a 40. El estado de los servidores MCP de los proveedores: método y números →

• 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)…