Pharma Intel
Server Details
Pharma Intel MCP — Compound tools that chain ClinicalTrials.gov,
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.9/5 across 8 of 8 tools scored. Lowest: 3.2/5.
There is overlap between pharma_drug_profile, pharma_safety_report, and pharma_pipeline_scan, all dealing with drug information but at different scopes. Also, ask_pipeworx serves as a meta-tool that can potentially call these tools, adding ambiguity. However, descriptions help distinguish their specific focuses.
Naming is inconsistent: some tools use pharma_ prefix (pharma_drug_profile, pharma_pipeline_scan, pharma_safety_report), while others have different conventions (ask_pipeworx, discover_tools, forget, recall, remember). Mixing snake_case with plain words adds inconsistency.
With 8 tools, the count is reasonable for a pharma-focused MCP server. The set includes core drug information, safety, pipeline, memory, and a meta-search tool. Slightly over the ideal range but still appropriate.
The server covers major pharma intel needs: drug profiles, safety, pipeline, and a query tool. Minor gaps include lack of specific regulatory filings or competitor analysis, but the ask_pipeworx tool may compensate. Overall good coverage for its domain.
Available Tools
8 toolsask_pipeworxAInspect
Ask a question in plain English and get an answer from the best available data source. Pipeworx picks the right tool, fills the arguments, and returns the result. No need to browse tools or learn schemas — just describe what you need. Examples: "What is the US trade deficit with China?", "Look up adverse events for ozempic", "Get Apple's latest 10-K filing".
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Your question or request in natural language |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It reveals that the tool selects the best data source and fills arguments, but does not disclose failure modes, latency, or which tools it might call. This is adequate but not detailed.
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 concise (three sentences) with examples front-loaded. Every sentence adds value, though it could be slightly tighter without losing meaning.
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 parameter set and absence of output schema, the description is sufficiently complete. It clarifies the tool's role as an orchestrator, which is important given the sibling tools that are domain-specific.
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% for the single parameter 'question'. The description adds value by explaining how the parameter is used (natural language request) and giving examples, but the schema already describes it as a string for the user's question.
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 accepts natural language questions and returns answers by selecting appropriate data sources. It distinguishes from siblings by explicitly positioning itself as an intelligent orchestrator that abstracts away tool selection and schema details.
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 explains when to use it ('just describe what you need') and provides concrete examples. However, it does not explicitly state when not to use it or compare to alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_toolsAInspect
Search the Pipeworx tool catalog by describing what you need. Returns the most relevant tools with names and descriptions. Call this FIRST when you have 500+ tools available and need to find the right ones for your task.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of tools to return (default 20, max 50) | |
| query | Yes | Natural language description of what you want to do (e.g., "analyze housing market trends", "look up FDA drug approvals", "find trade data between countries") |
Tool Definition Quality
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 that it returns tool names and descriptions, but does not mention potential behavior like the quality of search results, whether it uses semantic search, or any limitations like rate limits. A score of 3 is appropriate as it provides basic but not comprehensive behavioral context.
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 long, each adding value: first defines purpose, second describes output, third gives usage guidance. It is concise and front-loaded. However, the last sentence could be slightly more concise by combining with the previous, but overall very 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 tool's simplicity (search, return list), the description is mostly complete. No output schema exists, so the description should indicate what is returned (it does: tool names and descriptions). It covers the primary use case and guidance. Could mention that results are sorted by relevance, but not strictly necessary.
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%, so baseline is 3. The description does not add extra meaning beyond what the schema provides, as it only describes the tool's overall purpose. No additional parameter details are given, so score remains at 3.
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 searches a catalog and returns relevant tools, using specific verbs ('Search', 'Returns') and resource ('Pipeworx tool catalog'). It distinguishes itself by instructing to call this FIRST when many tools are available, differentiating from sibling tools that perform specific tasks like pharma lookups.
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?
Explicitly says 'Call this FIRST' when 500+ tools are available, providing clear when-to-use guidance. It does not need to mention when not to use since its purpose is discovery before other tools, and siblings are specific domain tools, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forgetBInspect
Delete a stored memory by key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key to delete |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It correctly indicates destructive behavior ('Delete'), but lacks details on irreversibility, confirmation, or side effects.
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 concise sentence front-loading the action and target. No unnecessary words, but could include a brief usage note without losing 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?
For a simple 1-parameter tool with no output schema, the description is adequate. However, it lacks context about confirmation, error handling, or impact on related data.
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% for the single required parameter 'key', with a clear description. The tool description adds no further meaning beyond what the schema provides, baseline score 3.
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 ('Delete') and the target ('a stored memory by key'). It is unambiguous and distinct from siblings like 'remember' (store) and 'recall' (retrieve).
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 on when to use this tool versus alternatives (e.g., 'recall' for retrieval, 'remember' for storage). No mention of prerequisites or when deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pharma_drug_profileAInspect
Look up a drug's FDA approval status, dosage forms, interactions, and active trials. Returns approval dates, formulations, known drug interactions, and ongoing trial details. E.g., search "ozempic" or "metformin".
| Name | Required | Description | Default |
|---|---|---|---|
| drug_name | Yes | Drug name (brand or generic) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so description carries full burden. It indicates the tool is a read operation (fetches data) and lists what data is returned. However, it does not disclose potential rate limits, data freshness, or whether the call might be slow due to aggregating multiple sources.
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: first lists what the tool returns, second provides input format with examples. No wasted words, but could be slightly more structured (e.g., bullet points) for clarity.
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 simple input schema (1 string param) and no output schema, the description provides a good overview of what the tool returns. It covers the main use case. Could mention that the output is a single object with multiple fields, but not necessary for 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 description coverage is 100% for the single parameter, which already describes 'drug_name' as 'Drug name (brand or generic)'. The description adds examples and context that it accepts brand or generic names, enhancing semantics 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?
Description clearly states the tool returns a comprehensive drug dossier including FDA approvals, labels, adverse events, RxNorm properties, interactions, and clinical trials. It specifies the input as a drug name with examples. This differentiates it from siblings like pharma_pipeline_scan and pharma_safety_report.
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 implies usage when a comprehensive drug profile is needed, but does not explicitly state when to use this vs. alternatives like pharma_safety_report. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pharma_pipeline_scanAInspect
Search clinical trials by condition (e.g., "lung cancer") or sponsor (e.g., "Pfizer"). Returns trial phases, recruitment status, and approved treatments for that indication.
| Name | Required | Description | Default |
|---|---|---|---|
| sponsor | No | Pharmaceutical company or sponsor name | |
| condition | No | Disease or condition (e.g., "breast cancer") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return categories (trial counts, recruiting studies, approved drugs) but does not mention whether the data is real-time or cached, any rate limits, or the scope of the database. No contradiction with annotations as annotations are empty.
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 two sentences long, front-loads the key action ('pipeline analysis'), and efficiently conveys filtering options and return types. It could be slightly more structured (e.g., bullet points) but is concise and scannable.
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 moderate complexity (two optional parameters, no output schema, no nested objects), the description covers the main aspects: purpose, filters, and return categories. It lacks details on whether results are aggregated or individual, but the provided information is sufficient for an agent to decide to use it.
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%, meaning the schema already describes both parameters adequately. The description adds context by providing example values (e.g., 'lung cancer', 'Pfizer') and clarifying that at least one parameter is expected, but it does not add meaning beyond what the schema already provides. 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's purpose: clinical trial pipeline analysis. It specifies the two primary filtering dimensions (condition and sponsor) and explicitly lists what results are returned (trial counts, recruiting studies by phase, FDA-approved drugs), making it highly specific and distinguishing it from sibling tools like pharma_drug_profile.
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 clear context on when to use this tool: for pipeline analysis by condition or sponsor. It implicitly excludes other sibling tools (e.g., pharma_drug_profile for individual drug details), but does not explicitly state when not to use it or mention alternatives. The examples of condition and sponsor values are helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pharma_safety_reportAInspect
Check adverse event frequency, severity patterns, and contraindications for a drug. Returns safety profiles, risk data, and recall history. E.g., search "aspirin".
| Name | Required | Description | Default |
|---|---|---|---|
| drug_name | Yes | Drug name (brand or generic) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clearly states this is a read operation and lists what data is returned, but lacks details on rate limits or authentication.
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 sentence with bullet-style list of functions, no wasted words, and essential information is front-loaded.
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 low complexity (1 param, no nested objects, no output schema), description is adequate but could mention output format (e.g., JSON) or any limitations.
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% and description says 'Provide a drug name', which adds no extra meaning beyond the schema's description 'Drug name (brand or generic)'. Baseline 3.
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 lists specific actions (adverse event reports, top reaction types, recall history, drug-drug interactions) and requires a drug name, distinguishing it from sibling tools like pharma_drug_profile and pharma_pipeline_scan.
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 implies use for drug safety assessment and lists what it covers, but does not explicitly state when to use this tool vs siblings (e.g., pharma_drug_profile).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recallAInspect
Retrieve a previously stored memory by key, or list all stored memories (omit key). Use this to retrieve context you saved earlier in the session or in previous sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Memory key to retrieve (omit to list all keys) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains the two modes (key vs no key) but does not disclose potential side effects, persistence behavior, or access patterns. Given no annotations, a 3 is appropriate for covering basic behavior.
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?
Description is two sentences, front-loaded with the core action. No wasted words. Could be slightly more concise by merging the second sentence into the first, but still effective.
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?
Tool is simple (1 optional param, no output schema, no nested objects). The description covers the essential usage scenarios. However, it doesn't mention what format the returned memory takes (string, object) or whether listing returns keys only or full memories. For a simple retrieval tool, this is adequate but not fully 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?
Schema description coverage is 100%, so the schema already documents the 'key' parameter. The description adds the meaning that omitting key lists all memories, which is already implied by the schema's required: [] and property description. Baseline 3 is correct.
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?
Clearly states the tool retrieves a memory by key or lists all memories when key is omitted. The verb 'retrieve' and resource 'memory' are specific. It distinguishes itself from siblings like 'remember' (store) and 'forget' (delete).
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?
Provides clear context for when to use: to retrieve context saved earlier. Implicitly contrasts with 'remember' and 'forget' but does not explicitly mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rememberAInspect
Store a key-value pair in your session memory. Use this to save intermediate findings, user preferences, or context across tool calls. Authenticated users get persistent memory; anonymous sessions last 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key (e.g., "subject_property", "target_ticker", "user_preference") | |
| value | Yes | Value to store (any text — findings, addresses, preferences, notes) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions persistence differences between authenticated and anonymous sessions, but does not disclose details like overwrite behavior, storage limits, or whether values are private.
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, each serving a distinct purpose: what the tool does, when to use it, and persistence behavior. No redundancy.
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 (2 parameters, no output schema), the description covers core functionality well. Missing details like overwrite behavior or storage limits are minor gaps for a simple key-value store.
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 detailed descriptions for both parameters (key and value). Description adds value by explaining the purpose (session memory) and providing example keys, but does not add significant semantics 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?
Description explicitly states 'Store a key-value pair in your session memory', uses specific verb ('store') and resource ('key-value pair'), and clearly distinguishes from siblings like 'forget' and 'recall'.
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?
Provides clear usage context: 'save intermediate findings, user preferences, or context across tool calls'. Does not explicitly state when not to use it, but the examples implicitly guide appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!