原型 · 预览版:收录官方注册中心里的全部服务器,每 30 分钟同步一次。评价和账户功能将在后续阶段推出。
PopNx MCP为使用 AI 的人准备的 MCP 服务器 · 用大白话讲清楚

Sighttrue

作者:kaitzyy-dev版本 1.0.0i★ –i在云端运行
注册名称io.github.kaitzyy-dev/sighttrue

安装

概览

作者提供的说明(英文原文)

Measured readings on open-source dependencies: health, end-of-life, model prices, incidents.

PopNx MCP 的三大支柱

这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。

它能帮你做什么

我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。

  • 连接方式: 在云端运行
  • 传输方式: Streamable HTTP
  • 分类: 诊所与健康

安装

选择你使用的 AI 应用,然后复制设置。

安装之前

你需要

你用的是哪个应用?

在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。

适用于网页版、桌面版和手机版 Claude:

  1. 打开 Settings → Connectors
  2. 点击 Add custom connector
  3. 粘贴下面的地址,然后点击 Add
  4. 如果要求登录,请登录作者的服务
SettingsConnectors1+ Add2https://…3
https://sighttrue.com/api/mcp

在终端中运行这条命令

claude mcp add --transport http sighttrue https://sighttrue.com/api/mcp

在 Cursor 中打开

或者自己复制设置

粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json

{
  "mcpServers": {
    "sighttrue": {
      "url": "https://sighttrue.com/api/mcp"
    }
  }
}

浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。

在 VS Code 中打开

或者自己复制设置

粘贴到项目中的 .vscode/mcp.json

{
  "servers": {
    "sighttrue": {
      "type": "http",
      "url": "https://sighttrue.com/api/mcp"
    }
  }
}

浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。

ChatGPT 只能连接互联网上的服务器:

  1. 打开网页版 ChatGPT → Settings → Connectors (Apps)
  2. 点击 Create 或 Add(部分套餐需要先在 Advanced 中开启 Developer mode)
  3. 粘贴下面的地址,起个名字,然后保存
  4. 如果要求登录,请登录作者的服务
SettingsConnectors1+ Create2https://…3
https://sighttrue.com/api/mcp

菜单名称可能因套餐和版本不同而略有差异。

你的选择通过 Cookie 保存在这台设备上,无需账户。

这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。

它能做什么

我们还没有读取这个服务器的工具列表;我们会轮流检查各个端点。

基础检查i

我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月6日

  • ✓ 通过

    作者与仓库一致

    注册名称已通过 GitHub 账户 kaitzyy-dev 验证,该账户拥有此仓库

  • … 尚未检查

    仍在维护

    我们还没有从 GitHub 读取这个仓库

  • … 尚未检查

    有许可证

    我们还没有从 GitHub 读取这个仓库

  • … 尚未检查

    端点有响应

    尚未检查;我们会轮流检查各个端点

  • … 尚未检查

    使用 OAuth 登录

    尚未检查;我们会轮流检查各个端点

  • … 尚未检查

    工具描述中没有隐藏指令

    尚未检查;我们会在检查端点时读取工具列表

与“诊所与健康”中的其他服务器比较i

  • 星标数多于此分类中其他 860 个服务器的 0%
  • 发布到注册中心的时间比此分类中其他 860 个服务器的 29% 更新
  • 基础检查结果等于或优于此分类中其他 860 个服务器的 100%

与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。

常见问题

Sighttrue 安全吗?

它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。

它需要哪些密钥或代码?

注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。

它在我的电脑上运行还是在云端?

它在作者的云端运行。通过互联网连接,无需安装,但你发送的内容会经过作者的服务器。

它还在维护吗?

GitHub 仓库最后更新于–,最新版本(1.0.0)于3个月前进入注册中心。

哪些应用可以使用它?

支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。它通过 URL 连接,所以接受远程 MCP 服务器的应用也可以使用,例如开启开发者模式的 ChatGPT。

有什么可以替代它?

同一分类中有:Mirobody, FHIR MCP Server, Google Health MCP

替代选择

同一分类中其他作者的服务器,按星标数排序。

如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i

Mirobody

作者:thetahealth

Lab results to LOINC codes and UCUM units, symptoms and diagnoses to ICPC-3. Offline, no API key.

在你的电脑上运行★ 1,408Apache-2.05天前更新
安装

FHIR MCP Server

作者:wso2

MCP server providing seamless access to FHIR APIs for AI tools and healthcare applications

在你的电脑上运行★ 137Apache-2.08天前更新
安装

Google Health MCP

作者:davidmosiah

Privacy-first unofficial Google Health API v4 MCP server for health, sleep, activity, HR agents

在你的电脑上运行★ 79MIT4个月前更新
安装

