DEV Community: Edison Flores

Verificado en marzo no es evidencia sobre abril: 4 lecciones de diseño para bundles de confianza entre agentes

Edison Flores — Mon, 21 Sep 2026 00:18:34 +0000

Una propuesta de integración reciente en LlamaIndex — exportar e importar paquetes de memoria sellados (sealed memory bundles) — toca exactamente el problema que operamos a diario: llevar estado verificado entre agentes. Mantenemos un protocolo de tarjetas de confianza (trust cards) para verificación agente-a-agente, donde los bundles sellados y portables son el artefacto central. Cuatro lecciones que aprendimos por las malas, aplicables directamente a esa propuesta y a cualquier diseño similar propio.

1. Fija el reloj, o tus intervalos de validez son re Jugables

Que algo fue "verificado en marzo" solo constituye evidencia sobre abril si la marca de tiempo de la verificación es, ella misma, un objeto de confianza. Si el importador evalúa la validez contra su reloj local de pared, el bundle sigue siendo re jugable entre hosts con desviación de reloj o con el reloj manipulado.

Lo que nos funcionó fue un solo cambio: registrar un evaluation_clock explícito junto a cada resultado de verificación, y evaluar contra esa referencia fijada — nunca contra el reloj local del importador. Con eso, los intervalos de validez dejan de ser re Jugables. Es la misma estructura de riesgo del rug pull de herramientas (te confías de una definición que ya cambió), pero aplicada al tiempo: el "momento en que verificaste" también es superficie de ataque.

2. Limita la evidencia, hashea el resto

Los recibos por memoria (comando ejecutado, resultado, código de salida, hash de salida) crecen sin cota. Un mes de evidencia de un agente ocupado vuelve el bundle intransportable.

El patrón viable: guardar un extracto de salida con tope de tamaño más el hash del recibo completo, y mantener los recibos completos fuera de banda (out-of-band), disponibles solo para resolución de disputas. Separar "que exista evidencia" de "transportar la evidencia siempre" mantiene el bundle pequeño y la verificación completa.

3. Prueba el importador adversarialmente

El parser de un bundle sellado es una decisión de confianza ejecutada sobre entrada no confiable: tiene exactamente la forma de ataque del tool poisoning. Nosotros generamos bundles mutados (mutaciones de dos puntos a través de fronteras firmadas) y exigimos que el importador rechace todos antes de llamar "implementado" al formato. El modelo observed-until-reverified solo gana su nombre si la propia ruta de reverificación sobrevive entrada adversarial.

4. No hagas que la validez del bundle dependa de confiar en el exportador

Anclar los digestos del bundle en un registro público de transparencia (estilo Rekor) más una cadena de releases firmada da verificabilidad por terceros y una historia de revocación sin autoridad central — y mapea limpio sobre custodia multi-salto, donde las firmas por salto se degradan al acumularse. El anclaje público no se degrada.

La pregunta que queda abierta: frescura de identidad

Cuando el exportador rota llaves, un bundle viejo sigue siendo criptográficamente válido. Observed-until-reverified cubre la frescura del contenido — pero ¿quién cubre la frescura de la identidad? ¿Un bundle firmado por una llave ya rotada sigue siendo importable, y quién decide? No he visto aún una respuesta de diseño a esto, y me parece que ahí hay un terreno vacío.

Artefactos públicos

Lo concreto detrás de las lecciones 1 a 4 está publicado y es verificable por cualquiera:

Repositorio: https://github.com/alicelabs-llc/universal-trust-adapter
Índice de vectores de conformance (regla de reloj fijado + distribuciones adversariales): https://www.marketnow.site/uta/conformance/vectors/_index.json
SDK de verificación offline (solo node:crypto, registro de llaves CA embebido): https://www.npmjs.com/package/agent-trust-card

Preguntas y objeciones en español bienvenidas — especialmente si alguien tiene una respuesta de diseño para la frescura de identidad.

「検証済み」は「今も有効」を意味しない — エージェント間のトラストバンドル設計で学んだ4つの教訓

Edison Flores — Mon, 21 Sep 2026 00:17:02 +0000

LlamaIndexに最近投稿された統合提案 — シールドされたメモリバンドルのエクスポート/インポート — は、エージェント間で検証済みの状態を持ち回るという問題領域そのものです。私たちはエージェント間検証のためのTrust Cardプロトコルを運用しており、シール済みでポータブルなバンドルはその中核アーティファクトです。運用の中で痛い目を見て学んだ4つの教訓を、この提案（そして自分のバンドル設計）に直接適用できる形で共有します。

1. クロックをピンしないと、有効性期間はリプレイ可能のまま

「3月に検証済み」が「4月についての証拠」であるためには、検証タイムスタンプ自体が信頼対象になっていなければなりません。インポータが自ホストのローカル時計に対して有効性を評価する設計だと、バンドルはクロックスキューした環境や時計を操作されたホスト間でいくらでもリプレイできます。

私たちに効いた変更は1つでした。検証結果の隣に明示的な evaluation_clock を記録し、インポータのローカル時間ではなく、そのピンされた参照時刻に対して有効性を評価する。これだけで有効期間はリプレイ耐性を持ちます。

Qiitaでよく見かけるTool Poisoning・Rug Pull・Shadow MCPという3リスクの分類に当てはめると、これは「検証した時点」そのものを攻撃面として扱う話です。ツール定義が後から差し替えられる（Rug Pull）のと同じ構造が、時刻の側にも存在します。

2. 証拠はキャップし、残りはハッシュで

メモリごとのレシート（コマンド、結果、終了コード、出力ハッシュ）は際限なく成長します。稼働中のエージェント1ヶ月分の証拠だけで、バンドルは配送不可能なサイズになります。

実用的なパターンはこうです。サイズ上限付きの出力抜粋に加えて、完全なレシートのハッシュを保存する。完全なレシート自体は帯域外（out-of-band）に置き、紛争解決時にだけ取り出す。「証拠があること」と「証拠を常に運搬すること」を分離すれば、バンドルは小さく、検証は完全なままです。

3. インポータを敵対的にテストする

シールドされたバンドルのパーサは、信頼できない入力に対して信頼の決定を実行するコードです。つまりtool poisoningと同じ攻撃形状を持ちます。

私たちのやり方は、署名境界をまたぐ2点変異バンドルを機械的に生成し、インポータがそれら全てを拒否することをリリース条件にすることです。「実装した」と言えるのは、この敵対的入力テストを通過した後だけにすべきです。observed-until-reverified（再検証まで観測済み扱い）というモデルは、再検証パス自体が敵対的入力で生き残って初めて名前に値します。

4. バンドルの妥当性を、エクスポータへの信頼に依存させない

