Meridian Trace — Medical Device Registrations
REMOTE · MERIDIANTRACE.COM · SCANNED SEP 24
Medical device registrations across 25 markets: coverage gaps, 510(k) predicates, classification
Available components
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security63
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation not fully verified: no authorisation is required to call this server, and 12 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe. See how to fix → View diagnostics → Unverified
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability63
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 3527 tokens (~293/item across 12 items; 12 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
- No destabilizing schema changes in the last 30 days.Pass
Tool Coverage98
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 94% of tool parameters carry a description.Partial
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 12 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 13 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities60
- Spec-recency check failed: implements MCP spec 2025-06-18; the latest is 2026-07-28. See how to fix → Fail
How do I install the Meridian Trace — Medical Device Registrations MCP server?
Meridian Trace — Medical Device Registrations is a hosted endpoint at https://meridiantrace.com/v1/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · meridiantrace.com
claude mcp add --transport http com-meridiantrace-medical-device-registrations 'https://meridiantrace.com/v1/mcp'
{
"mcpServers": {
"com-meridiantrace-medical-device-registrations": {
"url": "https://meridiantrace.com/v1/mcp"
}
}
} {
"servers": {
"com-meridiantrace-medical-device-registrations": {
"type": "http",
"url": "https://meridiantrace.com/v1/mcp"
}
}
} [mcp_servers.com-meridiantrace-medical-device-registrations] url = "https://meridiantrace.com/v1/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"com-meridiantrace-medical-device-registrations": {
"type": "remote",
"url": "https://meridiantrace.com/v1/mcp",
"enabled": true
}
}
} openclaw mcp add com-meridiantrace-medical-device-registrations --url 'https://meridiantrace.com/v1/mcp' --transport streamable-http
mcp_servers:
com-meridiantrace-medical-device-registrations:
url: "https://meridiantrace.com/v1/mcp" {
"McpServers": {
"com-meridiantrace-medical-device-registrations": {
"Transport": "http",
"Url": "https://meridiantrace.com/v1/mcp"
}
}
} assistant mcp add com-meridiantrace-medical-device-registrations -t streamable-http -u 'https://meridiantrace.com/v1/mcp'
{
"mcpServers": {
"com-meridiantrace-medical-device-registrations": {
"type": "http",
"url": "https://meridiantrace.com/v1/mcp"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 21 Sept 26 +1
- Stability: fail → pass ▲ security
- 19 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 90 to 94.
- 16 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 80 to 84.
- 14 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 74 to 77.
- 13 Sept 26 +1
- Stability: unverified → fail ▼ security
- Injection markers: unverified → pass ▲ security
- TLS certificate: unverified → pass ▲ security
- HSTS header: unverified → pass ▲ security
- Transport: fail → pass ▲ security
- Authorization: Authorisation not fully verified: no authorisation is required to call this server, and 12 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe. security
- MCP protocol: unverified → fail ▼ functional
- Endpoint reachability: unreachable → reachable ▲ functional
- Tool coverage: unverified → 100 ▲ functional
- 12 Sept 26 0
- Endpoint reachability: reachable → unreachable ▼ security
- Stability: fail → unverified ▼ security
- Tool safety: pass → unverified ▼ security
- TLS certificate: pass → unverified ▼ security
- HSTS header: pass → unverified ▼ security
- Transport: pass → fail ▼ security
- Authorization: Authorisation not yet verified: we couldn't confirm whether this endpoint requires it. security
- Capabilities: fail → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- First check of Schema quality: unverified functional
- 10 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 60 to 64.
- 8 Sept 26 0
- The server rewrote its instructions, which are the text every model session reads security
- Schema quality: 2990 → 3527 ▼ functional
- New tool “find_distributors” functional
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 24 Sept 2026 · Probed https://meridiantrace.com/v1/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=meridiantrace.com | CN=YE2,O=Let's Encrypt,C=US | 6 Sept 2026 | 5 Dec 2026 | ECDSA 256 | ECDSA-SHA384 | 505825822afa199a52ee3f92c8b4a44c872 |
| SANs: meridiantrace.com, www.meridiantrace.com | ||||||
| CN=YE2,O=Let's Encrypt,C=US (CA) | CN=Root YE,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | ECDSA 384 | ECDSA-SHA384 | 4df3b15dd6c0784c507cd37b58e6f115 |
| CN=Root YE,O=ISRG,C=US (CA) | CN=ISRG Root X2,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | ECDSA-SHA384 | 872165fc34b6e5fba8add5b3705fb53a |
| CN=ISRG Root X2,O=Internet Security Research Group,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | SHA256-RSA | 6c8f1dc727c7117f7baf853ac980f9cd |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of meridiantrace.com. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| com. | present | 19718 | 13 | Verified |
| meridiantrace.com. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
| Header | Value |
|---|---|
| strict-transport-security | max-age=31536000; includeSubDomains |
| content-security-policy | default-src 'self';base-uri 'self';font-src 'self' https: data:;form-action 'self';frame-ancestors 'self';img-src 'self' data:;object-src 'none';script-src 'self';script-src-attr 'none';style-src 'self' https: 'unsafe-inline';upgrade-insecure-requests |
| x-content-type-options | nosniff |
| x-frame-options | SAMEORIGIN |
| referrer-policy | no-referrer |
| permissions-policy | camera=(), microphone=(), geolocation=() |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://meridiantrace.com/v1/mcp | Verified | 200 | |
| http (plaintext) | http://meridiantrace.com/v1/mcp | HTTPS enforced | 301 | https://meridiantrace.com/v1/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
classify_device ~350
RUNS WITHOUT AN API KEY (anonymous callers see the top 3 FDA product codes and the full per-market risk table — a free key unlocks the rest). Classification view of a device type: the GMDN hierarchy it sits in, the FDA product codes it maps to with how many devices carry each, and — the part not published anywhere — how the SAME device type is actually risk-classed market by market, with the sample size behind each. Risk class is not portable: a device type can be modal High in Canada and modal Medium in the EU and Singapore, which changes submission route, evidence burden and timeline. Observed practice, not a regulatory determination. Takes a plain device name ("bone screw", "hip implant"), a GMDN code, or an FDA product code. A name is resolved by how many real devices carry each GMDN term rather than by string matching, and `resolution` reports which term was chosen, how many others matched and what they were — call again with `gmdn_code` to classify one of those instead.
| Name | Type | Req | Description |
|---|---|---|---|
| device_type | string | – | A device name in plain words ("insulin pump", "orthopaedic plate") or a GMDN term. US and British spellings both resolve. Name the device, not the brand or the use — "infusion pump", not "PumpMaster… |
| fda_product_code | string | – | FDA product code, e.g. "DZE" |
| gmdn_code | string | – | GMDN code, e.g. "44727" |
No output schema declared.
No examples provided.
find_distributors ~323
RUNS WITHOUT AN API KEY (anonymous callers see the top 3 per market and are told how many more matched). WHO COULD SELL A DEVICE IN A MARKET — the question a company entering a market actually has. Give it a market and, optionally, a device type or clinical area; it returns the local distributors and importers who hold registrations there, what clinical areas they cover, how many markets they operate in, and a sample of the lines they already carry. Strongest across Asia, where the registry names the local partner rather than the manufacturer and this relationship is not published anywhere else: Singapore, Malaysia, Thailand, Indonesia, Vietnam, the Philippines, Japan, Korea, Taiwan, India and Hong Kong. This is the INVERSE of get_license_holders, which starts from a manufacturer you can already name. Regulatory consultants and authorised representatives are excluded — they hold licences as a service and do not sell — as are manufacturers' own in-country subsidiaries. Read the `caveats` in the response before quoting any number from it.
| Name | Type | Req | Description |
|---|---|---|---|
| device_type | string | – | Optional clinical area or device category in plain words, e.g. "orthopaedic implants", "in vitro diagnostics", "cardiology". Partial matches count. Omit it to see the whole channel in that market. |
| limit | number | – | 1-25 (default 10). Capped to 3 without a paid key. |
| market | string | yes | ISO2 code or market name, e.g. "TH" or "Thailand". One market per call. |
No output schema declared.
No examples provided.
find_predicates ~193
US 510(k) predicate lineage, from the predicates actually cited in each clearance's own summary document — not a similarity guess. 64,567 clearances, 1992-2026. By k_number: what that device cited, AND which later devices cited IT as a predicate — the reverse direction shows whose clearances rest on your device and how contested a space is. By product_code: the predicates that code leans on most, ranked by how often they are cited, plus recent clearances. Use when choosing a predicate, assessing substantial equivalence, or mapping who is clearing devices in a classification.
| Name | Type | Req | Description |
|---|---|---|---|
| k_number | string | – | A 510(k) number, e.g. "K191275" |
| limit | number | – | Max rows per list (default 20, max 50) |
| product_code | string | – | An FDA product code, e.g. "LIT" |
No output schema declared.
No examples provided.
find_similar_devices ~184
Competing and comparable devices for a registration, matched on resolved device type (GMDN) rather than product-name text, and spread across markets so the answer is not all one country. Excludes the same manufacturer, so what comes back is the competitive set. Each result carries a match band. Use for competitive landscape, classification precedent in other markets, and finding how the same device type is described elsewhere. Get a registration_id from get_registrations.
| Name | Type | Req | Description |
|---|---|---|---|
| device_name | string | – | A product name, as an alternative to registration_id — the closest registration is used as the reference device |
| limit | number | – | Max results (default 15) |
| market | string | – | With device_name, restrict the reference lookup to one market (ISO2) |
| registration_id | string | – | The _id of a registration, from get_registrations |
No output schema declared.
No examples provided.
get_coverage ~95
RUNS WITHOUT AN API KEY — call it right now to check us before signing up for anything. What Meridian Trace actually holds: every source registry, the market it covers, how many registrations are on file from it, and when it was last crawled. Call this to verify coverage and freshness for yourself before relying on other tools, or to answer "do you cover market X, and how current is it?". No arguments.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
get_license_holders ~95
The local entities that actually hold a foreign manufacturer's registrations — the importers, distributors and regulatory consultants named on the licence in each market. In Malaysia, Indonesia and Thailand the registry names this local party rather than the OEM, so this is the only way to see who controls market access for a product, who a competitor is partnered with, and whether a manufacturer uses one partner or many.
| Name | Type | Req | Description |
|---|---|---|---|
| manufacturer_id | string | yes | – |
No output schema declared.
No examples provided.
get_market_coverage ~321
THE cross-market question, answered in one call: every market where this manufacturer IS registered and every market where they are NOT. Returns per-market registration and active-registration counts and the source registries, plus the markets absent from their footprint — which is the gap a market-access team is usually looking for ("registered in Indonesia and Thailand, missing in the Philippines"). Prefer this over get_registrations when the question is about market presence rather than individual products. A `marketAccess` block may also appear. It is NOT a registration and is excluded from marketCount and every count in this response: it reports market access held on another basis — currently PMDA foreign manufacturer accreditation, which licenses a manufacturing SITE to make devices for Japan, precedes product approval and outlives individual products. When it is present alongside Japan in `absent`, both are true and the distinction matters: the company can supply the market but has no Japanese product approval visible to us. Do not describe that as being registered in Japan, and do not add it to a market count.
| Name | Type | Req | Description |
|---|---|---|---|
| manufacturer_id | string | – | The Meridian Trace manufacturer _id, from search_manufacturer |
| name | string | – | Company name, as an alternative to manufacturer_id. Resolves the same way search_manufacturer does and uses the best match. |
| ticker | string | – | Listed ticker (e.g. "MDT"), as an alternative to manufacturer_id or name. Covers US-listed registrants; many large device makers are private or listed only outside the US and cannot be reached this w… |
No output schema declared.
No examples provided.
get_recent_registrations ~197
Registrations newly added to Meridian in the last N days, optionally filtered by market, risk class or device type — the competitor-monitoring feed. Ordered by when we first saw the record, so it surfaces market entries as they appear rather than by approval date. US PMA supplements are excluded: they are labeling and site changes against an existing approval, not new registrations. Filtering by market is much faster — unfiltered across all markets can take up to 15 seconds, a market or two returns in about a second.
| Name | Type | Req | Description |
|---|---|---|---|
| days | number | – | Look-back window, 1-180 (default 30) |
| device_type | string | – | Resolved GMDN device type |
| limit | number | – | Max results (default 50, max 100) |
| markets | array | – | ISO2 codes, e.g. ["TH","ID"] |
| risk_level | string | – | Low | Medium | High |
No output schema declared.
No examples provided.
get_registration Get one registration in full ~153
One registration, complete. Everything get_registrations returns for that row, plus the registry's own market-specific fields under `registryFields` — Korea's renewal window, Australia's intended purpose, Saudi's authorisation pathway, the EUDAMED device attributes (implantable, sterile, reusable, measuring, latex, tissue origin, legislation), and the manufacturer address — none of which fit a list row. `sourceUrl` links the authority's own record so you can check us. Reading one device exhaustively costs the same as seeing it in a list, and re-reading it is free.
| Name | Type | Req | Description |
|---|---|---|---|
| registration_id | string | yes | Registration id from get_registrations, find_similar_devices or get_recent_registrations. |
No output schema declared.
No examples provided.
get_registration_timeline ~224
New registrations per year for a manufacturer, split by market — the pace at which a company is entering markets and launching products, years before it appears in reported revenue. Built from each registry's own approval date, so it reaches back as far as the registry publishes (56 years for the US). Every market carries a historyQuality flag: complete_archive and retains_lapsed series are safe to trend, current_state_only markets publish only today's position and undercount anything since withdrawn. Use for entry velocity, launch cadence, and comparing two competitors' expansion over time.
| Name | Type | Req | Description |
|---|---|---|---|
| from_year | number | – | First year to include (default: 10 years ago) |
| manufacturer_id | string | – | From search_manufacturer |
| market | string | – | Restrict to one market (ISO2 or full name) |
| name | string | – | Company name, as an alternative to manufacturer_id |
| ticker | string | – | Listed ticker, e.g. "SYK" (US-listed coverage) |
| to_year | number | – | Last year to include (default: current year) |
No output schema declared.
No examples provided.
get_registrations ~354
Every individual registration held by a manufacturer — product name, registration number, status, dates, risk class and source registry — filterable by market and status. Each row also carries an `enrichment` block Meridian derived: device class as a RANK on that market's own scale ("3 of 4") rather than a label that means different things in different markets, the resolved device type, the clinical area with the number of signals that agreed on it, the FDA product code, country of origin, brand and intended use. Each row carries a `provenance` block naming any field Meridian derived (inferred, classified, translated) with a confidence band where one applies; every field NOT listed there is the registry's own value, unmodified. Use that to lean on verbatim fields and hedge on derived ones. Use get_market_coverage instead when the question is which markets a company is in.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | number | – | Results per page (default 50, max 200) |
| manufacturer_id | string | yes | – |
| market | string | – | Filter to a single market — ISO2 code (e.g. "SG") or full name (e.g. "Singapore") |
| page | number | – | Page number (default 1) |
| status | string | – | Filter by lifecycle state: "active", "expired", "cancelled" or "pending". These are applied as RULES, not string matching — a market that publishes no status (Israel, Mexico, China) is resolved from… |
No output schema declared.
No examples provided.
search_manufacturer ~150
Resolve a company name to a Meridian manufacturer entity — the entry point for every other tool. Names are unified across spelling variants and scripts, so "Medtronic", "Медтроник" and "美敦力" reach the same entity, and subsidiaries resolve to the parent that owns them. Returns up to 5 candidates with a confidence rating and their market footprint. A plain web search cannot do this: a manufacturer's Asian registrations are filed under local-script names that never appear alongside the English one.
| Name | Type | Req | Description |
|---|---|---|---|
| country | string | – | Optional ISO2 or full country name to narrow results (e.g. "SG" or "Singapore") |
| name | string | yes | Company name to search for |
No output schema declared.
No examples provided.
What is the Meridian Trace — Medical Device Registrations MCP server?
Meridian Trace — Medical Device Registrations is an MCP server listed in the public MCP registry as com.meridiantrace/medical-device-registrations. Medical device registrations across 25 markets: coverage gaps, 510(k) predicates, classification. This page covers its hosted endpoint (https://meridiantrace.com/v1/mcp).
Is the Meridian Trace — Medical Device Registrations MCP server safe to use?
Meridian Trace — Medical Device Registrations scores 77 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Meridian Trace — Medical Device Registrations MCP server expose?
Meridian Trace — Medical Device Registrations exposes 12 tools: search_manufacturer, get_registrations, get_registration, get_license_holders, find_distributors, and 7 more. Their descriptions and schemas cost roughly 2,639 tokens of context every time the server is loaded.
Does the Meridian Trace — Medical Device Registrations MCP server require authentication?
No. We connected to Meridian Trace — Medical Device Registrations without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.
Is the Meridian Trace — Medical Device Registrations MCP server still maintained?
Meridian Trace — Medical Device Registrations is still listed as active in the MCP registry. We last reached this channel on 24 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.