MCP Trust Scanners Now Grade Apple Health Servers
There is a new layer above the MCP registry, and it does not take a vendor's word for anything. Scanners now fetch a published server, read its install line, and grade it. If you install health-data tooling, you need to know what they check, because a bad install line scores zero.
Quick answer
A trust-scanner layer now grades published MCP servers automatically, off their published install metadata rather than a human review. On 2026-10-18 we saw VerifyMCP score ghurt, a health MCP server, 0 out of 100, because its tool URL was an unset template variable (evidence E8), and the Ext Ops Panel tracking registry first-seen dates alongside a listing (E7). The practical takeaway: a server is only as trustworthy as its published install line, so read that line before you run anything.
What a trust scanner actually reads
A scanner does not run the server and watch what it does. It fetches what the server published and checks that it resolves and makes sense. The signals we saw it grade on:
- Does the install line resolve? An
npxoruvxcommand, or a remote URL, that points at something real. A URL left as an unset template variable fails instantly. - Is the tool surface declared? A named list of tools with input schemas reads as trustworthy. A vague surface does not.
- Where does it come from? A registry listing with a first-seen date and a stable publisher identity scores better than an anonymous paste.
- What does it ask for? A server that wants a broad scope to do a narrow job gets marked down. Read-only and narrowly scoped gets marked up.
Why one server scored zero
The zero was not about behaviour. It was about a placeholder that shipped to production: the server's documented tool URL was still an unset template variable, so the scanner had nothing resolvable to grade and returned 0 out of 100. That is the whole lesson of this layer. A trust score measures the publish, not the intent. A good build with a sloppy install line reads as broken.
How we sourced this. The 0/100 score is from the scanner's own page for that server (E8), and the registry first-seen tracking is from the Ext Ops Panel listing (E7), both read on 2026-10-18. Scores are live and change, so open the scanner for a current number.
Why this matters more for health data
Health MCP servers sit next to the most personal records on your phone. The trust layer exists because installing a server is running someone's code with the ability to request your data. A scanner that reads the install line will not catch a malicious server on its own, but it does kill the class of mistake where a half-finished project gets installed by a hundred people who assumed the URL worked.
For a buyer, the scanners turn a hard question into a checklist. Before you install any health MCP server, answer these yourself, because a scanner would:
- Open the published install line and confirm it resolves to a real command or URL, not a placeholder.
- Confirm the tool surface is named and read-only where it can be.
- Check whether the server makes network calls, or reads a file locally.
- Check the publisher's identity and the listing's first-seen date.
- Read the repo, not just the listing.
How the local path scores on those checks
| What a scanner reads | MetricBridge MCP server |
|---|---|
| Install line resolves | A node command against a local server.mjs, no placeholder |
| Tool surface declared | 16 named read-only tools, 22 prompts |
| Network behaviour | Zero runtime network calls; reads a local file |
| Source | Open source, public GitHub repo |
| Scope | Read-only, your own files |
That is the reason a table like this is worth writing down. Every one of those rows is answerable from public information before you install anything, and none of them requires trusting a marketing page.
Bookmark this: the pre-install check
Before you add any health MCP server to your agent, run the five checks above and open the trust scanner for that server. Then, if you want the shortest path that already passes them, use a server that reads your own file:
{
"mcpServers": {
"health-export": {
"command": "node",
"args": ["/Users/you/.health-export-mcp/server.mjs"],
"env": {
"HEALTH_DATA_DIR": "/Users/you/Library/Mobile Documents/iCloud~ai~healthexport~app/Documents"
}
}
}
}Then ask the agent to call get_mcp_status. It reports whether the server is up, whether it found your data, and whether it is making network calls. That is a trust check you can run yourself, in one tool call.
FAQ
What is VerifyMCP?
It is one of the automatic trust scanners that grade published MCP servers. It fetches a server's published install metadata and returns a score. On 2026-10-18 it scored the health server ghurt 0 out of 100 because the tool URL was an unset template variable.
What is the Ext Ops Panel?
A directory layer that tracks MCP servers alongside registry metadata such as first-seen dates. It gives a listing a history rather than just a presence, so a new or anonymous listing is visible as new.
Do trust scanners run my data through the server?
No. A scanner reads what the server published, such as its install line and tool surface. It does not execute the server against your data. That is why a poor install line can fail scoring even when the code is fine.
How do I check a health MCP server myself?
Open its published install line and confirm it resolves without placeholders, confirm the tool surface is named and read-only, check whether it makes network calls or reads a local file, and read the repo. The MetricBridge server answers all four from public information.
Doing this yourself? MetricBridge handles the export step: all 190 metrics as local JSON, with the open-source MCP server (GitHub).
Passes the checks before you install it
MetricBridge is a $24.99 one-time unlock: the export, the open-source stdio MCP server with 16 read-only tools and zero network calls, and the on-device Ask and Weekly Brief.