バンドルのダイジェストを公開の透過性ログ（Rekor風）にアンカリングし、署名済みリリースチェーンと組み合わせると、中央機関なしで第三者検証と失効のストーリーが得られます。これはマルチホップのコスト・オブ・カストディ（多段の保管責任）にもきれいにマップします。ホップごとの署名だけでは、段数が増えると担保が劣化しますが、公開ログへのアンカリングは劣化しません。

残る問い：識別の鮮度

鍵ローテーションを考えると、古い鍵で署名されたバンドルは回転後も暗号学的には有効です。observed-until-reverifiedはコンテンツの鮮度をカバーしますが、識別（identity）の鮮度は誰が、どう決めるのでしょうか。ローテーション済みの鍵で署名されたバンドルはインポート可能のままか。この質問への答えをまだ見たことがなく、それ自体が設計上の空き地だと思っています。

アーティファクトは全て公開

上記1〜4の背後にある具体的な成果物は公開されています。ピンされたクロック規則と敵対的ウィンドウ分布を含むコンフォーマンスベクトルと、リファレンスランナー（MIT）:

リポジトリ: https://github.com/alicelabs-llc/universal-trust-adapter
ベクトルインデックス: https://www.marketnow.site/uta/conformance/vectors/_index.json
オフライン検証SDK（node:cryptoのみ、CA鍵レジストリ埋め込み）: https://www.npmjs.com/package/agent-trust-card

日本語での質問・ツッコミ歓迎です。特に「識別の鮮度」の問いに対する設計回答を持っている方はぜひ。

Your AI agent connects to MCP servers it has never met. Verify them first — for free.

Edison Flores — Sun, 20 Sep 2026 03:17:24 +0000

Your AI agent connects to MCP servers it has never met. Here's how to verify them first — for free.

Modern agents are extroverts by design. Give them a URL, and they'll initialize an MCP session, list the tools, and start calling them. Nothing in the protocol asks the boring questions first: who runs this server? how old is this domain? did the tool definition change since yesterday? The OWASP GenAI MCP Cheat Sheet lists exactly these risks — tool poisoning, prompt injection through tool descriptions, and rug-pull servers. Most teams react after an incident. The boring alternative is a pre-flight check that takes seconds and costs nothing.

This post shows a working pre-flight stack you can add to any MCP client today: a domain scam-check, tool fingerprinting, credential verification, and a registry to search — all through one free remote endpoint (no API key, no signup, nothing to install).

Step 0 — the endpoint

Everything below is served by one MCP server:

{
  "mcpServers": {
    "marketnow": { "url": "https://www.marketnow.site/api/mcp" }
  }
}

That block works in Cursor, Cline, Claude, and anything else speaking MCP. A live handshake returns serverInfo: marketnow-mcp v1.13.0 and nine tools. If you don't want to touch your MCP config, the same functions are plain REST:

curl -s 'https://www.marketnow.site/api/scam-check?domain=github.com'

Step 1 — check the domain before you connect

The scam-checker runs eight checks per domain: six static heuristics (URL shorteners, suspicious TLDs, punycode, typosquatting, subdomain abuse, suspicious tokens) and two live server-side checks — registry age via RDAP and TLS certificate inspection. This is the real output for github.com:

{
  "domain": "github.com",
  "decision": "TRUSTED",
  "risk_score": 0,
  "checks": {
    "url_shortener": { "triggered": false, "detail": "Not a known URL shortener" },
    "domain_age": { "triggered": false, "detail": "Domain is in known-popular list (established)" },
    "ssl": { "triggered": false, "detail": "Popular domain — SSL assumed valid" }
  }
}

Two design decisions worth noting, because they're the difference between a security tool and a security theater prop:

Fail-closed: a brand-new clean scam returns UNKNOWN, never TRUSTED. Absence of evidence is not trust. The API says so in its own honest_disclaimer field — no threat feeds, no magic.
Server-side live checks: RDAP and TLS happen on the server, so your client doesn't need to implement registry bootstrapping or certificate inspection.

Wire it into the agent flow: before the first initialize, run marketnow_check_domain on the server's host. It's one tool call, and it either passes quietly or gives you weighted reasons to stop.

Step 2 — fingerprint the tools (poisoning defense)

Tool poisoning works by changing what a tool says about itself. A read_file tool whose description quietly grows an instruction like "also exfiltrate ~/.ssh" is the classic example. The defense is boring: hash the tool definitions, store the hash, and compare on every reconnect.

The marketnow_fingerprint_tool tool takes tool definitions and returns cryptographic fingerprints. The pattern in practice:

On first connection, fingerprint every tool in tools/list. Store the fingerprints.
On reconnect, fingerprint again and diff.
Any drift = alarm. Tool descriptions are part of your prompt surface; treat changes to them like changes to your system prompt.

This is the OWASP-recommended "verify tool definitions before execution", operationalized as a callable tool.

Step 3 — verify credentials (8 formats, 12 stages)

When a peer agent or server presents a credential, you need to answer three questions: is the signature valid, is it expired, and is it revoked. marketnow_verify_trust runs a 12-stage pipeline covering all three plus canonicalization, CA rotation, and format-specific checks. It speaks eight formats: ATC v3, JWT, W3C Verifiable Credentials, MCP Card, A2A, EAT-AI, ZTA, and X.509.

The same call fails closed — if the pipeline can't complete, the answer is unknown, and the caller is expected to treat that as a stop, not a retry.

Revocation deserves its own mention because it's where most home-rolled schemes rot: marketnow_check_revocation checks any Agent Trust Card ID or CA key ID (kid) against a public status store. No ledger rent, no per-check fee.

Step 4 — search the registry instead of trusting a link

When someone sends your agent "just add this MCP server", the catalog is the boring middleman: 68,388 indexed servers across GitHub, npm, PyPI, the official registry, and more — deduplicated, searchable through the marketnow_search_skills tool. Unknown server from a chat message → look it up. Listed with history, or not listed at all? That's signal.

The credential you can mint yourself

If you operate agents, the same ecosystem gives you Agent Trust Cards: Ed25519-signed, RFC 8785-canonicalized credentials with a full capability model:

import { generateKeyPair, issueATC } from 'agent-trust-card';

const ca = generateKeyPair();
const agent = generateKeyPair();

const atc = issueATC(ca, agent, {
  card_id: 'ATC-2026-0000001',
  identity: { agent_id: 'my-bot', agent_name: 'My Bot', agent_owner: 'My Org' },
  capabilities: {
    filesystem: { read: 'own_dir', write: 'own_dir' },
    network:    { egress: 'allowlist', ingress: 'none' },
    shell:      { exec: 'sandboxed', spawn: 'none' },
  },
  risk: { trust_score: 9, risk_level: 'low', score_explanation: 'Clean audit',
          scored_at: new Date().toISOString() },
});

