Skip to main content
Glama
Sign In

Whimbrel: Medtech Research

by com.whimbrelresearch.data
OverviewDiscussionsAdmin

Company research record

deep_record

A full research rundown on one company, for when the rep asks for one: company facts, named partners, dated events, the evidence and source behind each, and known gaps. Pass company. Pass domain when asking for new research. Pass fact as email, clearance, or trial to return that stored fact only. With no record, this does not start one on its own: ask the rep first (a new company record uses one of the plan's records for the month and takes about 5 minutes). Pass start_new_record true only after the rep says yes. A record older than a week is shown as stored, with an offer to refresh; pass refresh and start_new_record true only after the rep says yes. A new record takes minutes: wait for it yourself with research_status and don't hand the wait to the rep. Requires an active Whimbrel plan.

Input Schema

NameRequiredDescriptionDefault
factNoReturn this one stored fact and do not start a new record. Omit it for the company file.
sinceNoISO date (YYYY-MM-DD) for the What changed section. Defaults to the last 90 days.
domainNoThe company's website domain. Required for a company Whimbrel does not cover yet: when a reply asks for it, ask the rep and call again with it.
companyYesCompany name.
refreshNoResearch the company again even though a record exists. Starts only with start_new_record true.
start_new_recordNoPass true only after the rep says yes to starting a new company record. Without it, nothing is started or used.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / fact / description
      Previous value: -"Return this one stored fact and do not queue a research run. Omit it for the company file."New value: +"Return this one stored fact and do not start a new record. Omit it for the company file."
    • changedInput schema / properties / refresh / description
      Previous value: -"Force a fresh research run even when a recent record exists. A record older than a week refreshes automatically without this."New value: +"Research the company again even though a record exists. Starts only with start_new_record true."
    • addedInput schema / properties / start_new_record
      Added value: +{
+  "description": "Pass true only after the rep says yes to starting a new company record. Without it, nothing is started or used.",
+  "type": "boolean"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / domain / description
      Previous value: -"The company's website domain. Required for a company not on Whimbrel's list yet: when a reply asks for it, ask the rep and call again with it."New value: +"The company's website domain. Required for a company Whimbrel does not cover yet: when a reply asks for it, ask the rep and call again with it."
  3. Changed1 schema field changed
    • changedInput schema / properties / domain / description
      Previous value: -"The company's website domain (recommended when requesting new research; otherwise it is resolved, and the run fails honestly if it cannot be)."New value: +"The company's website domain. Required for a company not on Whimbrel's list yet: when a reply asks for it, ask the rep and call again with it."
  4. Changed1 schema field changed
    • addedInput schema / properties / since
      Added value: +{
+  "description": "ISO date (YYYY-MM-DD) for the What changed section. Defaults to the last 90 days.",
+  "type": "string"
+}
  5. Changed1 schema field changed
    • changedInput schema / properties / refresh / description
      Previous value: -"Force a fresh research run even when a recent record exists (counts against the allowance). A record older than a week refreshes automatically without this."New value: +"Force a fresh research run even when a recent record exists. A record older than a week refreshes automatically without this."
  6. Changed1 schema field changed
    • addedInput schema / properties / fact
      Added value: +{
+  "description": "Return this one stored fact and do not queue a research run. Omit it for the company file.",
+  "enum": [
+    "email",
+    "clearance",
+    "trial"
+  ],
+  "type": "string"
+}
  7. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Goes well past the annotations by disclosing quota consumption (uses one of the plan's records for the month), latency (~5 minutes), the human-confirmation gate, the >1 week staleness behavior, and the plan requirement. The annotations already signal non-read-only and open-world, so this adds real operational context; the only gap is what happens on failure or partial results.

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?

Front-loaded with what the tool returns, then the operational rules; every sentence carries a rule that would otherwise cause a wrong call. It is dense and the confirmation/staleness rules are somewhat interleaved, costing a point on structure, but nothing is boilerplate.

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?

With no output schema, the description carries the return-shape burden and does so by naming the sections returned. It covers cost, latency, approval gating, staleness, and prerequisites, which is everything an agent needs for a slow, quota-consuming, human-gated operation.

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; the description nonetheless adds relational semantics the schema only implies piecewise — that refresh is inert without start_new_record true, and that domain is only needed for uncovered companies after asking the rep. That cross-parameter coupling is genuinely useful during invocation.

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+resource: a full research rundown on one company, and enumerates the returned content (facts, named partners, dated events, evidence/source, known gaps). It also carves out the narrower mode (fact=email/clearance/trial returns a single stored fact), which separates it from lighter siblings like company or opening_line_facts.

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?

Explicit when-to-use rules: pass domain when asking for new research, pass fact for a single stored fact, do not start a record without rep approval, pass start_new_record true only after yes, and pass refresh + start_new_record for stale records. It also routes the waiting loop to research_status rather than the rep, naming the alternative tool.

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