Skip to main content
Glama
Sign In

Whimbrel: Medtech Research

by com.whimbrelresearch.data
OverviewDiscussionsAdmin

Find companies

find
Read-onlyIdempotent

Use this when the user asks "who should I reach out to", for prospects, leads or targets, or for companies in a device area (neuromod, ortho, cardio, catheters). Finds US medical device companies by device, technology or space, a role being hired, a state or a date. One search across every kind of signal, answered as companies: a device, technology or space in plain words (about), and optionally a role being hired, a US state or a date. Looks at device trials, FDA device makers, filings and news, and hiring, folds them into one row per company with its evidence and sources, leaves out the rep's clients and the companies that are not a fit, and ranks the rest for what was asked and what the rep's firm sells. With no device or role named ("who should I reach out to?"), it leads with the companies Whimbrel ranks first for the rep's firm. Device recalls and CDRH warning letters are on each company's record (company), not in this search; say so rather than treating an inspection as a recall. Returns the total that matched and a page of companies, each with in_targets and watched when they hold; next_cursor gets the next page.

Input Schema

NameRequiredDescriptionDefault
askNoOptional: the rep's request in their words, when it says more than about does (e.g. 'who just raised money and is still pre-clearance').
roleNoOptional: a role being hired, e.g. 'design transfer', 'sterilization'.
sortNoOptional: fit orders by Fit for the rep's firm alone, best first, even when about or role is given.
aboutNoA device, technology or space, e.g. 'balloon catheter', 'spinal implants', 'wearable glucose'.
limitNoCompanies per page (default 15, up to 100).
sinceNoOptional ISO date; evidence on or after it.
stageNoOptional: only companies at this stage.
stateNoOptional US state name.
cursorNonext_cursor from the page before, for the next page.
looking_forNoOptional: limit to some kinds of evidence.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / cursor
      Added value: +{
+  "description": "next_cursor from the page before, for the next page.",
+  "type": "string"
+}
    • changedInput schema / properties / limit / description
      Previous value: -"Most companies to return (default 15, max 25)."New value: +"Companies per page (default 15, up to 100)."
    • addedInput schema / properties / sort
      Added value: +{
+  "description": "Optional: fit orders by Fit for the rep's firm alone, best first, even when about or role is given.",
+  "enum": [
+    "fit"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / stage
      Added value: +{
+  "description": "Optional: only companies at this stage.",
+  "enum": [
+    "pre-FDA",
+    "on the market"
+  ],
+  "type": "string"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / ask
      Added value: +{
+  "description": "Optional: the rep's request in their words, when it says more than about does (e.g. 'who just raised money and is still pre-clearance').",
+  "type": "string"
+}
  3. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial beyond that: it discloses the evidence sources folded in, that results are deduped to one row per company, that the rep's own clients and non-fit companies are excluded, that ranking is by fit to what the firm sells, and the pagination contract (total, page, next_cursor, in_targets/watched).

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?

Front-loaded with the trigger condition, which is good, but the middle is repetitive — the device/role/state/date filter set is stated twice in near-identical wording. Dense and informative, yet a trim of that duplicated clause would lose nothing.

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?

For a 10-parameter, zero-required search tool with no output schema, the description does the necessary work: it explains the ranking logic, the exclusion filters, the per-company evidence/source structure, the flags, and pagination via next_cursor. Nothing an agent needs to call it correctly is missing.

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 baseline is 3, but the description adds real meaning: `about` is plain words for a device/tech/space, `ask` is for requests that say more than `about`, `sort=fit` overrides about/role ordering, and `limit`/`cursor` relate to the returned next_cursor. It stops short of clarifying edge cases like `since` vs. `looking_for` interaction.

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?

States a specific verb and resource — finds US medical device companies — and enumerates the searchable dimensions (device/technology/space, hiring role, state, date). It also explicitly routes a related need elsewhere: recalls and CDRH warning letters live on the company record, not in this search, which separates it from the `company` 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?

Opens with the exact user phrasing that should trigger it ('who should I reach out to', prospects, leads, targets, device areas) and explains the no-filter fallback behavior. It also carves out what NOT to use it for (recalls, warning letters) and says to tell the user rather than misread an inspection as a recall.

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

All Whimbrel: Medtech Research 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