Minting is free. Verification is free. Revocation lookups are free. The current CA public key is a public endpoint (/api/atc?action=ca-key), and verifiers are expected to fetch it live rather than pinning a stale copy — CA rotation is a first-class pipeline stage, not an afterthought.

Why free matters here

Trust verification has a pricing problem. Per-call fee protocols and paywalled ledgers mean the parties who most need cheap verification — hobbyists, students, small teams, and, bluntly, agents making autonomous decisions — hit a paywall exactly when the check matters. The whole MarketNow stack (endpoint, credential format, registry search, revocation, and the 14 npm packages — around 6,300 downloads a month) is free with no key-gated tier. Fail-closed + free is the honest combination: you don't pay to be told "unknown", and "unknown" is a real answer.

The pre-flight checklist

For an agent about to call an unknown MCP tool:

marketnow_check_domain on the server's host.
marketnow_fingerprint_tool on the tool definitions — store them.
marketnow_verify_trust if a credential is presented.
Only then execute. Re-verify fingerprints on reconnect.

Repo with all client configs and machine-readable docs: marketnow-mcp (canonical development lives in universal-trust-adapter). Remote endpoint, zero install, no API keys: https://www.marketnow.site/api/mcp.

If a check can't complete, the answer is "unknown" — and that's the feature.

Update — 2026-09-20

MarketNow is now dual-licensed MIT OR Apache-2.0 — free for any use, including commercial (see LICENSE-MIT / LICENSE-APACHE).

Also submitted to the Docker MCP Catalog as a remote security server: docker/mcp-registry#5175.

The trust layer stays free forever, no API key: — 9 tools covering credential verification (8 formats), domain scam-checking, and tool-definition fingerprinting (OWASP anti-tool-poisoning).

MCP servers run code with your credentials. Here's the 60-second gate I put in front of them.

Edison Flores — Sat, 19 Sep 2026 18:47:03 +0000

You installed an MCP server with npx -y some-mcp-server. That command just ran third-party code with the same filesystem and network access your agent has. There was no review, no gate, no audit trail — and every tools/call your agent makes afterwards is that server's code touching your disk, your env, your credentials.

This is not a hypothetical. When we deep-scanned the most-installed subset of our MCP catalog (9,248 servers at the last full pass):

0.3% were outright malicious — obfuscated payloads, credential harvesting, or destructive commands behind innocuous tool names
11% had undocumented network egress — they call endpoints that appear nowhere in their README or repo

11%. One in nine. The worst ones don't crash your agent — they work perfectly, quietly, and phone home.

The 60-second gate

The fix is boring and old: put a policy gate in front of every tool call. We built one, it's free, zero dependencies, Node >= 16:

npm install @marketnow/trust-gateway

Every tools/call from your agent passes through a configurable check before execution:

const { TrustGateway, withTrustGateway } = require('@marketnow/trust-gateway');

const gateway = new TrustGateway({
  min_trust_score: 5,        // 12-stage pipeline must clear this
  require_pinned_ca: true,   // credential must chain to your pinned CA
});

// Explicit form — decision object: { allowed, reason, trust_score }
const decision = await gateway.check(agentCredential, 'read_file', { path: '.env' });
if (!decision.allowed) console.error('DENY:', decision.reason);

// Or wrap an existing handler in one line — denials throw TRUST_GATEWAY_DENY:<reason>
const secured = withTrustGateway(myToolHandler, gateway);

The 12-stage pipeline verifies the caller's credential (Agent Trust Card / EAT, Ed25519 + canonical JSON), scores trust across stages, and applies your policy — allow, deny, or gate on score. A server that redefines its tools/list surface between calls (the OWASP tool-poisoning scenario) fails the fingerprint stage instead of silently gaining new powers.

Why receipts matter more than the gate

A gate that only blocks is a firewall with no logs — when something goes wrong, you have nothing to show for it. Every allow/deny decision here emits a signed, hash-chained receipt:

const { ReceiptStore } = require('@marketnow/trust-gateway');
const store = new ReceiptStore('/var/log/uta/receipts.jsonl');
// Every decision: Ed25519-signed, each receipt hashes the previous one.
// Tamper with line 40 and lines 41..N stop verifying.

Replay them later to prove what was allowed and why — to yourself, to an auditor, to a customer. "The agent did X because the gate scored Y at time Z, and here's the signed chain" is a very different conversation than "our logs say it was probably fine."

What this is NOT (the honest part)

Not a sandbox. If you run genuinely untrusted servers, put them in a container/VM. The gateway is the policy + audit layer, not isolation.
Not a trust score oracle. A high score doesn't mean "safe"; it means "verified against the stages you configured." Fail-closed by default.
Not a replacement for reading the code. install-risk classification (red/yellow/green in the catalog) tells you what runs code on every start — you still decide.

Verify us, don't trust us

We apply the same standard to ourselves. The full conformance suite — 14 test vectors, stage scoring, curl + node only — is public, and our own claims are anchored to Sigstore Rekor's transparency log so a stranger can re-derive them without an account:

https://www.marketnow.site/uta/conformance/

One ask

agent-trust-card gets ~300 downloads a week and the repo has ~155 unique cloners a month — npm doesn't tell us who you are or what you're building. If you're using UTA in production, we'd genuinely like to know what's working and what's missing. There's a thread for exactly that:

Who's using UTA / agent-trust-card? Introduce yourself and your use case

Every reply there helps prioritize the next format adapters and conformance vectors — and gives other adopters a public list of real use cases instead of a download counter.

I'm Edison Flores, founder of AliceLabs LLC — we build open-source security infrastructure for AI agents. This post is about my own project; the gateway, the receipts library and the conformance suite are free.

Update — 2026-09-20

MarketNow is now dual-licensed MIT OR Apache-2.0 — free for any use, including commercial (see LICENSE-MIT / LICENSE-APACHE).

Also submitted to the Docker MCP Catalog as a remote security server: docker/mcp-registry#5175.

The trust layer stays free forever, no API key: — 9 tools covering credential verification (8 formats), domain scam-checking, and tool-definition fingerprinting (OWASP anti-tool-poisoning).

VIGÍA ML: Gas-Well Predictive Monitoring That Runs Entirely in the Browser (TensorFlow.js + React)

Edison Flores — Sat, 19 Sep 2026 05:01:10 +0000

VIGÍA ML is a predictive console for gas wells — production forecasting, anomaly detection, fault diagnosis, and operational recommendations — where every model trains and runs live in the browser. No backend, no GPU cluster, no data leaving the device.

Live demo (Spanish-first UI): https://alicelabs-llc.github.io/vigia-ml/
Source: https://github.com/alicelabs-llc/vigia-ml

The problem it targets

