biopharma-catalyst-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.2.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 3.8/5 across 10 of 10 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under ISC License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/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 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![biopharma-catalyst-mcp MCP server](https://glama.ai/mcp/servers/yesc97/biopharma-catalyst-mcp/badges/card.svg)](https://glama.ai/mcp/servers/yesc97/biopharma-catalyst-mcp)

Score Badge

Copy to your README.md:

[![biopharma-catalyst-mcp MCP server](https://glama.ai/mcp/servers/yesc97/biopharma-catalyst-mcp/badges/score.svg)](https://glama.ai/mcp/servers/yesc97/biopharma-catalyst-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/yesc97/biopharma-catalyst-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server