Biotech rNPV/PoS engine for AI agents. Signed exports, evidence register, asset landscape.
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.
Average 4.3/5 across 13 of 13 tools scored.
Each tool targets a distinct entity or operation: get_* fetches specific objects, query_* searches datasets, list_scenarios enumerates, while triage_asset and verify_export are standalone actions. There is no functional overlap or ambiguity among the 13 tools.
All tools follow a consistent verb_noun pattern in lowercase with underscores. The verbs (get, list, query, triage, verify) clearly indicate the action, and nouns identify the target. This uniform scheme makes the tool purpose predictable.
With 13 tools, the server is well-scoped within the ideal 3–15 range. Each tool addresses a specific aspect of the drug-development analysis domain (project/scenario context, evidence, methodology, benchmarks, risk, landscape, SEC deals, dossier, verification, triage) without redundancy.
The read-side surface is thorough for the domain: projects, scenarios, evidence, methodology, benchmarks, drug risk, landscape, SEC deals, dossier, export verification, and triage are all covered. The only minor gap is the lack of a list_projects tool, but get_project can fetch a known project, providing a workaround.
get_dossierAFetch the structured asset snapshot JSON for a scenario — the same content rendered in the PDF/Excel exports, in machine-readable form. Includes verdict, drivers, assumptions, evidence summary, and (if available) signed-export hashes pointing to the latest signed artifacts.
| Name | Required | Description | Default |
|---|---|---|---|
| scenario_id | Yes | UUID of the scenario to fetch the asset snapshot payload for. |
| Name | Required | Description |
|---|---|---|
| data | Yes | Structured asset snapshot payload mirroring the PDF/Excel exports. Top-level keys include verdict, drivers, assumptions, evidence, and (when available) signed_export hashes. See get_methodology('evidence-standards') for the full structure. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish safety (read-only, idempotent, non-destructive). The description adds behavioral detail beyond annotations by specifying inclusion of signed-export hashes (if available) and the exact components (verdict, drivers, assumptions, evidence summary), which helps agents understand what the response will contain and its relationship to export artifacts.
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, front-loaded with the core action and immediately clarifying the export equivalence. Every sentence adds value with no redundancy or unnecessary filler.
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?
With a single well-documented parameter, rich annotations, and an output schema, the description sufficiently covers what the tool does and returns. The mention of signed-export hashes and content composition provides complete context for an agent's decision-making, without needing to explain return values (output schema exists).
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 the parameter description already fully explains scenario_id. The tool description reinforces it but adds no new format, constraints, or behavioral meaning beyond the schema; hence 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 fetches structured asset snapshot JSON for a scenario, distinguishing it from siblings like get_scenario (likely scenario metadata) and get_evidence (evidence-specific) by specifying it returns the same content as PDF/Excel exports in machine-readable form, including verdicts, drivers, assumptions, and evidence summary.
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: use this when you need the machine-readable snapshot of a scenario, equivalent to the exports. It doesn't explicitly name alternatives or exclusions, but the referenced export relationship and content list give enough guidance for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_evidenceAFetch the evidence register entries for a scenario — the citations, sources, and supporting documents the analyst attached to back the assumptions. Use this when an analysis question references 'what's the evidence for X?'
| Name | Required | Description | Default |
|---|---|---|---|
| scenario_id | Yes | UUID of the scenario whose evidence register entries to fetch. |
| Name | Required | Description |
|---|---|---|
| data | Yes | Array of evidence-register entries. Each entry has fields like assumption_path, source_url, source_date, excerpt, freshness, confidence — see /methodology/evidence-standards for the canonical schema. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe, repeatable read. The description's 'Fetch' wording aligns without contradiction, but it adds no behavioral detail beyond what annotations already cover.
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 zero filler. The first sentence states the action and object, the second gives a practical usage cue. Information is front-loaded and every sentence earns its place.
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 single-parameter read tool with an output schema and strong safety annotations, the description fully covers what is fetched, what content is included, and when to invoke it. Nothing critical is missing.
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 input schema fully describes scenario_id, including UUID format and a description matching the tool's purpose. Since schema description coverage is 100%, the description adds no new parameter-level meaning, 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 opens with a specific verb and resource: 'Fetch the evidence register entries for a scenario.' It further defines what is included ('citations, sources, and supporting documents'), distinguishing it from sibling tools like get_scenario or get_dossier.
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 an explicit usage trigger: 'Use this when an analysis question references "what's the evidence for X?"'. It does not explicitly mention excluded cases or alternatives, but the context for when to call it is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_methodologyAFetch a PhaseFolio methodology section's full content (rNPV engine, backtest, PoS calibration, IRA framework, development paths, clinical stage normalization, evidence standards, network benchmarks, COGS benchmark, SG&A benchmark, tax benchmark, SEC EDGAR deal-term extraction). Designed for citation: each section has a stable URL and a methodology version identifier you can reference in analysis output.
| Name | Required | Description | Default |
|---|---|---|---|
| section | Yes | Which methodology section to fetch. 'rnpv' covers the core risk-adjusted NPV calculation: cumulative PoS, midpoint-discounted risk-adjusted development costs, the S-curve ramp/plateau/LOE revenue lifecycle net of COGS/SG&A/tax, WACC discounting, the rNPV and Unadjusted-NPV equations, Monte Carlo / expected NPV, and one-at-a-time sensitivity; 'backtest' covers the validation methodology and AUC/CI numbers; 'pos-calibration' covers the indication × modality × biomarker matrix, expanded modality normalization into the eight benchmark baselines, the scored multipliers including the engine 2.6.0 biomarker_quality drug-specific multiplier (oncology solid tumor, Phase II/III), the Phase 1 ORR extracted-but-not-scored signal with its Phase 0 governance disclosure, and the non-scored drug-specific risk flags; 'ira-framework' covers the Year-9/Year-13 MFP cliff modeling and the separate IRA classification for expanded modalities such as RNA Therapeutics, Protein Degrader, Radioligand, Oncolytic Virus, and Cancer Vaccine; 'development-paths' covers development-path tiers, automatic-effect policy, and the no path-based PoS/default-multiplier rule; 'stage-normalization' covers exact clinical labels, work packages, canonical PoS gates, and the no label-only PoS modifier rule for Phase 1b/2a/2b, adaptive, pivotal, expansion, platform, bridging, and related labels; 'evidence-standards' covers source tiers and freshness rules; 'network-benchmarks' covers anonymization and cohort cuts; 'cogs-benchmark' covers the per-modality COGS% default bands and price-sensitivity methodology; 'sga-benchmark' covers the per-commercial-model SG&A% default bands (orphan/specialty/primary-care); 'tax-benchmark' covers the US-statutory-21% default tax rate, effective-rate reality, and the NOL cap; 'sec-deal-terms' covers the SEC EDGAR 8-K Item 1.01 deal-term extraction pipeline (cohort, extractor + classifier versions, fields extracted, v0 vs v1 scope). |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds that each section has a stable URL and methodology version identifier, which is useful context beyond the annotations. No contradiction with annotations.
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 followed by a compact list of section names. While the list duplicates some schema enum content, it provides a quick overview that helps the agent scan available sections. The citation sentence earns its place by explaining a key design feature.
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 (one parameter), a rich output schema exists, and annotations cover safety, the description is complete. It explains what the tool returns, the citation use case, and the full scope of sections available.
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 only parameter 'section' has 100% schema description coverage, with an enum and detailed explanation for each value. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 applies.
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 starts with a specific verb and resource ('Fetch a PhaseFolio methodology section's full content'), immediately distinguishing it from sibling tools like get_dossier or get_evidence. It enumerates the exact methodology sections covered, leaving no ambiguity about the tool's scope.
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 states it is 'Designed for citation' and mentions stable URLs and version identifiers, implying the intended use case. It does not explicitly contrast with sibling tools like query_benchmarks, but the clear scoping to methodology sections makes the appropriate context evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_projectAFetch a PhaseFolio project's metadata: indication, sub-indication, modality, biomarker, asset name, and stage at entry. Use this when you need to ground an analysis question in the project's clinical context before fetching scenarios.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | UUID of the PhaseFolio project. Get from the project URL in the dashboard or from a prior list_scenarios call. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide strong safety signals (readOnlyHint, idempotentHint, destructiveHint=false). The description adds the specific metadata fields returned and the intended use case, but does not disclose additional behavioral traits such as authentication, rate limits, or potential side effects. The field list may be redundant given the output schema exists.
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, front-loaded with the action and key fields, followed by a concise usage guideline. No wasted words.
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, read-only metadata fetcher with an output schema and strong annotations, the description fully covers purpose, usage, and field content. It is complete without being verbose.
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%. The project_id parameter is well-described with where to obtain it (project URL or prior list_scenarios call). The tool description adds no additional parameter semantics, 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 verb 'fetch' and the specific resource 'PhaseFolio project's metadata', followed by an explicit list of fields. It distinguishes this tool from siblings like get_scenario by focusing on project metadata and clinical context.
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 explicitly states when to use it: 'when you need to ground an analysis question in the project's clinical context before fetching scenarios.' This implies a sequencing with scenario tools, though it does not name alternative tools or explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_scenarioAFetch a PhaseFolio scenario's complete inputs (stage costs, durations, PoS, commercial assumptions, IRA settings) and computed outputs (eNPV, rNPV, cumulative PoS, per-stage breakdown, top sensitivity drivers). This is the authoritative engine output — every signed export ties back to this payload.
| Name | Required | Description | Default |
|---|---|---|---|
| scenario_id | Yes | UUID of the scenario. Get from list_scenarios or the scenario URL in the dashboard. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds meaningful context: it returns both inputs and outputs, and establishes the payload's authoritative relationship to signed exports. No contradictions; it complements the annotations without repeating them.
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 what the tool returns. Every phrase earns its place—the detailed enumeration of inputs/outputs and the authoritative context are valuable, with no filler.
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 one-parameter read tool with an output schema, the description is complete. It enumerates the returned content (inputs and outputs) and clarifies the usage context ('every signed export ties back to this payload'), so the agent knows exactly what to expect and why this tool matters.
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 with a clear description for scenario_id. The tool description does not add extra parameter semantics beyond the schema, but it implies the need for scenario_id by saying 'Fetch a PhaseFolio scenario.' This meets the baseline for high schema coverage.
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 ('Fetch') and clearly identifies the resource ('a PhaseFolio scenario's complete inputs... and computed outputs'). It distinguishes this tool from siblings by calling it 'the authoritative engine output' and noting that every signed export ties back to it.
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?
It provides clear context for when to use this tool—when you need the full scenario payload or the canonical engine result. It does not explicitly name alternatives or state when not to use it, but the authoritative framing guides selection away from other getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_scenariosAList all scenarios in a PhaseFolio project. Returns scenario IDs, names, created/updated timestamps, and top-line eNPV/rNPV. Use this to discover what scenarios exist before fetching one in detail.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | Yes | Maximum number of scenarios to return (1–200). Defaults to 50; raise for projects with many what-if branches. | |
| project_id | Yes | UUID of the parent project whose scenarios to list. |
| Name | Required | Description |
|---|---|---|
| data | Yes | Scenarios in the project, newest first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose read-only/idempotent/non-destructive behavior. The description adds return field specifics (scenario IDs, names, timestamps, eNPV/rNPV) and workflow context. Minor caveat: 'all' is qualified by the schema's limit parameter, but this is not a contradiction.
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: the first states action and returns, the second gives usage guidance. No redundancy, front-loaded, and every sentence earns its place.
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 list tool with rich annotations and an output schema, the description covers purpose, usage, return content, and distinguishes from siblings. The only minor 'all' vs limit nuance is resolved by the schema's parameter description.
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 both parameters, with informative descriptions for project_id and limit. The description does not add parameter-level semantics, 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 'List all scenarios in a PhaseFolio project' with a specific verb and resource, and enumerates the returned fields. It distinguishes from sibling get_scenario by noting the tool is for discovery 'before fetching one in detail.'
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 explicitly instructs 'Use this to discover what scenarios exist before fetching one in detail,' providing a clear when-to-use directive and implying get_scenario for detailed retrieval. This directly addresses usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_benchmarksAQuery PhaseFolio benchmark availability. Source-backed PoS benchmarks are available separately; network cost distributions and duration percentiles are planned but currently return coming_soon with null estimates rather than PhaseFolio's manual planning defaults.
| Name | Required | Description | Default |
|---|---|---|---|
| metric | Yes | Which benchmark family to request. Cost and duration network benchmarks are currently coming_soon and return no estimate; manual wizard defaults are not returned as benchmarks. | |
| modality | No | Optional modality filter ('Antibody', 'Small Molecule', 'Cell Therapy', 'Gene Therapy', etc.). Omit to return cross-modality stats. | |
| indication | Yes | Indication name (e.g. 'NSCLC', 'Rheumatoid Arthritis', 'Atopic Dermatitis'). Free-form; the engine fuzz-matches to the canonical indication taxonomy. |
| Name | Required | Description |
|---|---|---|
| data | Yes | L1 (no-auth) returns a versioned headline set; L3 (bearer) will return granular slices once enough orgs are on the network. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds the key behavioral trait that unavailable benchmarks return coming_soon with null estimates rather than falling back to manual planning defaults, which is valuable beyond annotation.
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 sentence states the purpose, and the second provides an important caveat about availability. Information is front-loaded 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 presence of a fully descriptive input schema and output schema, plus annotations, the description is sufficient. It explains the key availability caveat that separates this tool from siblings and sets expectations for null returns.
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 input schema provides 100% description coverage with per-parameter explanations, including the coming_soon semantics for cost/duration. The description mostly reiterates this schedule/behavior, adding no new parameter-level detail, 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 queries PhaseFolio benchmark availability, which is a specific resource. It differentiates from siblings by noting source-backed PoS benchmarks are available separately, and clarifies that network cost/duration benchmarks are coming_soon, distinguishing it from other query tools.
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 explicitly indicates that source-backed PoS benchmarks are handled separately, implying a different tool should be used for those. It also warns that cost and duration benchmarks return coming_soon with null estimates, so users should not expect those values. This is clear context but does not name the alternative tool explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_drug_riskAFetch human-reviewed drug-specific clinical-risk signals for a project, including biomarker quality, Phase 1 ORR flag-only data, provenance, extractor versions, and pending-review counts. Use this before interpreting engine 2.6.0 drug-specific multipliers or flags.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | UUID of the project whose reviewed drug-specific clinical-risk signals should be queried. |
| Name | Required | Description |
|---|---|---|
| data | Yes | Drug-specific clinical-risk substrate for a project. Returns reviewed signals only; pending rows are counted but excluded from scoring. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds useful context beyond this: it characterizes the data as human-reviewed, includes 'Phase 1 ORR flag-only data', provenance, extractor versions, and pending-review counts, and clarifies the relationship to engine 2.6.0. No contradiction with annotations.
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 the primary purpose and data contents, followed by a concise usage directive. Every sentence adds value; no filler or 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?
The tool has a single parameter and an output schema, so much of the return structure is externally documented. The description covers the tool's role, data composition, and nuance about 'Phase 1 ORR flag-only data'. It lacks explicit details on pagination or authorization, but these are not critical given the schema and read-only annotations.
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%, with a clear description for project_id. The tool description adds no additional parameter-level semantics beyond what the schema already 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 opens with a specific verb ('Fetch') and clearly identifies the resource ('human-reviewed drug-specific clinical-risk signals for a project'), then enumerates the included data elements. This unambiguously distinguishes it from sibling tools like query_benchmarks or get_evidence.
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 explicitly states when to use the tool: 'Use this before interpreting engine 2.6.0 drug-specific multipliers or flags.' This provides clear context, though it doesn't enumerate alternatives or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_evidence_atlasAFetch the published Evidence Atlas program universe for a sub-indication. Defaults to source-verified rows from public CT.gov + FDA; agent-labeled rows require include_unverified=true and remain explicitly labeled. Pending AI-serviced event_links are human_verified=false and review_status=pending_human_review until reviewed. Trial summaries and financial_links are source-derived facts; interpreted efficacy, PoS, and verdicts are not returned.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | Yes | Maximum number of programs to return, 1-328. Defaults to 100. | |
| sub_indication | Yes | Evidence Atlas sub-indication slug, e.g. 'ipf'. | |
| include_unverified | Yes | When true, include agent-labeled-not-verified rows in addition to source_verified rows. Rejected rows are never returned. |
| Name | Required | Description |
|---|---|---|
| data | Yes | Evidence Atlas payload for one published sub-indication. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld/idempotent annotations, the description discloses valuable behavioral nuances: agent-labeled rows require include_unverified=true and remain labeled, pending event_links carry human_verified=false and review_status=pending_human_review, and interpreted fields like efficacy or PoS are never returned. This goes well beyond the structured annotation hints.
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 and then elaborates on filtering and data provenance. It is appropriately sized for the tool's complexity, though the later sentences introduce specialized terms like 'AI-serviced event_links' that add density but still earn their place.
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 output schema exists and annotations declare the tool read-only and idempotent, the description fills the remaining gaps: source-verified defaults, agent-labeled handling, pending review statuses, and explicit exclusions of interpreted results. The description is fully adequate for correct invocation.
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 all three parameters are already documented. The description adds context beyond the schema by explaining the behavioral implications of include_unverified and confirming that rejected rows are never returned, which enriches parameter understanding without contradicting schema details.
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 opens with a specific verb and resource: 'Fetch the published Evidence Atlas program universe for a sub-indication.' This clearly distinguishes the tool from siblings like get_dossier or query_benchmarks by its focus on program universes keyed by sub-indication.
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 the tool is appropriate: fetching published program universe data, with defaults to source-verified rows and explicit handling for agent-labeled rows. It does not name sibling alternatives or state when not to use it, but the usage context is sufficiently implied by the scope and filtering behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_landscapeAFetch the asset-anchored competitive landscape for a project — comparable trials, competing programs, sponsor activity, and biomarker overlap. Sourced from CT.gov + FDA + PhaseFolio's curated enrichment. Use when an analysis question asks 'who else is working on this?' or 'what's the competitive context?'
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | UUID of the project to anchor the landscape on. Indication × modality × biomarker filters derive from the project. | |
| phase_filter | Yes | Optional list of clinical phases to include (e.g. ['PHASE2','PHASE3']). Empty array means all phases. | |
| recency_years | Yes | How many years back to look (1–50). Defaults to 10 — broad enough to catch development-stage peers without polluting with stale failures. |
| Name | Required | Description |
|---|---|---|
| data | Yes | Asset-anchored landscape payload: kpis (sponsor counts, trial counts, etc.), comparable_trials[] (NCT-keyed), competing_programs[], biomarker_overlap. Filtered by the project's indication × modality × biomarker. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds value by disclosing data sources (CT.gov, FDA, PhaseFolio) and the nature of the output (curated enrichment, asset-anchored), which goes beyond the annotations. No contradiction.
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 defines scope and content, second gives usage guidance. No redundant or filler language; every word earns its place.
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 presence of output schema, full parameter descriptions, and rich annotations, the description covers purpose, usage, sources, and content. There are no material gaps for an agent to select and invoke the tool 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?
Schema coverage is 100%, so baseline is 3. The description does not add parameter-specific syntax or constraints; it only alludes to project-derived filters, which the schema already states. No additional value beyond 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 uses a specific verb ('Fetch') and resource ('asset-anchored competitive landscape'), enumerating concrete components (comparable trials, competing programs, sponsor activity, biomarker overlap). This clearly distinguishes it from siblings like get_dossier or get_evidence.
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 when to use it via example questions ('who else is working on this?' / 'what's the competitive context?'). It does not name alternatives or explicitly state when not to use, but the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_sec_deal_termsAQuery SEC EDGAR deal-term extractions by indication, deal type, date range, confidence, and review state. Returns per-deal rows with source quotes and accession URLs for verification; aggregate engine medians use the separate backend aggregate function.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | Yes | Maximum rows to return, 1-500. Defaults to 100. | |
| since | No | Optional inclusive effective_date lower bound in YYYY-MM-DD format. | |
| until | No | Optional inclusive effective_date upper bound in YYYY-MM-DD format. | |
| deal_type | No | Optional deal type filter. | |
| indication | No | Optional indication filter, e.g. 'antimicrobial'. | |
| min_confidence | Yes | Minimum extraction confidence threshold. Defaults to 0.5. | |
| include_needs_review | Yes | Whether to include rows flagged needs_review. Defaults to true so admin users can see flags. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds that it returns per-deal rows with source quotes and accession URLs for verification, and that aggregate medians are not included here. This provides behavioral context about the output content and scope beyond what annotations state.
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 filler. The first sentence states the action and filter dimensions; the second adds return-value detail and a crucial exclusion about aggregate medians. Both sentences carry necessary information.
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?
The description covers purpose, filters, return format, and an important scope limitation, making it well-rounded for a query tool. It doesn't detail output schema structure, but an output schema exists to handle that. The completeness is high given annotations and output schema.
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 every parameter has an individual description in the schema. The description repeats filter categories but adds no additional parameter-level detail beyond what the schema already provides. Baseline 3 is appropriate when schema covers all parameters.
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 identifies the tool's purpose as querying SEC EDGAR deal-term extractions with specific filters (indication, deal type, date range, confidence, review state). The verb 'Query' and resource 'SEC EDGAR deal-term extractions' are specific, distinguishing it from sibling tools like query_benchmarks or query_drug_risk.
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 by listing filter dimensions and noting that aggregate medians are handled by a separate backend aggregate function. This provides a partial when-not (for aggregates) but does not explicitly name sibling tools or provide when-to-use comparisons. No clear exclusions beyond the aggregate note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
triage_assetAProduce a transparent, provenance-linked CONDITIONAL READ on a drug asset for deal triage. Pass either text (a teaser/abstract — fields are machine-extracted and the result is marked inputs_unconfirmed) or pre-confirmed fields. Returns a reasoning chain (each claim grounded or marked insufficient_evidence), mechanism-plausibility flags, PoS + landscape metrics, and a meta block with engine/methodology/synthesis versions. Does NOT compute rNPV. Not an autonomous verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Unstructured asset text; triggers extraction (inputs_unconfirmed=true). | |
| fields | No | Pre-confirmed structured fields. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld/idempotent annotations, the description reveals meaningful behavior: text input triggers extraction and marks inputs_unconfirmed, each claim is grounded or marked insufficient_evidence, and a meta block includes versioning. It explicitly denies computing rNPV and being an autonomous verdict, adding substantial behavioral transparency.
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 only three sentences but packs in purpose, input modes, output components, and exclusions. It is front-loaded with the core purpose and every sentence adds necessary information with 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?
With a nested fields object and a rich output schema (present though not shown), the description still covers input constraints, output composition, and limitations. It fully prepares the agent for correct invocation without needing to infer missing details.
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 parameter names are documented, but the description adds key semantics: text triggers extraction and marks inputs_unconfirmed, while fields are 'pre-confirmed' (implying trusted input). This clarifies the practical difference between the two params beyond the schema's type descriptions.
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 produces a 'transparent, provenance-linked CONDITIONAL READ on a drug asset for deal triage,' specifying the verb, resource, and context. It also lists concrete outputs (reasoning chain, flags, metrics, meta) and exclusions (does NOT compute rNPV), making it distinct from sibling tools like get_dossier and query_landscape.
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 explicit input-mode guidance: 'Pass either text (machine-extracted, inputs_unconfirmed) or pre-confirmed fields.' It also sets context ('for deal triage') and notes what it does not do, which indirectly helps a user pick a different tool if needed, though it does not name specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_exportAVerify a signed PhaseFolio export by content hash. Returns verification status (valid/tampered/unknown), issued timestamp, methodology version, and an anonymized originating-org identifier. Use this when a user shares a PhaseFolio asset snapshot and you want to confirm it's authentic before citing the analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | 64-character hex SHA-256 of the signed artifact's content. Embedded in every signed PhaseFolio PDF (footer) and Excel (cover tab). |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context by spelling out the return values (verification status, issued timestamp, methodology version, anonymized originating-org identifier) and the intended use case (authenticity confirmation). This goes beyond the annotations without contradicting them.
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-loaded with the core action, and includes all necessary information without redundancy. The first sentence states the operation and return values; the second gives the use case. Every sentence earns its place, with no wasted words.
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 verification tool with one parameter, an output schema, and comprehensive annotations, the description covers all necessary aspects: what it does, what it returns, and when to use it. It is fully self-contained and leaves no significant gaps for an agent to infer.
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 input schema has 100% description coverage: the hash parameter is fully described with its format, purpose, and where to find it in export files. Since the schema already provides complete parameter semantics, the description does not need to add more. The tool description also references 'content hash,' aligning with the schema. Baseline 3 is appropriate per the rubric.
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: 'Verify a signed PhaseFolio export by content hash.' It specifies the resource (signed PhaseFolio export) and the method (content hash), and distinguishes it from all sibling tools (none of which are about verification). It also lists the returned fields, making the purpose unmistakable.
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 explicit usage context: 'Use this when a user shares a PhaseFolio asset snapshot and you want to confirm it's authentic before citing the analysis.' This gives a clear 'when to use' scenario. It does not explicitly mention when not to use or name alternative tools, but the guidance is concrete and sufficient for an agent to select the tool appropriately.
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.
No comments yet. Be the first to start the discussion!