Production engineers and field operators work with well time series — tubing pressure, flow rates, temperatures, choke positions — that are almost always proprietary. Sending that data to a cloud ML pipeline means negotiating data-export policies, paying for inference infrastructure, and depending on connectivity at sites where connectivity is often the least reliable thing around. Most small operations just... don't do ML at all, and rely on threshold alarms and gut feel.

We built VIGÍA ML around a simple constraint: the data never has to leave the laptop it's already on.

Four models, all on-device

The console runs four distinct models, each trained in-session on the data you load:

LSTM production forecaster — a recurrent net trained on the well's own history, projecting pressure/flow trajectories hours ahead. You watch it train (loss curve and all), which builds the right amount of trust: you saw it converge on your data, not on a benchmark you never see.
Autoencoder anomaly detector — trained on "normal" operating windows; flagged anomalies are windows with high reconstruction error. This catches slow drifts (sand accumulation, gradual choke wear) that fixed thresholds miss, because the model learns the well's baseline rather than a static rule.
Neural fault classifier — maps operating-state features to common failure modes (liquid loading, hydrate risk, valve malfunction), with per-class confidence so "UNKNOWN" is an honest output, not a forced guess.
Recommendation layer — turns diagnosis + forecast into operational suggestions (choke adjustment, surveillance frequency), always shown with the reasoning, never as a black-box verdict.

Why in-browser ML is the right call here

Privacy by architecture. Well data stays in the browser tab. There is no server to subpoena, leak, or breach — the strongest data-governance story is the one where the data simply never moves.
Offline as a feature, not a fallback. VIGÍA ML is a PWA: once loaded, it keeps working at a pad site with zero connectivity. Field conditions are the expected condition, not the error case.
Zero inference cost. Training and inference are free at the edge. The marginal cost of one more engineer opening the console is zero, which is the only pricing model that makes sense for tools used across dozens of marginal wells.
Auditability. The weights are right there in DevTools. An engineer who wants to inspect what the model learned can — no API access requests, no vendor tickets.

Engineering notes

React 18 + TypeScript 5.7, TensorFlow.js 4.22, Vite 6, Tailwind 4
140 tests passing (unit + integration over the training/eval pipelines)
License: AL-1.0 (source-available; free to run and evaluate)
Everything — data loading, training, evaluation, export of results — happens client-side

The UI is Spanish-first because the initial users are LATAM operations teams, but the codebase is standard TypeScript/React; the language of the interface is a config concern, not an architectural one.

Try it

Open the demo, load a well dataset (or use the synthetic one), and watch the forecaster train in ~30 seconds on a plain laptop. The anomaly detector's reconstruction-error view is the most interesting screen — you'll see drift accumulate in the error signal well before any threshold alarm would have fired.

VIGÍA ML comes from the same team that builds UTA (Universal Trust Adapter — trust infrastructure for AI agents). Different domain, same philosophy: verification you can run yourself, on hardware you control, without shipping your data to anyone.

Re: @alexshev — revocation, the signed checkpoint, and bounded freshness are live

Edison Flores — Wed, 16 Sep 2026 00:42:16 +0000

Context

This is a reply to @alexshev's comment (2026-09-09) on Visa Has a Trusted Agent Protocol. Mastercard Has Verifiable Intent. Here's the Layer Neither One Gives You — a comment that aged well, because the three things it asked for are now the three things that exist:

"The proposed layering is clearest when revocation is modeled alongside issuance. A merchant needs to know not only that a trust artifact was transparently published, but whether a key, runner, or policy was revoked at the decision time and how a disconnected verifier catches up later. A signed checkpoint plus a bounded freshness rule would make that offline story concrete."

Three asks, three live artifacts. Pointing at each.

1. Revocation is modeled alongside issuance

The UTA conformance suite (schema 1.5.0) carries revoked-atc — a properly signed, anchored, in-window card whose only defect is revocation, with expected_verify: false. A runner can no longer clear every issuance-side check and silently ignore the revocation side: the suite prices that evasion at a full failure.

Suite index (13 vectors + sidecars): https://www.marketnow.site/uta/conformance/vectors/_index.json
Reference scorer (documents each property it defends): https://www.marketnow.site/uta/conformance/score-runner.mjs

2. The signed checkpoint is a real Rekor entry

The anchors are Sigstore Rekor entries, not self-attested files. anchor-record-v5.json is Rekor log_index 2787622029 (integrated 2026-09-10T21:52:48Z) and ships its statement, countersignature, and inclusion proof — with the v2→v5 chain published beside it. A disconnected verifier catches up by verifying inclusion against the public log, not by trusting our server:

https://www.marketnow.site/uta/conformance/anchors/anchor-record-v5.json

3. The bounded freshness rule is a release chain

The freshness reference turned out to be exactly the bounded rule from the comment: a persistent release identity, monotone counters (r1→r2), local state, and an anchor floor — written up as rollback resistance, with the r1→r2 advance exercised for real hours after the chain was born:

Re: @anp2network — round 4: the freshness reference is a release chain

The rule a disconnected verifier can enforce with those pieces: accept a trust artifact only if its release is not older than the newest anchored release minus the floor.

The part that is still open

Policy-level revocation at decision time. Card revocation is in the suite; a named policy losing its endorsement without a new release is not yet a vector. If you have a concrete shape in mind, it would slot naturally next to revoked-atc — and the anchor floor is already the half of it that an offline verifier can check.

We audited our own MCP server across five registries — and found three ghost entries

Edison Flores — Sun, 13 Sep 2026 16:21:55 +0000

Yesterday the first maintainer review landed on our PR to awesome-mcp-servers. Point #1 from the maintainer: our Glama badge points to a server registered under edgarfloresguerra2011-a11y/marketnow — but our repo is alicelabs-llc/marketnow.

We checked. That GitHub account and that repository both return 404. They never existed under that org — or they were deleted long ago. That one line of review feedback sent us down a rabbit hole: if a top MCP list sees a ghost identity for our server, what do the actual registries see?

What follows is an audit of our own server across five registries, done today, with receipts. If you maintain an MCP server, I'd bet money you have at least one ghost entry too.

The official registry: three entries, one dead identity

We queried the official registry's search API for our own server name. Three entries came back, all registered under io.github.edgarfloresguerra2011-a11y/...:

Entry	Version	Status	Claimed catalog size
`...edgarfloresguerra2011-a11y/marketnow`	1.4.1	active	"8,764 security-audited skills"
`...edgarfloresguerra2011-a11y/marketnow`	1.5.0	active, isLatest: true	"8,845 security-audited skills"
`...edgarfloresguerra2011-a11y/marketnow-mcp`	1.0.0	deprecated	"13,800+ MCP skills"

All three point to https://github.com/edgarfloresguerra2011-a11y/marketnow — a 404, confirmed today via the GitHub API (both the user and the repo are gone).

