Mirobody
Lab results to LOINC codes and UCUM units, symptoms and diagnoses to ICPC-3. Offline, no API key.
Descripción del creador (original en inglés)
Measured readings on open-source dependencies: health, end-of-life, model prices, incidents.
Estos tres nunca se combinan en una sola puntuación: las opiniones, las mediciones y la popularidad son cosas distintas.
Todavía no escribimos un resumen sencillo para este. Abajo están los datos que leímos del registro.
Elige la app de IA que usas y copia la configuración.
Necesitas
¿Qué app usas?
Elige tu app arriba. La recordamos, así que la próxima vez el botón dirá “Instalar en …”.
Funciona en Claude para web, escritorio y móvil:
https://sighttrue.com/api/mcpEjecuta esto en tu terminal
claude mcp add --transport http sighttrue https://sighttrue.com/api/mcpPégalo en .cursor/mcp.json de tu proyecto, o en ~/.cursor/mcp.json
{
"mcpServers": {
"sighttrue": {
"url": "https://sighttrue.com/api/mcp"
}
}
}Tu navegador te pide permiso para abrir la app; luego la app muestra la configuración y te pide confirmar. Los valores de las claves quedan vacíos para que los completes tú.
Pégalo en .vscode/mcp.json de tu proyecto
{
"servers": {
"sighttrue": {
"type": "http",
"url": "https://sighttrue.com/api/mcp"
}
}
}Tu navegador te pide permiso para abrir la app; luego la app muestra la configuración y te pide confirmar. Los valores de las claves quedan vacíos para que los completes tú.
ChatGPT solo se conecta a servidores en internet:
https://sighttrue.com/api/mcpLos nombres de los menús pueden variar un poco según el plan y con el tiempo.
Tu elección se guarda en una cookie en este dispositivo; no necesitas cuenta.
Esta configuración se genera a partir de la ficha del creador en el registro. Si el README dice otra cosa, sigue el README.
Todavía no hemos leído la lista de herramientas de este servidor; revisamos los endpoints por turnos.
Revisamos información que cualquiera puede ver; no hemos leído el código. Las revisiones que no aplican no se cuentan. · Revisado el 6 nov 2026
El nombre en el registro se verificó con la cuenta de GitHub kaitzyy-dev, dueña del repo
Todavía no hemos leído este repo en GitHub
Todavía no hemos leído este repo en GitHub
Aún sin revisar; revisamos los endpoints por turnos
Aún sin revisar; revisamos los endpoints por turnos
Aún sin revisar; leemos la lista de herramientas cuando revisamos el endpoint
Comparado con todos los servidores activos de esta categoría en el registro. Las estrellas solo cuentan cuando quien lo publica es dueño del repo.
Superó 1 de 1 revisiones básicas aplicables. No hemos leído el código. Antes de agregar una clave o un token, revisa qué acceso pide el servidor y usa una clave que tenga solo los permisos que necesitas.
El registro no indica ninguna clave obligatoria, aunque algunos servidores te piden iniciar sesión la primera vez que los usas.
Se ejecuta en la nube del creador. Te conectas por internet sin instalar nada, pero lo que envías pasa por los servidores del creador.
El repo de GitHub cambió por última vez –, y la última versión (1.0.0) llegó al registro hace 3 meses.
Las apps compatibles con MCP, como Claude Desktop, Claude Code, Cursor y VS Code. Se conecta por URL, así que también funcionan las apps que aceptan servidores MCP remotos, como ChatGPT en modo desarrollador.
En la misma categoría: Mirobody, FHIR MCP Server, Google Health MCP
Servidores de la misma categoría hechos por otros creadores, ordenados por estrellas.
Cómo leer una tarjeta:★ Estrellas de GitHubiTres pilares: reseñas · revisiones · usoiActualizado = fecha en que se publicó la última versión en el registroi
Lab results to LOINC codes and UCUM units, symptoms and diagnoses to ICPC-3. Offline, no API key.
MCP server providing seamless access to FHIR APIs for AI tools and healthcare applications
Privacy-first unofficial Google Health API v4 MCP server for health, sleep, activity, HR agents
Copiado tal cual del repo del creador. PopNx MCP no lo ha revisado ni lo respalda. Se quitaron HTML, imágenes y scripts. Los enlaces llevan fuera de este sitio.
[sighttrue.com](https://sighttrue.com) · your stack · compare · method · feed
permissions:
pull-requests: write # only needed for the comment
steps:
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.
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.
/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.
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.
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.
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.
| Reading | Question it answers | Touches GitHub |
|---|---|---|
| Live | What changed in the last few hours? | yes |
| Ships | What released a new version? | yes |
| Forks | What is being copied faster than its own baseline? | yes |
| Demand | What are developers asking for, across more than one project? | yes |
| Dependencies | What is being added, dropped, or jumped a major version? | yes |
| Lineage | Which models say they were built on which? | no |
| Model prices | What does a million tokens cost, and when did that change? | no |
| Outages | Does the thing I depend on go down, and how often? | no |
| Ecosystem | What do the registries, advisories and forums say? | no |
| Depended on | What does everything else quietly rely on? | no |
| This week | What 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.
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.
| State | Meaning |
|---|---|
forming | Under 14 days of history. Raw counts only. No multiplier is computed and none is implied. |
detected | Crossed the threshold once. Neutral treatment. |
confirmed | Persisted 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.
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.
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.
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/
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
Solo se muestra el principio; lee el resto en el repo