Skip to main content
Glama

Whimbrel MedTech Analyst

by com.whimbrelresearch
OverviewDiscussionsAdmin

Companies in a signal space

space_scan
Read-onlyIdempotent

Companies already in the Whimbrel signal index for one space. Pass kind, since, new_award, phase, min_amount_usd, matching, and limit, the same filters find_signals accepts. Pass ask as the question in the caller's words. Returns a short list: the company, why it matched, and one next fact already stored. The reply answers ask from stored records.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
askNoThe question in the caller's words. The reply answers it from stored records.
kindNoOnly companies with this signal kind.
limitNoMaximum companies to return (default 25, max 50), taken from the newest matching rows in the index.
phaseNoNIH only: restrict to this program phase.
sinceNoISO date (YYYY-MM-DD); only signals on or after it. Defaults to the last 90 days.
matchingNoSpace-separated terms; each must appear in the signal's summary or abstract.
new_awardNoNIH only: first-year awards.
include_non_usNoKeep companies whose registry name reads as a non-US entity (a non-US legal form such as GmbH or Co., Ltd., or a non-US place name). Default false: those are left out of this US medtech search.
min_amount_usdNoOnly signals with a stated amount at or above this.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / kind / enum
      Previous value: -[
-  "nih_award",
-  "nsf_award",
-  "federal_contract",
-  "sbir_award",
-  "fda_clearance",
-  "fda_pma",
-  "fda_denovo",
-  "fda_breakthrough_auth",
-  "fda_hde",
-  "fda_listing",
-  "fda_recall",
-  "fda_warning_letter",
-  "fda_import_alert",
-  "fda_pma_supplement",
-  "trial_registration",
-  "funding_filing"
-]New value: +[
+  "nih_award",
+  "nsf_award",
+  "federal_contract",
+  "sbir_award",
+  "fda_clearance",
+  "fda_pma",
+  "fda_denovo",
+  "fda_breakthrough_auth",
+  "fda_hde",
+  "fda_listing",
+  "fda_recall",
+  "fda_warning_letter",
+  "fda_import_alert",
+  "fda_pma_supplement",
+  "fda_pma_original",
+  "trial_registration",
+  "funding_filing"
+]
  2. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world. The description goes beyond them by disclosing the return shape ('the company, why it matched, and one next fact already stored') and clarifying that the reply answers 'ask' from stored records only — a real behavioral constraint absent from the annotations.

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

Conciseness4/5

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

Purpose is front-loaded in the first sentence, followed by filter guidance, the ask semantics, and the return shape. Four sentences with no filler, though the 'Pass kind, since, ... Pass ask as...' construction is a little list-like and mechanical.

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

Completeness4/5

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

With no output schema, the description correctly carries the burden of describing the return value, and it does so. It also notes the implicit US-medtech scope via the include_non_us default. It could say more about how 'ask' is interpreted, but the essentials for calling the tool are present.

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

Parameters3/5

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

Schema description coverage is 100% and the enum parameters are well documented, so the schema does the heavy lifting. The description mostly restates parameter names and adds one useful cross-reference (filters mirror find_signals), which is a modest gain but no syntax or format detail beyond the schema.

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

Purpose4/5

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

States a specific verb (scan) and resource (companies already in the Whimbrel signal index for one space), which is distinguishable from find_signals. However, it never explicitly contrasts itself with find_signals beyond noting shared filters, and the 'one space' scope is asserted without a corresponding parameter, leaving the boundary slightly fuzzy.

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

Usage Guidelines3/5

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

The description implies usage by tying its filters to 'the same filters find_signals accepts' and by framing 'ask' as the caller's question, but it never states when to choose space_scan over find_signals or its other siblings. Usage is inferable rather than stated.

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

All Whimbrel MedTech Analyst 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