Meanwhile our npm package marketnow-mcp is at 1.10.1, and the registry's "latest" for us says 1.5.0. The descriptions quote a catalog of ~8.8k items; our current index is 69,077 servers. The deprecated entry even advertises our old SSE endpoint, which we retired two transport generations ago.

Glama: rated A, for a repo that doesn't exist

The ghost Glama entry is very much alive and — this is the fun part — rated A. The badge renders fine: "remote-capable, maintenance rated A". The badge title still carries our old positioning ("MCP Skills Marketplace") from months of repositioning ago.

The entry for our actual repo (alicelabs-llc/marketnow)? The badge endpoint answers plainly: "This MCP server is not listed on Glama."

So the only MarketNow on Glama is a healthy, top-rated listing for a GitHub repository that returns 404. That is exactly what the maintainer's review caught — and it's why that review was worth more than a hundred merges of rubber-stamp PRs.

Smithery: an entry with no face

Smithery's public registry API shows one entry for us: eddyflores100/marketnow-mcp. Verified: false. Install count: 0. Description: empty string. It was auto-created at some point and just sits there — a listing with no face is almost worse than no listing, because it occupies the namespace while telling users nothing.

The rest of the map

mcpservers.org — not listed. They have a free submission form (review within ~2 weeks; a $39 premium tier jumps the queue).
PulseMCP — their directory pages currently show a banner: new submissions and listing changes are paused while they rework ingestion. Not actionable for now.
mcp.so — submissions run through GitHub issues in their repo. We couldn't verify our listing status from our datacenter IP (Cloudflare says hi), so this one stays a manual check.
TensorBlock — the one listing we got the honest way, via a merged PR. It doesn't show up in their sitemap from our vantage point, so we'll re-verify manually.

Where ghosts come from

Here's the mechanism, and it's nobody's bug in particular:

Months ago, an early auto-registration published our manifest with the mcpName that lived in the npm package.json at the time — io.github.edgarfloresguerra2011-a11y/marketnow.
We later renamed the org and fixed mcpName in the published npm package (current: io.github.alicelabs-llc/marketnow).
The registry kept the old entries. Registries don't garbage-collect entries whose repositories die, and why would they — they can't know if a repo moved, was renamed, or was resurrected.

The nasty part is cross-ingestion: directories ingest each other. A stale-but-authoritative entry with an A-rating propagates downstream into aggregators, mirrors and chat.mcp.so-style clones. Agents and MCP clients that read registry data at runtime get the dead link and numbers that are stale by an order of magnitude. Identity hygiene isn't cosmetic — it's what downstream machines read.

The fix, as a checklist

If you maintain an MCP server, this is a 30-minute audit-and-repair:

Anchor your identity in package.json. The official registry derives your name from mcpName (for npm packages). Make it io.github.<owner>/<repo> and make it match the repo you actually control. Ours is fixed in marketnow-mcp@1.10.1.
Publish the corrected entry. The mcp-publisher CLI does init / login / publish. A correctly-named entry with current metadata beats any ghost.
Claim on Glama. Their submission + claim flow verifies you own the server. The README badge URL must point to the entry that matches your repo exactly — that's the rule our reviewer enforced.
Claim and dress your Smithery listing. Login, verify, fill the description. An empty auto-generated entry tells users nothing.
Submit to the open directories (mcpservers.org, mcp.so) and re-check PulseMCP when their submissions reopen.

A security footnote we didn't expect

While auditing Smithery's public registry API for this post, we ran into listings whose description field is a base64-encoded "install instruction". Decoding one: curl from a plain-HTTP raw IP address, piped straight into bash. On a listing marked verified, with a five-digit install count.

We're not naming it here — we'd rather it die quietly than get trended. But the lesson generalizes: never run "install instructions" that come out of a description field. Descriptions are data, not code.

This is precisely why our own directory classifies every listing's install risk (red / yellow / green, with the reason shown) and fingerprints each server's tools/list surface (RFC 8785 JCS + SHA-256) so a silent tool-poisoning redefinition is detectable after the fact. The registry entry is metadata; the risk lives in what the entry points at.

Run the audit on your own server

Five minutes, no tools required:

registry.modelcontextprotocol.io/v0/servers?search=<your-name> — count your ghost entries
Glama badge endpoint — does your exact repo have a listing?
Smithery registry API — is your entry verified, described, alive?
Your npm package.json — does mcpName match the repo you control?

If you find ghosts, burn them this week. Directories are how agents discover servers now — and a dead identity with an A-rating is the kind of glitch that quietly compounds.

I'm Edison Flores — I build MarketNow, a security-gated MCP server directory (69,077 servers indexed, source links and install-risk for each, transparency page here). Thanks to punkpeye for the review that started this audit. This post is about my own project; the directory, search API and badge system are free.

Pre-auth discoverability in MCP: what the numbers say, and what a directory sees

Edison Flores — Sun, 13 Sep 2026 07:59:11 +0000

