Skip to main content
Glama
Sign In

Meridian Trace — Medical Device Registrations

by com.meridiantrace
OverviewDiscussionsAdmin

find_distributors

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, Japanese captive importers and companies whose own registrations show they make what they register. TWO COUNTS, NEVER ONE: matching is the distributors that hold registrations in the market; matchingLicenceOrTenderOnly is the ones known only from a licence list or a tender award, with no registrations of their own in our data. Those are still potential distributors (often sub-distributors) and are returned too, each row marked basis: "licence_or_tender_only"; they rank after registered holders, so pass holder_basis "licence_or_tender_only" to list them. Read the caveats in the response before quoting any number from it.

Input Schema

NameRequiredDescriptionDefault
limitNo1-25 (default 10). Capped to 3 without a paid key.
marketYesISO2 code or market name, e.g. "TH" or "Thailand". One market per call.
device_typeNoOptional 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.
holder_basisNoWhich distributors to LIST (counts always report both): "all" (default; registered holders rank first), "registrations" (hold registrations here), or "licence_or_tender_only" (known from a licence list or tender award, no registrations of their own in our data).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / holder_basis
      Added value: +{
+  "description": "Which distributors to LIST (counts always report both): \"all\" (default; registered holders rank first), \"registrations\" (hold registrations here), or \"licence_or_tender_only\" (known from a licence list or tender award, no registrations of their own in our data).",
+  "enum": [
+    "all",
+    "registrations",
+    "licence_or_tender_only"
+  ],
+  "type": "string"
+}
  2. Added

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses anonymous rate/limit behavior ('anonymous callers see the top 3 per market'), the two-count model with exact field names ('matching', 'matchingLicenceOrTenderOnly'), the 'basis' marker, ranking behavior, and a caveat about reading 'caveats' before quoting numbers. This is rich behavioral context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long and front-loaded with a parenthetical about API keys, but many sentences are necessary for the complex behavior. However, some redundancy exists (e.g., repeating the two-count explanation already in the schema) and the density could be improved. It is not overly concise but serves a complex tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description provides all necessary context: anonymous limits, the two-count model with field names, ranking, exclusions, geographic strengths, and a pointer to caveats. An agent has enough information to call this correctly and interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all parameters. The description adds value by explaining the two-count distinction and the holder_basis option in narrative form, which reinforces the schema and clarifies semantics. It does not add much beyond that, but the schema is comprehensive, so a 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('WHO COULD SELL A DEVICE IN A MARKET ... returns the local distributors and importers who hold registrations there') and explicitly distinguishes it from the sibling get_license_holders ('This is the INVERSE of get_license_holders'). An agent can tell exactly what this tool does and how it differs from its closest sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is explicit: 'Give it a market and, optionally, a device type or clinical area'. It contrasts with get_license_holders ('which starts from a manufacturer you can already name'). It also explains exclusions (regulatory consultants, authorised reps, manufacturers' subsidiaries) and the two-count logic, including when to pass holder_basis 'licence_or_tender_only'. This is unusually detailed guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Meridian Trace — Medical Device Registrations toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources