{"$schema":"https://wellknown.network/schemas/agent-record-v1.json","schemaVersion":"1","id":"ag_dxbrjhd8xwyn","handle":"clairvoyance","url":"https://wellknown.network/agents/clairvoyance","links":{"self":"https://wellknown.network/agents/clairvoyance/record.json","html":"https://wellknown.network/agents/clairvoyance","markdown":"https://wellknown.network/agents/clairvoyance/record.md","api":"https://wellknown.network/api/v1/agents/clairvoyance","status":"https://wellknown.network/api/v1/agents/clairvoyance/status","claim":"https://wellknown.network/agents/clairvoyance/claim","claimApi":"https://wellknown.network/api/v1/claims","claimDescriptor":"https://wellknown.network/agents/clairvoyance/claim.json","badge":"https://wellknown.network/agents/clairvoyance/badge.svg","openapi":"https://wellknown.network/openapi.json","history":"https://wellknown.network/api/v1/agents/clairvoyance/history","tools":"https://wellknown.network/api/v1/agents/clairvoyance/tools"},"ard":{"identifier":"urn:air:clairvoyance.fyi:server:clairvoyance","type":"application/mcp-server-card+json"},"kind":"mcp_server","declared":{"name":"Clairvoyance","summary":"Software design skills for AI coding agents, inspired by A Philosophy of Software Design.","description":"Software design skills for AI coding agents, inspired by A Philosophy of Software Design.","publisher":{"name":"clairvoyance.fyi","url":"https://clairvoyance.fyi"},"homepage":"https://clairvoyance.fyi/mcp","repository":"https://github.com/codybrom/clairvoyance","version":"1.3.1","license":null,"protocols":["mcp"],"tags":["software-design","code-review","agent-skills"],"pricing":null,"endpoints":[{"url":"https://clairvoyance.fyi/mcp","type":"mcp_streamable_http","auth":null,"probeable":true}],"skills":null,"tools":["deep-modules","module-boundaries","information-hiding","pull-complexity-down","general-vs-special","error-design","abstraction-quality","naming-obviousness","comments-docs","strategic-mindset","design-it-twice","code-evolution","complexity-recognition","red-flags","design-review","diagnose"],"extra":{"ard":{"type":"application/mcp-server-card+json","metadata":null,"identifier":"urn:air:clairvoyance.fyi:mcp:clairvoyance","artifactUrl":"https://clairvoyance.fyi/mcp/server-card","representativeQueries":["review this module for software design problems","find design red flags in this pull request","is this interface too shallow for what it does","compare two designs for this feature before i build it","why does this code feel so hard to change"]},"updatedAt":"2026-10-08T03:42:15.169906Z","publishedAt":"2026-10-08T03:42:15.169906Z","registryName":"fyi.clairvoyance/mcp"},"attribution":{"kind":"ard_catalog","name":"ard_catalog","repoUrl":"ard_catalog","summary":"ard_catalog","version":"ard_catalog","description":"ard_catalog","homepageUrl":"ard_catalog","publisherUrl":"ard_catalog","publisherName":"ard_catalog"}},"derived":{"capabilities":[{"slug":"code.review","name":"Code Review","confidence":1,"provenance":"derived"},{"slug":"media.3d","name":"3D & Design","confidence":1,"provenance":"derived"},{"slug":"dev.docs-lookup","name":"Documentation Lookup","confidence":1,"provenance":"derived"},{"slug":"code.documentation","name":"Code Documentation","confidence":0.583,"provenance":"derived"}],"categories":["code","dev","media"],"language":"en"},"observed":{"status":"live","statusReason":"Responded 6h ago.","lastOkAt":"2026-10-28T12:25:46.269Z","lastProbedAt":"2026-10-28T12:25:46.269Z","statusComputedAt":"2026-10-28T12:29:22.222Z","reliability30d":{"probes":68,"successRate":1,"p50Ms":183,"basis":"service","measures":{"availability":"availability","latency":"response time","tools":"tool surface observed","summary":"Checks reached the service itself."},"checks":{"total":68,"ok":68,"authBoundaryOk":0,"serviceOk":68,"note":"Counted from the observation rows for the window, checks of the server only (HTTP, A2A card, MCP initialize). ok = authBoundaryOk + serviceOk. `probes` is the sum of daily rollups and includes registry checks, so it can differ from `total`."}},"latestObservations":[{"at":"2026-10-28T12:25:46.269Z","kind":"mcp_initialize","ok":true,"httpStatus":200,"latencyMs":158,"error":null,"detail":{"tools":[{"name":"deep-modules","description":"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 "},{"name":"module-boundaries","description":"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 mo"},{"name":"information-hiding","description":"Checks for information leakage across module boundaries, including temporal decomposition and false encapsulation. Use when modules change together, implementat"},{"name":"pull-complexity-down","description":"Checks whether complexity is pushed to callers or absorbed by implementations — the direction complexity flows. Use when callers must do significant setup, hand"},{"name":"general-vs-special","description":"Evaluates whether interfaces are appropriately general-purpose. Use when checking interface generality, when if-branches or parameters serve only one caller, or"},{"name":"error-design","description":"Reviews error handling and exception design, applying the \"define errors out of existence\" principle. Use when reviewing error handling, when a module throws to"},{"name":"abstraction-quality","description":"Evaluates whether abstractions provide a genuinely different way of thinking or are structurally shallow. Use when adjacent layers feel redundant, wrappers add "},{"name":"naming-obviousness","description":"Reviews naming quality and code obviousness via the isolation test, scope-length principle, and consistency audit. Use when names feel vague, something is hard "},{"name":"comments-docs","description":"Reviews comment quality and documentation practices: the four comment types, comments-first workflow, and comment rot. Use when reviewing comments or docs, when"},{"name":"strategic-mindset","description":"Assesses whether code reflects strategic or tactical thinking, including the 10-20% investment rule and tactical-tornado patterns. Use when evaluating design in"},{"name":"design-it-twice","description":"Generates and compares at least two fundamentally different design alternatives on concrete criteria before committing. Use when the user asks to design somethi"},{"name":"code-evolution","description":"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"},{"name":"complexity-recognition","description":"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 "},{"name":"red-flags","description":"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 "},{"name":"design-review","description":"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 ask"},{"name":"diagnose","description":"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 ski"},{"name":"fetch-reference","description":"Fetch a supporting file from a Clairvoyance skill's references/ folder, when the skill's instructions point to one. Available: information-hiding (back-door-lea"}],"toolCount":17,"toolsHash":"12bee240d22a6d3b37a99ec6dd081d8d180e59f914895aa7f3294a60a5b35361","serverName":"fyi.clairvoyance/mcp","capabilities":["tools","prompts"],"serverVersion":"1.3.1","protocolVersion":"2025-06-18"}},{"at":"2026-10-28T05:29:19.421Z","kind":"mcp_initialize","ok":true,"httpStatus":200,"latencyMs":190,"error":null,"detail":{"tools":[{"name":"deep-modules","description":"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 "},{"name":"module-boundaries","description":"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 mo"},{"name":"information-hiding","description":"Checks for information leakage across module boundaries, including temporal decomposition and false encapsulation. Use when modules change together, implementat"},{"name":"pull-complexity-down","description":"Checks whether complexity is pushed to callers or absorbed by implementations — the direction complexity flows. Use when callers must do significant setup, hand"},{"name":"general-vs-special","description":"Evaluates whether interfaces are appropriately general-purpose. Use when checking interface generality, when if-branches or parameters serve only one caller, or"},{"name":"error-design","description":"Reviews error handling and exception design, applying the \"define errors out of existence\" principle. Use when reviewing error handling, when a module throws to"},{"name":"abstraction-quality","description":"Evaluates whether abstractions provide a genuinely different way of thinking or are structurally shallow. Use when adjacent layers feel redundant, wrappers add "},{"name":"naming-obviousness","description":"Reviews naming quality and code obviousness via the isolation test, scope-length principle, and consistency audit. Use when names feel vague, something is hard "},{"name":"comments-docs","description":"Reviews comment quality and documentation practices: the four comment types, comments-first workflow, and comment rot. Use when reviewing comments or docs, when"},{"name":"strategic-mindset","description":"Assesses whether code reflects strategic or tactical thinking, including the 10-20% investment rule and tactical-tornado patterns. Use when evaluating design in"},{"name":"design-it-twice","description":"Generates and compares at least two fundamentally different design alternatives on concrete criteria before committing. Use when the user asks to design somethi"},{"name":"code-evolution","description":"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"},{"name":"complexity-recognition","description":"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 "},{"name":"red-flags","description":"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 "},{"name":"design-review","description":"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 ask"},{"name":"diagnose","description":"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 ski"},{"name":"fetch-reference","description":"Fetch a supporting file from a Clairvoyance skill's references/ folder, when the skill's instructions point to one. Available: information-hiding (back-door-lea"}],"toolCount":17,"toolsHash":"12bee240d22a6d3b37a99ec6dd081d8d180e59f914895aa7f3294a60a5b35361","serverName":"fyi.clairvoyance/mcp","capabilities":["tools","prompts"],"serverVersion":"1.3.1","protocolVersion":"2025-06-18"}},{"at":"2026-10-27T22:30:55.607Z","kind":"mcp_initialize","ok":true,"httpStatus":200,"latencyMs":165,"error":null,"detail":{"tools":[{"name":"deep-modules","description":"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 "},{"name":"module-boundaries","description":"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 mo"},{"name":"information-hiding","description":"Checks for information leakage across module boundaries, including temporal decomposition and false encapsulation. Use when modules change together, implementat"},{"name":"pull-complexity-down","description":"Checks whether complexity is pushed to callers or absorbed by implementations — the direction complexity flows. Use when callers must do significant setup, hand"},{"name":"general-vs-special","description":"Evaluates whether interfaces are appropriately general-purpose. Use when checking interface generality, when if-branches or parameters serve only one caller, or"},{"name":"error-design","description":"Reviews error handling and exception design, applying the \"define errors out of existence\" principle. Use when reviewing error handling, when a module throws to"},{"name":"abstraction-quality","description":"Evaluates whether abstractions provide a genuinely different way of thinking or are structurally shallow. Use when adjacent layers feel redundant, wrappers add "},{"name":"naming-obviousness","description":"Reviews naming quality and code obviousness via the isolation test, scope-length principle, and consistency audit. Use when names feel vague, something is hard "},{"name":"comments-docs","description":"Reviews comment quality and documentation practices: the four comment types, comments-first workflow, and comment rot. Use when reviewing comments or docs, when"},{"name":"strategic-mindset","description":"Assesses whether code reflects strategic or tactical thinking, including the 10-20% investment rule and tactical-tornado patterns. Use when evaluating design in"},{"name":"design-it-twice","description":"Generates and compares at least two fundamentally different design alternatives on concrete criteria before committing. Use when the user asks to design somethi"},{"name":"code-evolution","description":"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"},{"name":"complexity-recognition","description":"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 "},{"name":"red-flags","description":"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 "},{"name":"design-review","description":"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 ask"},{"name":"diagnose","description":"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 ski"},{"name":"fetch-reference","description":"Fetch a supporting file from a Clairvoyance skill's references/ folder, when the skill's instructions point to one. Available: information-hiding (back-door-lea"}],"toolCount":17,"toolsHash":"12bee240d22a6d3b37a99ec6dd081d8d180e59f914895aa7f3294a60a5b35361","serverName":"fyi.clairvoyance/mcp","capabilities":["tools","prompts"],"serverVersion":"1.3.1","protocolVersion":"2025-06-18"}},{"at":"2026-10-27T15:23:54.882Z","kind":"mcp_initialize","ok":true,"httpStatus":200,"latencyMs":161,"error":null,"detail":{"tools":[{"name":"deep-modules","description":"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 "},{"name":"module-boundaries","description":"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 mo"},{"name":"information-hiding","description":"Checks for information leakage across module boundaries, including temporal decomposition and false encapsulation. Use when modules change together, implementat"},{"name":"pull-complexity-down","description":"Checks whether complexity is pushed to callers or absorbed by implementations — the direction complexity flows. Use when callers must do significant setup, hand"},{"name":"general-vs-special","description":"Evaluates whether interfaces are appropriately general-purpose. Use when checking interface generality, when if-branches or parameters serve only one caller, or"},{"name":"error-design","description":"Reviews error handling and exception design, applying the \"define errors out of existence\" principle. Use when reviewing error handling, when a module throws to"},{"name":"abstraction-quality","description":"Evaluates whether abstractions provide a genuinely different way of thinking or are structurally shallow. Use when adjacent layers feel redundant, wrappers add "},{"name":"naming-obviousness","description":"Reviews naming quality and code obviousness via the isolation test, scope-length principle, and consistency audit. Use when names feel vague, something is hard "},{"name":"comments-docs","description":"Reviews comment quality and documentation practices: the four comment types, comments-first workflow, and comment rot. Use when reviewing comments or docs, when"},{"name":"strategic-mindset","description":"Assesses whether code reflects strategic or tactical thinking, including the 10-20% investment rule and tactical-tornado patterns. Use when evaluating design in"},{"name":"design-it-twice","description":"Generates and compares at least two fundamentally different design alternatives on concrete criteria before committing. Use when the user asks to design somethi"},{"name":"code-evolution","description":"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"},{"name":"complexity-recognition","description":"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 "},{"name":"red-flags","description":"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 "},{"name":"design-review","description":"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 ask"},{"name":"diagnose","description":"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 ski"},{"name":"fetch-reference","description":"Fetch a supporting file from a Clairvoyance skill's references/ folder, when the skill's instructions point to one. Available: information-hiding (back-door-lea"}],"toolCount":17,"toolsHash":"12bee240d22a6d3b37a99ec6dd081d8d180e59f914895aa7f3294a60a5b35361","serverName":"fyi.clairvoyance/mcp","capabilities":["tools","prompts"],"serverVersion":"1.3.1","protocolVersion":"2025-06-18"}},{"at":"2026-10-27T08:25:12.353Z","kind":"mcp_initialize","ok":true,"httpStatus":200,"latencyMs":253,"error":null,"detail":{"tools":[{"name":"deep-modules","description":"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 "},{"name":"module-boundaries","description":"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 mo"},{"name":"information-hiding","description":"Checks for information leakage across module boundaries, including temporal decomposition and false encapsulation. Use when modules change together, implementat"},{"name":"pull-complexity-down","description":"Checks whether complexity is pushed to callers or absorbed by implementations — the direction complexity flows. Use when callers must do significant setup, hand"},{"name":"general-vs-special","description":"Evaluates whether interfaces are appropriately general-purpose. Use when checking interface generality, when if-branches or parameters serve only one caller, or"},{"name":"error-design","description":"Reviews error handling and exception design, applying the \"define errors out of existence\" principle. Use when reviewing error handling, when a module throws to"},{"name":"abstraction-quality","description":"Evaluates whether abstractions provide a genuinely different way of thinking or are structurally shallow. Use when adjacent layers feel redundant, wrappers add "},{"name":"naming-obviousness","description":"Reviews naming quality and code obviousness via the isolation test, scope-length principle, and consistency audit. Use when names feel vague, something is hard "},{"name":"comments-docs","description":"Reviews comment quality and documentation practices: the four comment types, comments-first workflow, and comment rot. Use when reviewing comments or docs, when"},{"name":"strategic-mindset","description":"Assesses whether code reflects strategic or tactical thinking, including the 10-20% investment rule and tactical-tornado patterns. Use when evaluating design in"},{"name":"design-it-twice","description":"Generates and compares at least two fundamentally different design alternatives on concrete criteria before committing. Use when the user asks to design somethi"},{"name":"code-evolution","description":"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"},{"name":"complexity-recognition","description":"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 "},{"name":"red-flags","description":"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 "},{"name":"design-review","description":"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 ask"},{"name":"diagnose","description":"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 ski"},{"name":"fetch-reference","description":"Fetch a supporting file from a Clairvoyance skill's references/ folder, when the skill's instructions point to one. Available: information-hiding (back-door-lea"}],"toolCount":17,"toolsHash":"12bee240d22a6d3b37a99ec6dd081d8d180e59f914895aa7f3294a60a5b35361","serverName":"fyi.clairvoyance/mcp","capabilities":["tools","prompts"],"serverVersion":"1.3.1","protocolVersion":"2025-06-18"}},{"at":"2026-10-27T01:26:31.866Z","kind":"mcp_initialize","ok":true,"httpStatus":200,"latencyMs":226,"error":null,"detail":{"tools":[{"name":"deep-modules","description":"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 "},{"name":"module-boundaries","description":"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 mo"},{"name":"information-hiding","description":"Checks for information leakage across module boundaries, including temporal decomposition and false encapsulation. Use when modules change together, implementat"},{"name":"pull-complexity-down","description":"Checks whether complexity is pushed to callers or absorbed by implementations — the direction complexity flows. Use when callers must do significant setup, hand"},{"name":"general-vs-special","description":"Evaluates whether interfaces are appropriately general-purpose. Use when checking interface generality, when if-branches or parameters serve only one caller, or"},{"name":"error-design","description":"Reviews error handling and exception design, applying the \"define errors out of existence\" principle. Use when reviewing error handling, when a module throws to"},{"name":"abstraction-quality","description":"Evaluates whether abstractions provide a genuinely different way of thinking or are structurally shallow. Use when adjacent layers feel redundant, wrappers add "},{"name":"naming-obviousness","description":"Reviews naming quality and code obviousness via the isolation test, scope-length principle, and consistency audit. Use when names feel vague, something is hard "},{"name":"comments-docs","description":"Reviews comment quality and documentation practices: the four comment types, comments-first workflow, and comment rot. Use when reviewing comments or docs, when"},{"name":"strategic-mindset","description":"Assesses whether code reflects strategic or tactical thinking, including the 10-20% investment rule and tactical-tornado patterns. Use when evaluating design in"},{"name":"design-it-twice","description":"Generates and compares at least two fundamentally different design alternatives on concrete criteria before committing. Use when the user asks to design somethi"},{"name":"code-evolution","description":"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"},{"name":"complexity-recognition","description":"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 "},{"name":"red-flags","description":"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 "},{"name":"design-review","description":"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 ask"},{"name":"diagnose","description":"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 ski"},{"name":"fetch-reference","description":"Fetch a supporting file from a Clairvoyance skill's references/ folder, when the skill's instructions point to one. Available: information-hiding (back-door-lea"}],"toolCount":17,"toolsHash":"12bee240d22a6d3b37a99ec6dd081d8d180e59f914895aa7f3294a60a5b35361","serverName":"fyi.clairvoyance/mcp","capabilities":["tools","prompts"],"serverVersion":"1.3.1","protocolVersion":"2025-06-18"}},{"at":"2026-10-26T18:30:42.830Z","kind":"mcp_initialize","ok":true,"httpStatus":200,"latencyMs":216,"error":null,"detail":{"tools":[{"name":"deep-modules","description":"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 "},{"name":"module-boundaries","description":"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 mo"},{"name":"information-hiding","description":"Checks for information leakage across module boundaries, including temporal decomposition and false encapsulation. Use when modules change together, implementat"},{"name":"pull-complexity-down","description":"Checks whether complexity is pushed to callers or absorbed by implementations — the direction complexity flows. Use when callers must do significant setup, hand"},{"name":"general-vs-special","description":"Evaluates whether interfaces are appropriately general-purpose. Use when checking interface generality, when if-branches or parameters serve only one caller, or"},{"name":"error-design","description":"Reviews error handling and exception design, applying the \"define errors out of existence\" principle. Use when reviewing error handling, when a module throws to"},{"name":"abstraction-quality","description":"Evaluates whether abstractions provide a genuinely different way of thinking or are structurally shallow. Use when adjacent layers feel redundant, wrappers add "},{"name":"naming-obviousness","description":"Reviews naming quality and code obviousness via the isolation test, scope-length principle, and consistency audit. Use when names feel vague, something is hard "},{"name":"comments-docs","description":"Reviews comment quality and documentation practices: the four comment types, comments-first workflow, and comment rot. Use when reviewing comments or docs, when"},{"name":"strategic-mindset","description":"Assesses whether code reflects strategic or tactical thinking, including the 10-20% investment rule and tactical-tornado patterns. Use when evaluating design in"},{"name":"design-it-twice","description":"Generates and compares at least two fundamentally different design alternatives on concrete criteria before committing. Use when the user asks to design somethi"},{"name":"code-evolution","description":"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"},{"name":"complexity-recognition","description":"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 "},{"name":"red-flags","description":"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 "},{"name":"design-review","description":"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 ask"},{"name":"diagnose","description":"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 ski"},{"name":"fetch-reference","description":"Fetch a supporting file from a Clairvoyance skill's references/ folder, when the skill's instructions point to one. Available: information-hiding (back-door-lea"}],"toolCount":17,"toolsHash":"12bee240d22a6d3b37a99ec6dd081d8d180e59f914895aa7f3294a60a5b35361","serverName":"fyi.clairvoyance/mcp","capabilities":["tools","prompts"],"serverVersion":"1.3.1","protocolVersion":"2025-06-18"}},{"at":"2026-10-26T10:31:41.280Z","kind":"mcp_initialize","ok":true,"httpStatus":200,"latencyMs":216,"error":null,"detail":{"tools":[{"name":"deep-modules","description":"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 "},{"name":"module-boundaries","description":"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 mo"},{"name":"information-hiding","description":"Checks for information leakage across module boundaries, including temporal decomposition and false encapsulation. Use when modules change together, implementat"},{"name":"pull-complexity-down","description":"Checks whether complexity is pushed to callers or absorbed by implementations — the direction complexity flows. Use when callers must do significant setup, hand"},{"name":"general-vs-special","description":"Evaluates whether interfaces are appropriately general-purpose. Use when checking interface generality, when if-branches or parameters serve only one caller, or"},{"name":"error-design","description":"Reviews error handling and exception design, applying the \"define errors out of existence\" principle. Use when reviewing error handling, when a module throws to"},{"name":"abstraction-quality","description":"Evaluates whether abstractions provide a genuinely different way of thinking or are structurally shallow. Use when adjacent layers feel redundant, wrappers add "},{"name":"naming-obviousness","description":"Reviews naming quality and code obviousness via the isolation test, scope-length principle, and consistency audit. Use when names feel vague, something is hard "},{"name":"comments-docs","description":"Reviews comment quality and documentation practices: the four comment types, comments-first workflow, and comment rot. Use when reviewing comments or docs, when"},{"name":"strategic-mindset","description":"Assesses whether code reflects strategic or tactical thinking, including the 10-20% investment rule and tactical-tornado patterns. Use when evaluating design in"},{"name":"design-it-twice","description":"Generates and compares at least two fundamentally different design alternatives on concrete criteria before committing. Use when the user asks to design somethi"},{"name":"code-evolution","description":"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"},{"name":"complexity-recognition","description":"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 "},{"name":"red-flags","description":"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 "},{"name":"design-review","description":"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 ask"},{"name":"diagnose","description":"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 ski"},{"name":"fetch-reference","description":"Fetch a supporting file from a Clairvoyance skill's references/ folder, when the skill's instructions point to one. Available: information-hiding (back-door-lea"}],"toolCount":17,"toolsHash":"12bee240d22a6d3b37a99ec6dd081d8d180e59f914895aa7f3294a60a5b35361","serverName":"fyi.clairvoyance/mcp","capabilities":["tools","prompts"],"serverVersion":"1.3.1","protocolVersion":"2025-06-18"}},{"at":"2026-10-26T03:29:52.444Z","kind":"mcp_initialize","ok":true,"httpStatus":200,"latencyMs":152,"error":null,"detail":{"tools":[{"name":"deep-modules","description":"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 "},{"name":"module-boundaries","description":"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 mo"},{"name":"information-hiding","description":"Checks for information leakage across module boundaries, including temporal decomposition and false encapsulation. Use when modules change together, implementat"},{"name":"pull-complexity-down","description":"Checks whether complexity is pushed to callers or absorbed by implementations — the direction complexity flows. Use when callers must do significant setup, hand"},{"name":"general-vs-special","description":"Evaluates whether interfaces are appropriately general-purpose. Use when checking interface generality, when if-branches or parameters serve only one caller, or"},{"name":"error-design","description":"Reviews error handling and exception design, applying the \"define errors out of existence\" principle. Use when reviewing error handling, when a module throws to"},{"name":"abstraction-quality","description":"Evaluates whether abstractions provide a genuinely different way of thinking or are structurally shallow. Use when adjacent layers feel redundant, wrappers add "},{"name":"naming-obviousness","description":"Reviews naming quality and code obviousness via the isolation test, scope-length principle, and consistency audit. Use when names feel vague, something is hard "},{"name":"comments-docs","description":"Reviews comment quality and documentation practices: the four comment types, comments-first workflow, and comment rot. Use when reviewing comments or docs, when"},{"name":"strategic-mindset","description":"Assesses whether code reflects strategic or tactical thinking, including the 10-20% investment rule and tactical-tornado patterns. Use when evaluating design in"},{"name":"design-it-twice","description":"Generates and compares at least two fundamentally different design alternatives on concrete criteria before committing. Use when the user asks to design somethi"},{"name":"code-evolution","description":"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"},{"name":"complexity-recognition","description":"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 "},{"name":"red-flags","description":"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 "},{"name":"design-review","description":"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 ask"},{"name":"diagnose","description":"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 ski"},{"name":"fetch-reference","description":"Fetch a supporting file from a Clairvoyance skill's references/ folder, when the skill's instructions point to one. Available: information-hiding (back-door-lea"}],"toolCount":17,"toolsHash":"12bee240d22a6d3b37a99ec6dd081d8d180e59f914895aa7f3294a60a5b35361","serverName":"fyi.clairvoyance/mcp","capabilities":["tools","prompts"],"serverVersion":"1.3.1","protocolVersion":"2025-06-18"}},{"at":"2026-10-25T20:28:42.349Z","kind":"mcp_initialize","ok":true,"httpStatus":200,"latencyMs":236,"error":null,"detail":{"tools":[{"name":"deep-modules","description":"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 "},{"name":"module-boundaries","description":"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 mo"},{"name":"information-hiding","description":"Checks for information leakage across module boundaries, including temporal decomposition and false encapsulation. Use when modules change together, implementat"},{"name":"pull-complexity-down","description":"Checks whether complexity is pushed to callers or absorbed by implementations — the direction complexity flows. Use when callers must do significant setup, hand"},{"name":"general-vs-special","description":"Evaluates whether interfaces are appropriately general-purpose. Use when checking interface generality, when if-branches or parameters serve only one caller, or"},{"name":"error-design","description":"Reviews error handling and exception design, applying the \"define errors out of existence\" principle. Use when reviewing error handling, when a module throws to"},{"name":"abstraction-quality","description":"Evaluates whether abstractions provide a genuinely different way of thinking or are structurally shallow. Use when adjacent layers feel redundant, wrappers add "},{"name":"naming-obviousness","description":"Reviews naming quality and code obviousness via the isolation test, scope-length principle, and consistency audit. Use when names feel vague, something is hard "},{"name":"comments-docs","description":"Reviews comment quality and documentation practices: the four comment types, comments-first workflow, and comment rot. Use when reviewing comments or docs, when"},{"name":"strategic-mindset","description":"Assesses whether code reflects strategic or tactical thinking, including the 10-20% investment rule and tactical-tornado patterns. Use when evaluating design in"},{"name":"design-it-twice","description":"Generates and compares at least two fundamentally different design alternatives on concrete criteria before committing. Use when the user asks to design somethi"},{"name":"code-evolution","description":"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"},{"name":"complexity-recognition","description":"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 "},{"name":"red-flags","description":"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 "},{"name":"design-review","description":"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 ask"},{"name":"diagnose","description":"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 ski"},{"name":"fetch-reference","description":"Fetch a supporting file from a Clairvoyance skill's references/ folder, when the skill's instructions point to one. Available: information-hiding (back-door-lea"}],"toolCount":17,"toolsHash":"12bee240d22a6d3b37a99ec6dd081d8d180e59f914895aa7f3294a60a5b35361","serverName":"fyi.clairvoyance/mcp","capabilities":["tools","prompts"],"serverVersion":"1.3.1","protocolVersion":"2025-06-18"}}],"tools":[{"name":"deep-modules","description":"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 "},{"name":"module-boundaries","description":"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 mo"},{"name":"information-hiding","description":"Checks for information leakage across module boundaries, including temporal decomposition and false encapsulation. Use when modules change together, implementat"},{"name":"pull-complexity-down","description":"Checks whether complexity is pushed to callers or absorbed by implementations — the direction complexity flows. Use when callers must do significant setup, hand"},{"name":"general-vs-special","description":"Evaluates whether interfaces are appropriately general-purpose. Use when checking interface generality, when if-branches or parameters serve only one caller, or"},{"name":"error-design","description":"Reviews error handling and exception design, applying the \"define errors out of existence\" principle. Use when reviewing error handling, when a module throws to"},{"name":"abstraction-quality","description":"Evaluates whether abstractions provide a genuinely different way of thinking or are structurally shallow. Use when adjacent layers feel redundant, wrappers add "},{"name":"naming-obviousness","description":"Reviews naming quality and code obviousness via the isolation test, scope-length principle, and consistency audit. Use when names feel vague, something is hard "},{"name":"comments-docs","description":"Reviews comment quality and documentation practices: the four comment types, comments-first workflow, and comment rot. Use when reviewing comments or docs, when"},{"name":"strategic-mindset","description":"Assesses whether code reflects strategic or tactical thinking, including the 10-20% investment rule and tactical-tornado patterns. Use when evaluating design in"},{"name":"design-it-twice","description":"Generates and compares at least two fundamentally different design alternatives on concrete criteria before committing. Use when the user asks to design somethi"},{"name":"code-evolution","description":"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"},{"name":"complexity-recognition","description":"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 "},{"name":"red-flags","description":"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 "},{"name":"design-review","description":"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 ask"},{"name":"diagnose","description":"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 ski"},{"name":"fetch-reference","description":"Fetch a supporting file from a Clairvoyance skill's references/ folder, when the skill's instructions point to one. Available: information-hiding (back-door-lea"}],"package":null,"toolSurface":{"id":"ts_gpuuruvj8d5h","endpointId":"ep_mjevanuhe3cj","hash":"12bee240d22a6d3b37a99ec6dd081d8d180e59f914895aa7f3294a60a5b35361","toolCount":17,"serverName":"fyi.clairvoyance/mcp","serverVersion":"1.3.1","protocolVersion":"2025-06-18","firstSeenAt":"2026-10-09T15:33:31.980Z","lastSeenAt":"2026-10-28T12:25:46.261Z","observations":68,"toolNames":["deep-modules","module-boundaries","information-hiding","pull-complexity-down","general-vs-special","error-design","abstraction-quality","naming-obviousness","comments-docs","strategic-mindset","design-it-twice","code-evolution","complexity-recognition","red-flags","design-review","diagnose","fetch-reference"],"distinctSurfaces":1},"endpointFacts":[{"id":"ep_mjevanuhe3cj","url":"https://clairvoyance.fyi/mcp","type":"mcp_streamable_http","factsCheckedAt":"2026-10-26T18:30:42.842Z","auth":{"observedAt":"2026-10-26T18:30:42.886Z","authRequired":false,"scheme":null,"resourceMetadata":null,"authorizationServer":null,"conformance":{"dpop":false,"rfc8414":false,"rfc9728":false,"pkceS256":false,"clientIdMetadataDocument":false,"dynamicClientRegistration":false}},"tls":{"observedAt":"2026-10-26T18:30:42.930Z","protocol":"TLSv1.3","chainValid":true,"chainError":null,"hostMatches":true,"subject":"clairvoyance.fyi","issuer":{"commonName":"YE1","organization":"Let's Encrypt"},"validFrom":"2026-10-21T06:31:48.000Z","validTo":"2027-01-19T06:31:47.000Z","daysToExpiry":82,"sanCount":2,"fingerprint256":"61:73:91:FB:01:CF:8A:0D:2B:31:6C:2A:73:9C:E5:B6:67:25:15:77:24:37:31:D5:B6:A1:23:9D:D6:E1:B3:ED"}}]},"verification":{"claimed":false,"claimedAt":null,"proofs":[]},"provenance":{"sources":[{"source":"ard_catalog","key":"urn:air:clairvoyance.fyi:mcp:clairvoyance","url":"https://clairvoyance.fyi/.well-known/ard.json","firstSeenAt":"2026-10-09T15:27:15.526Z","fetchedAt":"2026-10-09T15:27:15.526Z","normalizedAt":"2026-10-09T15:27:15.526Z"},{"source":"mcp_registry","key":"fyi.clairvoyance/mcp","url":"https://registry.modelcontextprotocol.io/v0/servers/fyi.clairvoyance%2Fmcp","firstSeenAt":"2026-10-09T15:19:38.883Z","fetchedAt":"2026-10-25T16:18:16.005Z","normalizedAt":"2026-10-25T16:18:16.005Z"}]},"firstSeenAt":"2026-10-09T15:19:38.883Z","updatedAt":"2026-10-28T12:30:35.308Z"}