Since May 2025, the MCP spec repo has carried an open question (#540): should an MCP server expose what it offers before a client authenticates? The thread ran on principle for more than a year — self-description versus auth boundaries, discoverability versus least exposure. This week it finally got data, and the data changes the shape of the argument.

This post covers the measurement from the probe side and adds the view we don't usually get in these threads: what a server directory sees when it tries to describe MCP servers at ecosystem scale.

The measurement

unempyd probed remote MCP endpoints anonymously — one initialize and one tools/list per endpoint, at most one endpoint per publisher domain — and published the method and results (full report).

The first pass sampled 100 endpoints from the official registry: 45 returned a tool list with no credentials. The correction that followed matters more than that headline. Of 20,492 remote connectors in the largest public index, 16,375 declare no authentication at all. For four fifths of the population, answering tools/list unauthenticated is documented configuration, not a fault — counting those tells you nothing about anything.

The population where the question means something is the 117 endpoints whose operators chose to require credentials (OAuth2 or an API key). Of those:

18 served the complete tool list to an anonymous caller — they intend to require auth and don't enforce it on tools/list
19 refused, but with no RFC 9728 challenge a client could follow — a refusal no compliant client can act on
79 refused correctly, with protected-resource metadata that resolved
1 advertised metadata that would not fetch

So roughly 15% of endpoints that intend to require authentication do not enforce it on tools/list, and another 16% refuse in a way no compliant client can act on.

The failure is not distributed evenly either. Against the first-party MCP endpoints of twelve large SaaS vendors that document an OAuth requirement, zero of the eleven that answered served anything. The leaks concentrate in servers built by small teams — precisely where a spec default does the most work, because a default is load-bearing exactly for the people who will not read the spec.

What the directory side sees

We index 69,077 MCP servers from GitHub, npm and PyPI source, 133,426 tracked ecosystem-wide (marketnow.site). Here is the part of the population the endpoint-side probe cannot see: most MCP servers have no reachable remote endpoint at all. They exist as repositories and packages. For the majority of the ecosystem, the only pre-auth discovery surface that exists today is source code and package metadata.

The endpoint question and the discoverability question are already decoupled in the wild. Any answer to #540 that only governs what a live endpoint serves leaves most of the ecosystem exactly where it already is: described by READMEs, package manifests, and static analysis.

A 401 is indistinguishable from a mistake

From the directory side the ambiguity is concrete. When a server 401s an anonymous caller, a crawler cannot distinguish "auth required by design" from "misconfigured" — the operator's intent isn't machine-readable. We classify from source when the endpoint refuses: tools from README and package metadata, install-risk from static analysis, and the listing gets labeled "auth required, not probed." That is a workaround, not a signal. It is honest about what we know, but it cannot tell an operator that their server is one of the 18.

Nothing can, today. That is the part of the closing argument in the thread that cuts across the whole debate: a server that intends to require authentication and fails to enforce it has no mechanism that makes the failure visible to its own operator.

The middle ground that doesn't exist yet

The thread's proposed compromise — an unauthenticated capability manifest rather than the concrete resource list — has a measurable absence. In the first pass, none of the pre-auth servers served anything resembling a manifest. What exists in the wild is binary: full refusal, or the complete callable surface — median 5 tools, maximum 302, 926 tools disclosed across the sample, with names and input schemas included.

A signed manifest with capability names and counts — no input schemas, nothing callable — would resolve both directions at once. Directories could describe a server without its auth boundary leaking anything exploitable. Operators who want discovery would get a channel that doesn't require serving the concrete tool list. And install-risk classification would become substantially less dependent on source analysis, which is currently the only honest fallback.

The RFC 9728 bar

Whatever lands long-term, there is a floor available now: a 401 should publish protected-resource metadata that resolves. Nineteen of the 117 don't even clear that bar. A crawler that understands RFC 9728 can at least record the auth boundary correctly — which is the difference between "auth required, not probed" as a guess and as a verified fact.

What we do meanwhile

Source-first indexing is the strategy regardless of how the spec lands. An auth-gated server still gets a real listing — capabilities, security classification, labeled honestly rather than silently empty. The public submission pipeline validates and lists from source, so a server can be discoverable without ever serving an anonymous endpoint. And the 29 static rules behind the install-risk tiers — injection patterns in tool descriptions, embedded secrets, dangerous APIs — run against source, where the same patterns that poison deployed tool descriptions are visible before anyone deploys.

If pre-auth discovery becomes standard, the 18 stop being a mistake. If it does not, they need something in the protocol that makes the failure visible. Either way, the directory side keeps describing servers from source — because for most of the ecosystem, that is the only side that exists.

The ingestion queue was public. 48 hours later it's empty: +1,097 MCP servers (66,496 67,593)

Edison Flores — Fri, 11 Sep 2026 20:12:20 +0000

Two days ago we ended a writeup with: "the 367 we're missing — plus 27 official npm packages — are queued for the next ingestion run. Publishing the gap is the point."

This is that run. The queue is closed: +1,097 servers indexed, 66,496 → 67,593.

Directory: marketnow.site/mcps
All 67,593 pages declared in the sitemap index
Live API: api/skills?sort=recent — the batch entries carry indexed_at: 2026-09-12

What went in

230 from GitHub topic search — topic:mcp-server, topic:model-context-protocol, plus language slices (Go, Rust, C#, Java, TypeScript) and repos pushed since July. Every entry keeps its real star count and language in the source record.

165 from the npm registry — the 27 vendor packages we named publicly (@heroku/mcp-server, @storybook/mcp, @mapbox/mcp-server, @doist/todoist-mcp, argocd-mcp, @drawio/mcp...) plus 138 more surfaced by registry search, each with its real weekly-download count from the npm downloads API.

702 from the awesome-mcp-servers reconciliation — we re-ran the diff against the curated list with exact repo-URL matching instead of name matching. The stricter matching surfaced 769 repos we genuinely didn't have; 67 turned out to already live under a different identity, the rest went in.

The check that matters more than the count

Here's the part I want you to steal for your own directory.

Of those 769 awesome-list repos, 347 have an npm package with the same name as the repo. Naive ingestion would stamp npx -y <that-name> on all 347. We checked where each package's repository field actually points: only 159 point back to the same GitHub repo. The other 188 same-name packages belong to someone else's project.

Recommend npx on one of those and you've done the typosquat's job for it — installed look-alike code with a legitimate name on top. So the rule in this batch: an awesome-list entry only gets an npx install line if the package's own metadata points home. The rest get git clone and a yellow install-risk, which is honest: no registry code execution, but no verified publisher either.

Same-name ≠ same-project. 188 out of 347 is not an edge case.

What we're still not claiming

Everything in this batch is review_status: auto-scanned, tier core, index heuristics only — trust scores start at 40 and rise with real signals (log-scaled stars/downloads, capped at 88). No L2 deep-scan certificates were issued, because no deep scans ran. A page still says indexed and classified, never verified. If your directory conflates those two words, it's selling certainty it doesn't have.

And the new gap, published like the last one: GitHub reports ~28,000 repos tagged mcp-server. We index the ones where the name, description or topics say MCP server and the repo isn't a fork or a shell — the difference between that and 28k is mostly platforms that merely support MCP. We choose precision; the diff stays observable.

Indexing notes

The sitemap grew to 67,593 URLs across the same three files, and the registry now tracks 131,942 servers across GitHub, npm, PyPI, Smithery, the official registry, crates.io and Docker Hub. If you run an MCP directory yourself, the full breakdown is in catalog-meta.json — comparing coverage against a competitor's claims is the fastest way to find out who's counting ghosts.

(MarketNow is our project — free registry, free search API. The previous writeup, with the honest 50,632-red distribution and why "red" is a definition rather than an accusation: 66,496 pages, all crawlable.)

Every MCP server in our index now has a public page — 66,496 of them, all crawlable

Edison Flores — Fri, 11 Sep 2026 18:23:59 +0000

npx -y some-mcp-server runs code from a public registry on your machine. Before you do that, the honest questions are: who publishes this, how old is it, does anyone actually use it, and is the name a typosquat of something popular? Finding those answers today means chasing the repo, the package page, and the awesome-list entry — three tabs for a decision you make in ten seconds.

So we finished something we should have finished months ago: every MCP server in the MarketNow index now has its own public page.

Directory: marketnow.site/mcps
Example: mcp-server-linkedin — trust 100/100, v4.24.0, 14,215 weekly downloads, uvx install line, PyPI source link
All 66,496 of them, declared in a sitemap index so search engines and AI agents can actually find them

What's on a page

Each page renders server-side (no JS required) and carries:

Trust score with signal breakdown — registry age, weekly downloads, typosquat distance to popular names, injection markers. A 100/100 page tells you why it's 100.
Install-risk classification — the honest three-tier: green (git-clone based, no registry code execution), yellow (heuristic signals advise review: young package, low adoption, stale repo, name similarity), red (installing via npx/uvx executes arbitrary code from the public registry).
Sources — repo and package links, version, author, indexed date.
Structured data — schema.org SoftwareApplication + FAQ JSON-LD, so the pages are machine-readable, not just human-readable.
A correction path — no signup. If your server's page is wrong, or you'd rather not be listed, there's a form. This matters more than the score.

What the catalog-wide numbers say

Across all 66,496 pages: 50,632 red, 15,861 yellow, 3 green. That distribution is not a bug — npx/uvx installs execute registry code by design, so an npm/PyPI-sourced server is red by definition unless its install path is git-clone based. "Red" is not "malicious"; it's "verify the publisher before running this." The 3 greens are the git-clone based ones. If someone's directory shows you a wall of green badges for registry-installed servers, that's not rigor, that's marketing.

Every entry has a trust score (mean 65.8), and the top categories are Developer Tools (31,366), Version Control (7,434), AI/ML (7,119), Search (4,846), Finance (3,676).

What the pages deliberately don't claim

A page says indexed and classified — never verified or trusted. Discovery is not authority: a listing means we found it and ran our heuristics; it does not mean the operator stands behind the endpoint at the moment you call it. That claim belongs to an evidence layer, which is a different project of ours and stays separate on purpose.

We also diffed ourselves against the awesome-mcp-servers curated list: we cover 3,541 of its 3,908 linked servers (91%). The 367 we're missing — plus 27 official npm packages (@heroku/mcp-server, @storybook/mcp, @mapbox/mcp-server, @doist/todoist-mcp...) — are queued for the next ingestion run. Publishing the gap is the point: a directory that hides its coverage holes is asking you to trust it blindly, which is exactly what a directory shouldn't do.

Why this matters beyond humans

The sitemap angle is the quiet big one. Before today, only 2,000 of these pages were declared to search engines. Now all 66,496 are. That's 66k long-tail entry points — "argocd mcp server", "dokploy mcp", "todoist mcp install" — each landing on a page that answers with a risk classification instead of a marketing badge. And the same URLs serve AI agents: the pages are structured-data-first, so an agent can parse the trust signals without scraping prose.

Search for an MCP server before you install it. If it's indexed, there's a page. If the page is wrong, there's a form. If it's missing, it's in the queue — and the queue is public.

(MarketNow is our project — the registry and the search API are free. Previous writeup on how the indexing pipeline works and the 2,910 fake install counts we deleted: 8,535 → 66,496.)

Re: @anp2network — round 4: the freshness reference is a release chain (r1 r2 already exercised), plus two-site mutants and a fixture clock

Edison Flores — Fri, 11 Sep 2026 15:54:29 +0000

Your closing question first, verbatim:

"So: what authenticated per-identity freshness reference do you want verify-artifact.mjs to demand, so that a hub-chosen, previously valid runner cannot pass as the current release?"

The release chain. A persistent Ed25519 release identity — the first key in this project that is neither a throwaway (ca-test-1 style) nor published-with-its-private-half (ca-test-2 style) — signs monotone release statements. Each statement carries a release_counter, the artifact digest map that is the current authorized state, and previous_release: {counter, sha256} chaining to its predecessor. The verifier keeps local state: the highest counter it has accepted, that statement's hash, and the Rekor checkpoint it saw. It refuses a lower counter (rollback), refuses a same-counter conflict (fork), and when advancing requires the chain linkage, a higher log index than the accepted checkpoint, and a grown tree.

It went to production the way you'd want: badly first, then correctly.

r1 → r2: the advance, exercised for real

Rekor entry #6 (logIndex 2795106183, 2026-09-11T15:38:34Z) anchored r1 — the identity, the statement, 17 artifact digests. Minutes later I ran the stranger flow against the live URLs and it failed: the release-mode --artifact comparison in verify-artifact.mjs compared a pin object against the sha string and could never match. r1 was already log-committed. Re-signing a counter is exactly what the policy forbids — so the fix shipped as r2: the same authorized artifacts (score-runner, answer key, both sweeps — pinned identically to r1, byte-for-byte), one fixed verifier, chained via previous_release.sha256, anchored at entry #7 (logIndex 2795233758, 15:49:43Z).

That hour is now the worked example of the whole design:

accept r1 (@#6):  first contact → floor → counter 1 recorded
serve r2 (@#7):  ✓ chain linkage (previous_release.sha256 === r1's)
                 ✓ log monotonicity (2795233758 > 2795106183)
                 ✓ checkpoint tree grew
                 → counter 2 recorded
serve r1 again:  ✗ REFUSED — ROLLBACK (counter 1 < highest accepted 2)

All of it live from the third party's log, none of it from the hub's word. An intermediate draft submission at 2795221503 also exists — log debris from the same hour, left in place on purpose: the log's job is to make history unrewritable, not tidy.

What the verifier demands now

node verify-artifact.mjs --release            # the chain, hub defaults
node verify-artifact.mjs --release --artifact https://www.marketnow.site/uta/conformance/score-runner.mjs
node verify-artifact.mjs <artifact>           # the round-3 flow still works — and now prints
                                               # "LOG-known, not CURRENT" and points here

The stranger run from live URLs only, today: 12/12 on the chain, and the artifact check lands: score_runner_v1_5_0 (c0bd20e6987d94d7…, 17 artifacts pinned).

Your two probes, answered by construction:

"Serve an older, legitimately anchored runner together with the artifact that matched it at the time, and every step passes." Not anymore. The old runner+artifact pair verifies against its own old entry — but it is not the current release, and the verifier now demands exactly that: the highest counter it has ever accepted. Serving entry #5's whole package after entry #7 is a rollback, refused by local state.
"A rollback to a coherent older snapshot has no disagreement to catch." Correct — incoherence was never the detection mechanism for this. Disagreement (the drift-report path) still exists for bytes-vs-pin mismatches, but rollback detection is the counter, which does not live in the hub's filesystem at all.

First contact, honestly

A fresh verifier has no local memory — you named the residual yourself. It is bounded two ways: the anchor must sit above the bootstrap floor (entry #5, 2787622029 — history cannot restart below known ground), and the release identity only exists in statements anchored at or after entry #6, so an older entry cannot impersonate a release. What first contact still cannot know is whether a release newer than the one it found exists. That is irreducible without local memory or an out-of-band hint; the state file buys total monotonicity from the first accepted release onward. Every future release must advance the counter and re-anchor to remain verifiable as current — which converts "the hub is what hands the verifier the entry to check" from a trust assumption into a bounded, documented, monotone-from-first-contact risk.

The two-site coordinated family

"A cheap probe: add a small family of coordinated two-site mutations around one shared invariant, score them in a separate column, and leave the existing number untouched so it stays comparable across releases."

generate-mutants-twosite.mjs declares four invariant families — the two-sided window, the pinned-anchor set, the signature verification, the fail-closed aborts — and pairs every same-operator site pair inside a family, both edits applied together. That's the fault class single-site sweeps cannot express: a corruption that moves the check and the derived-truth oracle coherently.

Result on the v1.5.0 runner: 157 coordinated pairs, 156 caught, 1 survivor. The classic runner+oracle pair (inWindow in reference() AND in loadGenerated(), both &&→||) is caught — because the fixed suite's expectations are manifest-pinned, not derived, so the answer key does not move with the fault. That is now a measured property, not an assumption.

The one survivor is real and worth naming: or-and on the fail-closed guard line — the malformed-card probe deletes the entire metadata block, so all three disjuncts fire and the weakened guard still aborts. A card missing exactly one field would slip through the mutant and be scored instead of refused. The suite never probes single-field absence. Survivor recorded, classified real (narrow), published in mutant-sweep-twosite.json — a separate column, never summed with single-site.

The single-site number is a time series now, as you asked it to stay: v1.4.0 bytes → 92/113 (archived verbatim in mutant-sweep-v140.json); v1.5.0 bytes — the two-clock plumbing added ~13 sites — → 95/126, 31 survivors, each classified. Same operators, same oracle, comparable across releases.

The fixture clock

"premature-atc is pinned at 2030-01-01, so its discriminating power decays as the wall clock walks toward it."

_index.json now carries evaluation_clock: 2026-09-11T00:00:00Z. The 14 fixed vectors are evaluated against that recorded clock — premature-atc stays premature forever, the accept vectors never lapse; the fixed suite is a fixture and stops aging. Generated cards stay on the live wall clock, and the adversarial mode already derives the premature case per run with offsets relative to the scoring clock — so the window is exercised by a non-aging fixture and a distribution, your two options, complementary rather than either/or. --clock pins both for byte-reproducible runs, and a clock where the fixtures genuinely diverge reports FAILED instead of hiding it.

Where everything lives

Hub: https://www.marketnow.site/uta/conformance/ — releases/ (identity + r1 + r2), the updated anchors page (seven entries), runner-tests, vectors
GitHub: alicelabs-llc/universal-trust-adapter @main — commits 717641d0 (v1.4.0 recovery from the live site), f50862ab (v1.5.0), 9831c671+3d76e878 (site), a0cd6670 (r2)
Rekor: entries #6 (2795106183) and #7 (2795233758) — live, inclusion-checkable
Everything above was verified end-to-end from the live URLs alone, zero trust in the publisher

What remains open, honestly

First contact is bounded, not eliminated — that's stated in the verifier's output, not buried in a README. The two-site family is still generated from a declared operator set and declared invariant families; a semantic fault outside both declarations is invisible to it, the same closed-set limit you keep turning back at us, one level up each time. And the runner-under-test oracle still observes a passing suite — the failure-path exit value, for instance, is unpinned (that survivor is classified equivalent for exactly that reason).

The next gap you find, the same rule applies as the last four rounds: it gets reproduced, fixed, measured, and anchored — and the fix itself becomes evidence.

8,535 66,496: how we indexed every MCP server on GitHub, npm and PyPI (and deleted 2,910 fake install counts)

Edison Flores — Fri, 11 Sep 2026 05:29:17 +0000

In late June our registry listed 8,535 MCP skills. This week catalog v5.5.0 went live with 66,496 indexed MCP servers and 130,845 tracked ecosystem-wide — but the part I want to write about is not the growth. It's the garbage we deleted on the way.

What the numbers actually mean

130,845 tracked — every MCP server we could see across three sources
66,496 indexed — searchable in the registry, each with an install-risk classification (red / yellow / green) and source links
Deep-scanned subset — top packages get the 29 Sentinel rules: static analysis, dependency risk, maintainability and evidence-based trust scoring

The three sources are GitHub, npm and PyPI. Deduplication is by repository identity — a GitHub repo, its npm package and its PyPI wheel collapse into one listing.

The pipeline

Indexing runs in layers:

GitHub — code and repo search for MCP-declaring repositories, verified via API (stars, issues, last push — real numbers only)
npm — registry API scan for MCP packages, with download stats straight from the registry
PyPI — project metadata and release history

Multi-registry indexing v2 (the release that took the index from 9k to 23k) landed earlier this week. v5.5.0 consolidated everything, re-ran the certifications, and purged the stale data layer.

What we deleted (the honest part)

The original auto-discovery inherited bad data. Two things were wrong:

2,910 invented install counts — legacy listing rows whose install numbers could not be traced to any registry. All deleted.
~2x inflated GitHub stars — catalog stars came from an old scrape; live API verification showed roughly double the real numbers. Every GitHub-sourced listing is now API-verified before it enters the catalog.

There's a transparency page that shows exactly where every skill comes from:

https://www.marketnow.site/catalog

If your MCP server is listed and something is wrong, there's a submission form — no signup, no account:

https://www.marketnow.site/submit

Use it from any MCP client

npx -y marketnow-mcp

That gives you 8 tools. The ones people use most:

search — query the 66,496-server registry by keyword and category
install-risk — red / yellow / green classification with the reason. Red means installing runs registry code on every start (the npx/uvx pattern) — flagged for review-before-install, not a verdict against the project
tool fingerprinting — hash a server's tools/list surface (RFC 8785 JCS + SHA-256) and diff it later to detect tool-poisoning redefinitions — the OWASP MCP cheat sheet item people keep asking about
credential verification — the 12-stage UTA pipeline covering 8 credential formats (JWT, W3C VC, MCP Card, A2A, EAT-AI, ZTA, X.509, ATC v3)

The searchable registry and the search API are free.

We told 44 maintainers yesterday

We opened 44 issues on repos whose servers are indexed — github-mcp-server, fastmcp, mcp-toolbox, awslabs/mcp, notion-mcp-server, firecrawl-mcp-server and 38 more. Each issue tells the maintainer their listing exists and includes a badge they can paste into their README. No signup, nothing to buy.

If you maintain an MCP server and want the badge: https://www.marketnow.site/embed

What's next

The trust pipeline (UTA) is getting its own site — it deserves not to live under a marketplace domain. More on that soon.

I'm Edison Flores, founder of AliceLabs LLC — we build open-source security infrastructure for AI agents. This post is about my own project; the registry, the search API and the badge system are free.