Provides access to biomedical literature via NCBI E-utilities, enabling searches for recent publications on drugs, mechanisms, or diseases.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@biopharma-catalyst-mcp audit MRK Keytruda"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A forensic biopharma research MCP server — pulls catalyst-grade signals from 6 free, authoritative sources (ClinicalTrials.gov, PubMed, SEC EDGAR, SEC XBRL companyfacts, openFDA, Yahoo Finance) and hands them to your LLM. Includes a server-side aggregator that runs the full forensic workflow in one tool call and returns a deterministic verdict.
Built for the workflow most retail biopharma analysts actually run: a ticker hits the radar, you spend 2–4 hours grinding Google Scholar, FDA pages, EDGAR, and the options chain to decide if the catalyst story holds up. This compresses that to ~30 seconds.
Related MCP server: Healthcare Compliance MCP
audit_catalystSingle tool, single call, single verdict. Works on any sponsor / drug combination — no hardcoded tickers anywhere.
audit_catalyst(ticker="MRK", drug="Keytruda", sponsor="Merck")
→ Verdict: CLEAN (MED)
Primary finding: Tried to break thesis. Approved 20260424. (1 secondary
concern noted in signals)
Signals fired:
[A-BEAR] AMENDED_AFTER_COMPLETION_NO_RESULTS — NCT04700072
[S-BULL] RECENT_FDA_APPROVAL — 20260424
Math: positive cash flow, IV 29.1%, insider net $0.00MA CLEAN verdict is the highest praise this tool gives. It means the auditor cross-referenced 9 sources, tried to break the bull thesis, and couldn't (or could only surface secondary concerns that don't outweigh an S-tier bull signal). That's a stronger long signal than a generic "BUY" rating, because failing to break a thesis is harder than confirming it.
The verdict scale:
CLEAN — tried to break the thesis, couldn't. Confidence drops if A-tier concerns surface.
FLAG — A-tier bear signal fired without an offsetting S-tier bull. Data ambiguous; look harder.
BEAR_SIGNAL — at least one S-tier bear fired (terminated trial, FDA rejection, dilution risk, etc.). Confidence rises with multiple S-tier bears.
BLACK_FLAG — Going Concern disclosed by auditors + cash runway under 6 months. Equity at high risk of zero.
DISQUALIFIED — insufficient data tied to the company. Try a different drug or query the underlying connectors directly.
The math (cash runway, months to catalyst, insider sentiment, ATM IV, catalyst date) is also returned for the user to inspect. The LLM narrates; the verdict is code.
If you'd rather have the LLM run the workflow itself across the individual tools, drop this prompt into your MCP client as a custom instruction or system prompt:
You are a Tactical Biopharma Auditor. Your goal is to cross-reference company PR
against raw data from ClinicalTrials.gov, PubMed, SEC EDGAR, openFDA, and the
options market to find discrepancies. You are looking for "Trial Drift" and
"Signal Decay."
When auditing a ticker/drug, run this workflow:
1. Trial Drift Audit (search_clinical_trials)
- Flag terminations, withdrawals, or COMPLETED status without a results readout.
- If a Phase 2/3 trial has a completionDate in the past but the market is still
waiting for "upcoming data," flag the delay as a negative signal.
- The connector emits an `auditFlag` field; surface it in your output.
2. Literature Signal Check (search_pubmed)
- Scan abstracts for skepticism keywords: "controversial," "mixed results,"
"safety concerns," "marginal improvement," "failed to demonstrate."
- Compare to standard of care if abstracts mention comparators.
3. Filing Density & FDA History (get_sec_filings, get_fda_activity)
- Count 8-K (current event) frequency. A flurry of 8-Ks before a catalyst
usually signals structural changes or pre-announcing trouble.
- Has the drug or sponsor had NDAs marked CRL (rejected), WD (withdrawn), or
received supplements with regulatory friction?
4. Market Pricing (get_market_data)
- Check ATM IV. If IV is extremely high (>150%) but the bull case seems
"certain," the market is pricing a binary failure risk that needs identifying.
Output format:
* Audit Verdict: [CLEAN / FLAG / BEAR SIGNAL]
(CLEAN means: tried to break the thesis, couldn't.)
* Primary Discrepancy: One sentence on the biggest data point that contradicts
the company's PR.
* Key Risks: 2-3 specific risks found in CT.gov or PubMed.
* Data Density: Summary of how much info we actually have vs. how much is
missing.Then ask: audit ticker SRPT, drug elevidys (or whatever).
A CLEAN verdict is the highest praise this tool gives — it means the auditor tried to find a hole in the thesis and couldn't. That's a stronger long signal than a generic bull stamp.
Ten tools — nine raw connectors plus the aggregator:
Tool | Source | What it does |
| (aggregator) | Headline tool. Runs the full Tactical Auditor workflow against (ticker, drug). Deterministic verdict. |
| ClinicalTrials.gov v2 API | Pipeline + status by intervention; flags terminations, withdrawals, completed-without-readout |
| NCBI E-utilities | Recent literature on a drug / mechanism / disease |
| SEC EDGAR | Last 10 filings (10-K, 10-Q, 8-K, S-1) by ticker |
| SEC XBRL companyfacts | Cash, quarterly burn, runway months, Going Concern flag |
| SEC EDGAR Form 4 XML | Role-classified insider transactions (clinical/financial/admin), coordinated exit detection (72h window), Net Insider Sentiment ($), 10b5-1 detection |
| Yahoo Finance | Short % of float, days to cover, MoM delta — feeds SHORT_INTEREST_SPIKE and SHORT_SQUEEZE_POTENTIAL signals |
| ClinicalTrials.gov v2 API | Trial protocol + amendment proximity (goalpost detection) |
| Yahoo Finance | Quote + full options chain (IV, strikes, expirations) |
| openFDA | NDA/BLA submissions with decoded status (AP, CRL, WD, etc.); auto-fallback drug→sponsor |
All sources are free, no API keys required.
git clone https://github.com/yesc97/biopharma-catalyst-mcp.git
cd biopharma-catalyst-mcp
npm install
npm run buildAdd to your MCP client config (e.g. ~/.config/claude/claude_desktop_config.json):
{
"mcpServers": {
"biopharma-catalyst": {
"command": "node",
"args": ["/absolute/path/to/biopharma-catalyst-mcp/build/index.js"],
"env": {
"SEC_USER_AGENT": "Your Name <your-email@example.com>"
}
}
}
}SEC_USER_AGENT is required by SEC EDGAR — use a real contact email or you'll be rate-limited.
For headless runs without an MCP client:
node build/cli.js <TICKER> "<DRUG_NAME>" "<SPONSOR_NAME>"
node build/cli.js PFE "Comirnaty" "Pfizer"
node build/cli.js MRK "Keytruda" "Merck"
node build/cli.js LLY "Mounjaro" "Eli Lilly"The CLI prints a structured human-readable snapshot — same data the MCP tools expose.
Biopharma research signal lives at the pipeline drug level, not the corporate level. Searching CT.gov for "Pfizer" returns hundreds of unrelated trials across every therapeutic area. Searching for Comirnaty returns the specific vaccine trials that drive regulatory outcomes. Always feed the tools the drug name (brand or generic), and use the ticker only for market data + SEC filings.
Institutional-grade biopharma research requires analyzing the world's largest pipelines. A few examples from live runs:
audit_catalyst("LLY", "Mounjaro", "Eli Lilly")Verdict: CLEAN (HIGH)
Primary finding: Tried to break thesis. Strong pipeline density with 10+
ongoing Phase 3 trials.
Signals:
[S-BULL] RECENT_FDA_APPROVAL — 20260315
[A-BULL] INSIDER_BUYING — net $2.4M over 90daudit_catalyst("PFE", "Comirnaty", "Pfizer")Verdict: CLEAN (MED)
Primary finding: Massive data density; no S-tier bear signals detected in
last 12 months.
Signals:
[A-BEAR] 8K_CLUSTER — 4 filings in last 30d (normal for earnings)
[S-BULL] RECENT_FDA_APPROVALaudit_catalyst("MRK", "Keytruda", "Merck")Verdict: CLEAN (MED)
Primary finding: Approved 20260424. (1 secondary concern noted in signals)
Signals:
[A-BEAR] AMENDED_AFTER_COMPLETION_NO_RESULTS — NCT04700072
[S-BULL] RECENT_FDA_APPROVAL10b5-1 plans don't exempt insider selling from the bear column — management chose to schedule those sales. Real money out the door is real money out the door.
CT.gov protocol diff — currently we detect late-stage amendments via the proximity heuristic (last update vs primary completion date). The CT.gov v2 API does not expose what changed in an amendment. To detect specific endpoint changes (the canonical goalpost move), we'd need to scrape the public version-history web UI or wait for an API update.
FDA AdComm forward calendar — currently we surface FDA submission history. A forward calendar of advisory committee meetings would let users plan around binary regulatory events.
Polygon / Tradier connector — Yahoo's options data is incomplete on illiquid small-cap biotech. A paid market-data option for power users.
Sponsor-class weighting — currently the aggregator filters trials to those sponsored by the queried company. Industry-academic partnerships and NIH-sponsored trials are excluded. Could weight rather than filter.
10-K MD&A scan — extract the "Risk Factors" section and look for management-disclosed risks beyond the Going Concern check.
After any change, rebuild and run the MCP stdio smoke test:
npm run build
node /path/to/verify-mcp.mjs # 9-tool stdio handshake + 1 invocation eachFor the aggregator specifically:
node build/cli.js <TICKER> "<DRUG>" "<SPONSOR>"Both should complete in under 30 seconds against live APIs. If they don't, check whether SEC has rate-limited you (see Per-source caveats below).
Create src/connectors/<name>.ts. Export a single async function that returns a structured shape (no LLM-dependent fields, just data).
If it hits sec.gov or data.sec.gov, wrap each axios call in throttleSec(() => axios.get(...)).
Wire it in src/index.ts: import, add to the tools/list schema, add the dispatch case in the request handler.
Optionally wire into audit_catalyst — add to the Promise.allSettled block and write the signal logic against the spec.
Add a smoke test invocation to your local verify-mcp.mjs.
SEC.gov: 10 req/sec hard cap. Throttled to ~5 req/sec via sec-throttle.ts. Going over triggers a 10-minute IP block. The SEC_USER_AGENT env var must be a real contact email — fake placeholders are rate-limited harder.
CT.gov v2: No protocol-diff endpoint. The goalpost detector uses a proximity heuristic (firstPost vs primaryCompletion vs lastUpdate). True diff requires scraping the public version-history UI; queued for v1.2.
Yahoo Finance: Schema validation is suppressed because Yahoo drifts on illiquid biotech option chains. Calls return what they can; expect occasional empty option chains.
openFDA: drugsfda.json covers NDA/BLA submission history but not always forward PDUFA dates. Use CT.gov completionDate as the leading catalyst indicator.
Form 4 XML: EDGAR's primaryDocument field points to the HTML wrapper, not the structured XML. The connector lists each filing's folder via index.json and finds the .xml entry. Capped at 25 most recent filings per audit to bound cost.
SEC_USER_AGENT must stay in local environment variables and never be committed to version control. It contains a real contact email and gets logged on the SEC side; treating it as a secret keeps it out of public git history and avoids inadvertent doxxing.
.env and .env.local are gitignored by default in this repo; keep your contact details there.
If you fork this project, set your own SEC_USER_AGENT — do not reuse another user's.
Agent context files (GEMINI.md, CLAUDE.md, .gemini/, .claude/) are also gitignored; never commit those, they may contain operating notes / strategy details meant for local use only.
Patch (x.x.+1): bug fixes, doc tweaks, no schema changes.
Minor (x.+1.0): new tools, new connectors, additive signal logic, schema additions to existing tools.
Major (+1.0.0): breaking schema changes (renamed fields, removed tools), new required env vars, MCP protocol upgrades.
Bump version in package.json to match the change scope.
Update README "headline tool" or "Forensic case studies" sections if behavior changed.
Run npm run build && node verify-mcp.mjs — must be 9/9 passing.
Commit using conventional-commit style (feat:, fix:, chore:).
Tag the commit: git tag v<X.Y.Z>.
Push to your remote when ready; optional npm publish if you maintain a public npm release.
Attila Kovacs (yesc97)
Email: igenccc@gmail.com
GitHub: yesc97
Not investment advice. This is research automation. The synthesis step — and the trade — is on you.
ISC
FORENSIC AGGREGATOR. Runs all 8 connectors in parallel against (ticker, drug) and returns a deterministic verdict: CLEAN | FLAG | BEAR_SIGNAL | BLACK_FLAG. Encodes the full Tactical Auditor logic — terminations, FDA rejections, late-stage protocol amendments, dilution risk (runway vs catalyst), Going Concern disclosure, insider unloading, 8-K clusters, literature skepticism. CLEAN means: tried to break the thesis, couldn't. The strongest long signal this tool gives.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | The stock ticker symbol | |
| drug | Yes | Drug name (brand or generic) — biopharma signal lives at the drug level, not the company level | |
| sponsor | No | Optional sponsor company name (used for FDA fallback when drug query returns empty) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses parallel execution, deterministic verdict categories, and explains the meaning of CLEAN. It does not mention auth needs, rate limits, or side effects, but the behavioral summary is fairly transparent for a composite tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose. While slightly verbose, each sentence contributes useful information (e.g., verdict categories, CLEAN definition). Could be tightened but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description adequately explains the tool's function, verdict categories, and logic behind CLEAN. It lacks precise return format details but is sufficient for an aggregator tool with deterministic output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description adds value by explaining why drug is at drug level and that sponsor is optional for FDA fallback, providing context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'FORENSIC AGGREGATOR' and specifies that it runs 8 connectors in parallel to return a deterministic verdict (CLEAN | FLAG | BEAR_SIGNAL | BLACK_FLAG). It distinguishes itself from sibling tools which are individual data sources, making the purpose and differentiation clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a composite signal and calls it 'the strongest long signal this tool gives,' but lacks explicit guidance on when not to use it or alternatives. It does contrast with siblings indirectly by being an aggregator, but could be more explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get FDA submission and approval activity for a drug or sponsor (NDA/BLA filings, approvals, supplements). Use kind='drug' for drug name (brand or generic) or kind='sponsor' for company sponsor name. Submission status codes are decoded (AP=approved, CRL=rejection, WD=withdrawn). Supports auto-fallback from drug to sponsor if results are empty.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Drug name or sponsor name to search | |
| kind | No | Whether the query is a drug name or sponsor company name | |
| sponsorFallback | No | Optional: Company sponsor name to fall back to if drug search returns nothing |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses auto-fallback behavior and decoding of status codes. Lacks disclosure of rate limits or error handling, but adds significant context beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. Purpose is front-loaded, and each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Input semantics are well-covered, but no output schema or description of return fields is provided. For a tool with no output schema, the description should mention what data fields are returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds meaning: clarifies kind values, explains query accepts brand/generic names, and explains sponsorFallback parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets FDA submission and approval activity for a drug or sponsor, mentioning specific filing types (NDA/BLA, approvals, supplements). This is distinct from sibling tools like get_insider_transactions or get_sec_filings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains when to use kind='drug' vs kind='sponsor' and describes auto-fallback behavior. However, it does not explicitly distinguish from alternatives like search_clinical_trials for drug-related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get insider Form 4 transactions for a ticker over the last N days. Returns individual transactions, total sales/purchases in dollars, and a Net Insider Sentiment score (purchases - sales). Detects 10b5-1 scheduled sales but does not exempt them.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | The stock ticker symbol | |
| windowDays | No | Lookback window in days (default 90) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It adds value by explaining the tool returns individual transactions, total sales/purchases in dollars, a Net Insider Sentiment score, and detects 10b5-1 scheduled sales without exempting them. This goes beyond the schema and provides useful behavioral context, though it omits potential rate limits or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: first states purpose, second outlines outputs, third adds behavioral nuance. No superfluous information, clearly structured and front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two simple parameters, no output schema, and moderate complexity, the description covers purpose, outputs, and a key behavioral detail (10b5-1 handling). It could mention authorization requirements or rate limits, but overall it is sufficiently complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents both parameters. The description mentions 'ticker' and 'windowDays' in context but does not add new syntactic detail beyond what the schema provides. The baseline of 3 is appropriate as there is marginal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get insider Form 4 transactions for a ticker over the last N days.' It specifies a concrete verb ('Get'), resource ('insider Form 4 transactions'), and scope ('ticker', 'N days'). This distinguishes it from siblings like 'get_sec_filings' or 'get_market_data'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for analyzing insider transactions and mentions detection of 10b5-1 sales, but it does not explicitly state when to use this tool versus alternatives like 'get_sec_filings' which may also contain insider data. No 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current price and options data for a stock ticker
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | The stock ticker symbol |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states what data is retrieved. It does not disclose behaviors such as rate limits, data freshness, required permissions, or whether the operation is read-only. For a tool with no annotations, this lack of behavioral detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple tool, though it could be slightly more informative without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, no output schema, and no annotations, the description is minimally adequate. It states the core function but lacks details on output structure or behavior, which would help an agent handle responses correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the single 'ticker' parameter, adequately explaining it as 'The stock ticker symbol.' The description does not add any additional meaning or context beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get current price and options data for a stock ticker,' using a specific verb and resource. Among sibling tools focused on FDA, SEC, and clinical data, this tool's market data purpose is immediately distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. However, the tool's focus on stock market data is implied by its name and description, and sibling tools cover unrelated domains, so context provides some differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current protocol details + amendment proximity for a clinical trial by NCT ID. Flags late-stage protocol amendments (the 'goalpost move') by computing how far into the trial timeline the last update happened. Cannot detect WHAT changed (CT.gov v2 API does not expose protocol diffs) — only WHEN.
| Name | Required | Description | Default |
|---|---|---|---|
| nctId | Yes | ClinicalTrials.gov NCT identifier (e.g. NCT04994483) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It explicitly states that the tool computes amendment proximity by timing of last update and cannot detect what changed, providing clear behavioral transparency about capabilities and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The first sentence delivers the core purpose, and the second adds a critical limitation. Every word is necessary, and the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (one string parameter) and no output schema, the description adequately explains what is returned (protocol details and amendment proximity) and a limitation. However, it could be improved by specifying the nature of the protocol details (e.g., title, phase) for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter nctId described. The description adds context that the ID is for a clinical trial, but this overlaps with the schema description. It does not add new semantic meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'current protocol details + amendment proximity' for a clinical trial by NCT ID. It uses a specific verb 'Get' and resource, and distinguishes from sibling tools like search_clinical_trials, which are for searching rather than fetching a snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to get protocol snapshot and amendment timing) but does not explicitly provide when-not-to-use scenarios or alternatives. It does mention a limitation (cannot detect WHAT changed), which offers some guidance on appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent SEC filings (10-K, 10-Q, 8-K, S-1) for a stock ticker.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | The stock ticker symbol |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only states the basic action (get filings) but does not disclose data freshness, ordering, rate limits, or whether it returns full content or metadata. This is minimal for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that communicates the core purpose without unnecessary words. It is front-loaded and efficient, though a few additional details (like recency definition) would not hurt.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (1 param, no output schema), the description covers the basic what and for whom. However, it lacks definition of 'recent' and does not hint at output structure. Basic completeness but leaves unanswered questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (ticker described in schema). The description adds context by specifying 'for a stock ticker', which aligns with the schema. No additional meaning like format or examples beyond what schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the resource 'SEC filings' with concrete filing types (10-K, 10-Q, 8-K, S-1). It clearly targets stock tickers, distinguishing it from sibling tools like get_market_data or get_xbrl_facts. However, 'recent' is ambiguous and could be clarified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives (e.g., get_xbrl_facts for detailed financial data). The description implies it's for recent filings but doesn't exclude other uses or provide context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get short interest data for a ticker — short % of float, days to cover, and month-over-month delta. Used to detect SHORT_INTEREST_SPIKE (delta >20%, bear) and SHORT_SQUEEZE_POTENTIAL (days to cover >5, bull).
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | The stock ticker symbol |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read operation ('get') and specifies returned fields, but does not disclose idempotency, authentication needs, rate limits, or potential errors. This lack of behavioral detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core function, then application context. Every word contributes value with no redundancy or fluff. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers the main purpose and provides interpretation thresholds, but lacks output schema details, error conditions, or data freshness. For a simple single-parameter tool, it is minimally complete but has room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter 'ticker' already described in schema. Description adds context about what ticker is used for (get short interest data), but no additional semantic detail about parameter format or constraints. Baseline 3 is appropriate as schema does most of the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states what the tool does: get short interest data for a ticker, listing specific fields (short % of float, days to cover, delta). It distinguishes from sibling tools by focusing on short interest, a unique niche among diverse tools like get_fda_activity or get_insider_transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly mentions use cases for detecting SHORT_INTEREST_SPIKE and SHORT_SQUEEZE_POTENTIAL with thresholds, providing clear context. However, it does not compare with sibling tools or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get structured financial facts from SEC XBRL for a ticker — cash, quarterly burn, runway months, and Going Concern disclosure flag. Used by the Tactical Auditor to detect dilution risk (runway shorter than time to next catalyst).
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | The stock ticker symbol |
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 lists the specific facts returned (cash, burn, runway, going concern) but does not disclose whether the operation is read-only, side effects, permissions needed, or rate limits. The behavioral information is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first defines what the tool does, the second gives a use case. Excellent structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description adequately lists the return values (cash, burn, runway, going concern). It could mention data freshness or limitations, but overall it's fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter 'ticker' with a clear description. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets structured financial facts from SEC XBRL, specifying cash, quarterly burn, runway months, and Going Concern flag. It differentiates from siblings by being focused on XBRL financial data, which is distinct from tools like get_sec_filings or get_market_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific use case: 'Used by the Tactical Auditor to detect dilution risk (runway shorter than time to next catalyst).' This gives clear context for when to use, though it does not explicitly exclude alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search ClinicalTrials.gov for studies by intervention (drug or company name)
| Name | Required | Description | Default |
|---|---|---|---|
| intervention | Yes | The name of the drug or company to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It reveals only the input schema and the target database, but omits traits such as pagination, result count limits, data freshness, rate limits, or whether it returns full study details or summaries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It front-loads the action and resource, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description provides the essential purpose but lacks details on return format, result size, or any special behavior. It is minimally complete but could be enhanced with typical search behavior info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description essentially repeats the schema's parameter description ('drug or company name'). No additional semantic value is added beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search'), the specific resource ('ClinicalTrials.gov for studies'), and the filtering criterion ('by intervention (drug or company name)'). It effectively distinguishes from sibling tool 'search_pubmed' which searches a different database.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search_pubmed' or when not to use it. The description only states what it does, lacking any context about preferred scenarios or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search PubMed for scientific papers by term (drug name, condition, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | The search term |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It only states 'Search PubMed' without disclosing rate limits, authentication needs, result format, or pagination behavior. Insufficient for a public API tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single clear sentence with no wasted words. Front-loaded with purpose, efficiently covering action, resource, and parameter hints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, description is minimally adequate. However, lacks output format details, and no output schema is provided. Adequate but leaves agent guessing about return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the 'term' parameter fully. Description adds value by providing examples ('drug name, condition, etc.'), going beyond the schema description. Baseline 3 plus enhancement yields 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Search' and resource 'PubMed for scientific papers', with examples of terms like drug name or condition. It distinguishes from sibling tool 'search_clinical_trials' by specifying scientific papers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context (searching by term) but provides no explicit when-to-use or when-not-to-use guidance. Does not mention alternatives or limitations despite having sibling search_clinical_trials.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.2.0audit_catalystget_fda_activityget_insider_transactionsget_market_dataget_protocol_snapshotget_sec_filingsget_short_interestget_xbrl_factssearch_clinical_trialssearch_pubmedScored across 10 tools
Each tool targets a distinct aspect of biopharma analysis—FDA activity, clinical trials, insider transactions, SEC filings, market data, short interest, XBRL facts, PubMed literature, and a high-level aggregator. There is no overlap; even the audit_catalyst synthesizes data from others rather than duplicating.
Tool names follow a consistent verb_noun pattern with underscores: 'get_*' for data retrieval, 'search_*' for database queries, and 'audit_catalyst' for the aggregator. The verb choice accurately reflects the action type, and all names are clear and predictable.
Ten tools is within the ideal 3-15 range for a domain-specific MCP server. Each tool covers a necessary data source or analytical function, and none feel redundant or extraneous.
The tool set covers the full lifecycle of biopharma catalyst analysis: FDA actions, clinical trials, insider trading, financials (XBRL and SEC filings), short interest, market data, and literature. The audit_catalyst aggregates these into a verdict, leaving no obvious gaps for the stated purpose.
Verified biotech catalyst calendar (PDUFA/AdComm/trial readouts) anchored to official sources.
Verify stock theses against public filings with a source-backed evidence ledger.
SEC, Congress, FDA, crypto, app reviews and live jobs: scored signals. 18 tools, free flagship.
Pharma Intel MCP — Compound tools that chain ClinicalTrials.gov,