作者的 README

打开 README

按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。

Sighttrue

[sighttrue.com](https://sighttrue.com) · your stack · compare · method · feed

Check your dependencies in CI

permissions:

pull-requests: write # only needed for the comment

steps:

  • uses: actions/checkout@v4
  • uses: sighttrue/sighttrue@v1 with: manifest: package.json fail-on: withdrawn,archived,relicensed

Fails the build when a dependency's own publisher has withdrawn it — npm calls it deprecated, PyPI and crates.io call it yanked, RubyGems yanked, Packagist abandoned, NuGet deprecated — or when its repository has been archived or moved to a source-available licence, and reports advisories either way. Reads package.json, requirements.txt, pyproject.toml, Cargo.toml, composer.json and Gemfile. No key, no account, no service to sign up to — it reads published measurements and talks to OSV. A network problem is never a finding: if the readings cannot be fetched the step says so and passes, because a build that breaks when somebody else's site is down is a build that gets deleted.

On a pull request it also leaves a comment with the findings as a table, and rewrites that same comment on every push rather than adding another. A red build tells a reviewer that something is wrong; it does not tell them which dependency, or what changed about it, without opening the log. Set comment: false to report only in the step summary. A pull request from a fork gets a read-only token, so the comment is skipped there and the step still passes.

Also runs against requirements.txt and Cargo.toml.

Or install the App and change nothing

The Action needs a workflow file in every repository that wants it. The GitHub App needs one install and then watches every repository it is given, with no workflow, no key and no configuration: when a pull request adds a runtime dependency that is on the watchlist, it leaves one comment with what is on record — downloads, OpenSSF scorecard, advisory count, licence, last push — and edits that same comment on every later push.

It says nothing at all when a pull request changes no manifest, adds no dependency, or adds nothing that is tracked. That is the common case and it is the point: a bot that comments to say it found nothing gets uninstalled. It never calls a package safe, unsafe or recommended, because none of those are things this project measures.

The Action fails a build; the App only reports. Both read the same published bundle, so they cannot disagree.

An SBOM you are allowed to hand over

/stack exports the readout as a CycloneDX 1.6 document, with each dependency's advisory count, scorecard, licence, publish date and bus factor attached as properties. Built in the browser from the pasted manifest, like everything else on that page — nothing is uploaded, and there is no endpoint to send a manifest to.

It states no versions. A manifest declares ^1.6.0; it does not say what was installed, and it says nothing about the transitive tree underneath. The document says both of those things in its own metadata rather than leaving a reader to notice, because an SBOM that guessed would be worse than none: a compliance artefact asserting something nobody resolved.

Suggest something to watch

The watchlist is curated and partial, and it was chosen by hand with no method beyond judgement — its weakest point. Open an issue to argue for a repository. Every change to the list is a reviewed commit, so that issue is where the review happens.

For coding agents

An MCP server over the same readings, so an agent can answer "is this dependency healthy" from a measurement taken today rather than from training data a year old.

{ "mcpServers": { "readout": { "url": "https://sighttrue.com/api/mcp" } } }

Nine tools free, twenty-two paid. check_before_install is the one to reach for while writing code: given a package it returns only what a reviewer would be annoyed to discover afterwards — a publisher that withdrew it, scripts it runs on the installing machine, an archived repository, advisories, a source-available licence, a long silence — each with the address of the body that published it. It does not say whether to install. It says what is on record so the decision is made knowing it, and an empty result says plainly that it means nothing was found rather than that the package is safe.

Then check_package, check_stack, search_repositories, compare_repositories, find_model, check_eol, check_provider, list_readings . Read-only, no key, no account. Every result carries the limits of what it can support, because an agent will paste these figures into a code review and a scorecard quoted without "measures declared practices, not whether the project is safe" is a claim this project does not make.

Without MCP, one GET returns the same thing:

curl 'https://sighttrue.com/api/verdict?pkg=npm:axios'

curl 'https://sighttrue.com/api/verdict?pkg=pypi:django&version=4.2'

Advisories, licence, when the registry last shipped it, the bus factor, and whether the release is still supported — each with the address of the body that published it, so a figure quoted into a review can be checked in one click. Despite the name there is no verdict in it: no score, no rank, no recommendation. Those would be this project's judgement of somebody else's work wearing the costume of a measurement.

One agent watches 417 open-source repositories and takes eleven readings, most of which never touch GitHub: 807 provider incidents kept after their own status pages dropped them, 522 release lines on the end-of-life clock, 382 model prices, 182 packages by real ship date, 416 commit histories for the bus factor. It runs every four hours on GitHub Actions, commits what it reads to this repository, and publishes a static site.

Every page and every bundle is a file. There are five dynamic routes and no page depends on any of them: /api/ask, /api/mcp, /api/chain, /api/github/webhook for the App, and the sign-in and watchlist endpoints under /api/auth and /api/watchlist. Signing in with GitHub saves a watchlist and nothing else — the readings on a signed-in page are the same published bundle anyone can download.

The commit history of data/ is the point. It is an audit trail: every reading is timestamped, append-only, and checkable against GitHub directly.

What it reports

Eleven readings, each named by the question it answers rather than by the collector that produces it. The same list drives the site's navigation, so the two cannot drift — they had, three times over, before it was written down once.

ReadingQuestion it answersTouches GitHub
LiveWhat changed in the last few hours?yes
ShipsWhat released a new version?yes
ForksWhat is being copied faster than its own baseline?yes
DemandWhat are developers asking for, across more than one project?yes
DependenciesWhat is being added, dropped, or jumped a major version?yes
LineageWhich models say they were built on which?no
Model pricesWhat does a million tokens cost, and when did that change?no
OutagesDoes the thing I depend on go down, and how often?no
EcosystemWhat do the registries, advisories and forums say?no
Depended onWhat does everything else quietly rely on?no
This weekWhat would I have missed looking once a week?—

The six that never touch GitHub are the answer to the fair complaint that a GitHub summariser is worth only what GitHub already shows you.

Whether each detector's threshold is reachable at all is published too, on the index under Our record. A detector nothing has ever come close to is not a quiet detector, it is a misconfigured one, and the site says so about itself.

How to read it

Every comparison is against a repository's own history, not against other repositories. "27× baseline" means 27 times what that project normally does, and the baseline is drawn on the chart so you can see what normal means.

Confidence is stated, never implied.

StateMeaning
formingUnder 14 days of history. Raw counts only. No multiplier is computed and none is implied.
detectedCrossed the threshold once. Neutral treatment.
confirmedPersisted across two consecutive daily snapshots.

Only confirmed signals are treated as findings. That costs up to a day of speed and buys the thing that cannot be bought back.

Generated prose is set in a different typeface from measured values. Where a sentence explains a number, every figure in that sentence is checked against the source record before it is published; if any of them is not in the record, the sentence is discarded and a templated one is used instead.

What this does not claim

  • The watchlist is curated and partial. It is chosen by hand and is not a survey of open source. Dependency and demand findings describe the repositories being watched, not the ecosystem.
  • The data is not real-time. Four hours is the floor, and scheduled runs are routinely delayed.
  • Nothing here predicts anything, and nothing here says a repository is good, bad, safe, or unsafe.
  • Appearing on the watchlist is an observation, not a relationship. No project listed here has endorsed this.

Published findings that turn out to be wrong are superseded by a correction event carrying the same prominence. Events are never deleted and history is never rewritten.

The data

Every bundle the site reads is served as JSON, so any claim can be checked against the same file the page used.

data/

├── live/state.jsonl Latest reading per repository. Sorted, rewritten each pulse. ├── live/window.jsonl Timestamped fork samples, for the rolling 24h delta. ├── live/manifests.jsonl Last-seen dependency set, diffed daily. ├── history/YYYY-MM-DD.jsonl One immutable snapshot per day. ├── events/YYYY-MM.jsonl Append-only. Never rewritten, never pruned. ├── summaries.jsonl Generated prose, keyed by event id. ├── watchlist.jsonl What is watched, and since when. └── meta.json Last run status.

Files are sorted with a fixed key order so a repository that did not change produces no diff. That is what keeps a repository committed to six times a day from growing without bound.

Running it

Node 24. Types are stripped natively, so there is no build step and no runtime dependencies.

It said 22.18+ until the D1 schema arrived. The tests load migrations/ into node:sqlite, which is stable in 24 and behind a flag in 22 — so on 22 the suite fails on an import rather than on an assertion, which is a confusing way to learn a version requirement.

npm install          # dev dependencies only: typescript, vitest, fonts

npm test npm run typecheck

node scripts/pulse.ts --limit=20 # needs GITHUB_PAT node scripts/daily.ts node scripts/build.ts # emits dist/

Watchlist maintenance

The watchlist is curated. Deriving it from a search query was tried and produced a worse list — topic search only finds repositories that tagged themselves, and sorting by stars ranks tutorials and link collections above infrastructure. derive-watchlist.ts is kept for proposing candidates a curator might have missed, and because the negative result is worth being able to reproduce.

node scripts/verify-watchlist.ts   # check every entry against the API

node scripts/retire-watchlist.ts # mark archived and deleted ones inactive node scripts/derive-watchlist.ts # propose candidates, writes n

只显示了开头部分;其余内容请在仓库中阅读

问 PopNx