Biotech rNPV/PoS engine for AI agents. Signed exports, evidence register, asset landscape.
Scored across 10 tools
Most tools target clearly distinct resources (project, scenario, evidence, methodology, benchmarks, drug risk), but get_dossier and get_scenario both return scenario-level structured data with computed outputs, risking misselection. Descriptions distinguish the export-snapshot focus of get_dossier from the authoritative model payload of get_scenario, keeping the overlap manageable.
All tool names use snake_case with a predictable verb_noun pattern (get_, list_, query_, triage_, verify_). The consistent convention makes the set easy to scan and remember.
10 tools is well within the typical 3-15 range for a read-only analytical server. Each tool maps to a distinct capability (retrieval, triage, verification) without obvious bloat.
Coverage is strong for retrieval and verification, but the absence of a list_projects operation means agents cannot discover project IDs, creating a potential dead end. No create/update operations exist, though this may be intentional for a read-only server.
Fetch 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.
Fetch 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.
Fetch a PhaseFolio methodology section's full content (rNPV model, backtest, PoS calibration, IRA framework, development paths, deal-term modelling, holding valuation, 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 model 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; 'deal-term-modelling' covers how licensing deal terms map onto a scenario's deal structure (term-model mapping v1): what is modelled, not modelled and refused, the territory restriction and the approximations it names, milestone timing at stage ends, the cost-share rule, and the non-USD conversion-rate refusal; 'holding-valuation' covers how a Workspace holding is valued (scenario, share of asset value, look-through estimate, cost, not valued): each method's inputs, reason codes and completeness, the totals rules (never added across bases or currencies, estimates left out by default) and what the look-through estimate ignores; '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' is the retirement notice for the SEC EDGAR deal-term source (retired 2026-09-27), with its frozen versions. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds genuinely new behavioral context: that each section carries a stable URL and a methodology version identifier suitable for citation. It stops short of describing response format or size, but with a rich annotation set that is a minor omission.
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?
Purpose is front-loaded in the opening clause, which is good. But the 14-item parenthetical enumeration of sections is redundant with an enum that already defines each value at length, bloating a single sentence without adding routing value. The second sentence (citation, stable URL, version id) is the most valuable part and could carry more weight.
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-only documentation fetch with an output schema present and full annotation coverage, the description supplies enough for correct invocation: what is retrieved, the citation/version behavior, and the domain of each section. Nothing critical is missing, though the redundancy in the section list inflates length without improving 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% and the single 'section' enum is documented in exhaustive detail inside the schema itself (each value with a paragraph of scope). The description's parenthetical list of sections largely restates the enum values, adding little beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.
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?
States a specific verb ('Fetch') and resource ('a PhaseFolio methodology section's full content'), and the parenthetical enumerates the exact domains covered (rNPV, backtest, PoS calibration, IRA framework, etc.). This is clearly distinguishable from siblings like get_dossier, get_evidence, or query_benchmarks, which fetch asset/evidence/benchmark data rather than methodology documentation.
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 phrase 'Designed for citation' implies the intended use case (retrieving methodology text to reference in analysis output), which is useful contextual framing. However, it never states when to prefer this over siblings such as get_evidence or verify_export, nor any exclusions or prerequisites, leaving the selection logic largely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch 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.
Fetch 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 model 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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds valuable trust context: it is the authoritative model output and every signed export ties back to this payload, though it does not state rate limits or auth needs.
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 tight sentences, purpose-first with the payload scope up front and the authority/trust note second. No filler or repetition; every clause carries useful 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?
For a single-parameter read tool with an output schema and rich safety annotations, the description is complete. It adds model-output authority and enumerates payload scope without needing to explain return values, which the output schema already covers.
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 single scenario_id parameter is fully documented with UUID format and source. The description adds no parameter syntax, constraints, or meaning beyond what the schema already provides, so baseline 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?
Specific verb 'Fetch' plus resource 'PhaseFolio scenario' and enumerates both inputs (stage costs, durations, PoS, commercial assumptions, IRA settings) and computed outputs (eNPV, rNPV, cumulative PoS, per-stage breakdown, sensitivity drivers). The scope distinguishes it from list_scenarios and other get_* siblings even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use, when-not-to-use, prerequisites, or named alternatives within the description. The schema's note that scenario_id comes from list_scenarios is structured-field guidance, not tool-description routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List 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 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 model 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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description's added value is the disclosure that cost/duration benchmarks return coming_soon with null estimates instead of the manual wizard defaults. That is exactly the kind of behavioral caveat an agent needs to avoid misinterpreting placeholder output. It does not mention rate limits or auth, but those are minor here.
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 tool's purpose and followed by the availability caveat. Information density is high and there is little waste, though the second sentence is long and slightly convoluted with the 'rather than PhaseFolio's manual planning defaults' clause.
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?
An output schema exists, so return-value shape need not be explained, and the description covers the critical edge case (coming_soon/null). Given the modest three-parameter surface and the schema's own documentation, the description is close to complete; only minor gaps remain around what the PoS source actually contains.
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 enum values, the optional modality filter, and the indication fuzz-matching are already documented in the schema. The description adds no parameter-level detail beyond that, so the baseline 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?
States a clear verb (Query) and resource (PhaseFolio benchmark availability), and effectively signals that this tool answers 'what benchmarks exist' rather than returning rich data. It also distinguishes itself from the separate source-backed PoS benchmark path. It is slightly muddled by framing around availability rather than the returned data, so not a clean 5.
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?
Tells the agent the key condition: cost and duration families currently return coming_soon with null estimates, so they should not be relied on, while PoS is source-backed. This is real when-to-use/when-not-to-use guidance. It does not explicitly name a sibling alternative for cost/duration data, so it stops 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.
Fetch 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 model 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's added value is that the data is human-reviewed, carries provenance and extractor versions, and may be incomplete via 'pending-review counts' - useful reliability context beyond the annotations. It stops short of noting auth needs, freshness/latency, or pagination.
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 core action and followed by the usage trigger. The middle payload list is dense with domain jargon, but each clause carries identifying information rather than 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 1-parameter schema and an output schema present, the description need only convey purpose and usage, both of which it does. Minor gap: it doesn't indicate whether the returned signals can be empty or how pending-review counts should be interpreted, though that is largely a return-value concern covered by the 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?
Only one parameter, and the schema description coverage is 100%, so the schema already documents project_id fully (UUID of the project to query). The description adds nothing beyond what the schema provides, which is the baseline 3 for well-covered single-parameter schemas.
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?
States a specific verb+resource ('Fetch human-reviewed drug-specific clinical-risk signals for a project') and enumerates the payload's distinguishing contents (biomarker quality, Phase 1 ORR flag-only data, provenance, extractor versions, pending-review counts). An agent can tell this apart from siblings like get_evidence or get_methodology without opening either schema.
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 states when to use it: 'before interpreting model 2.6.0 drug-specific multipliers or flags.' That is a clear contextual trigger, but no when-not condition and no named alternative sibling are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Produce 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 metrics, and a meta block with model/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?
Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lowered. The description still adds real behavioral context: the inputs_unconfirmed flag on extraction, claims grounded or marked insufficient_evidence, mechanism-plausibility flags, and version metadata. It omits any mention of latency, cost, or failure modes for an open-world call.
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, front-loaded with the core verb and output shape, then input modes, then non-goals. No filler and every clause carries instruction or boundary 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?
With an output schema present, return values need no elaboration, yet the description still summarizes the reasoning chain and meta block. Inputs, output character, and explicit non-goals (rNPV, autonomous verdict) are all covered for a two-mode tool.
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 would be 3, but the description adds the either/or contract between `text` and `fields` (the schema does not enforce mutual exclusivity) and explains the downstream consequence of each path.
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?
States a specific verb+resource ('produce a CONDITIONAL READ on a drug asset') plus the domain purpose ('for deal triage'). It distinguishes itself from siblings like query_drug_risk and get_dossier by naming the reasoning-chain and provenance character of the output.
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 pass `text` (teaser/abstract, mark inputs_unconfirmed) versus pre-confirmed `fields`. It also states negative scope: 'Does NOT compute rNPV. Not an autonomous verdict,' which prevents misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify 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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds the three verification outcome states (valid/tampered/unknown), which is some extra semantic context, but since an output schema exists this is largely redundant and it says nothing about auth, rate limits, or failure 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?
Two tight sentences: the mechanism and return payload come first, the usage condition second. Every clause carries information and nothing is padded.
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?
An output schema exists, so the return-value sentence is not strictly required, but the description still conveys purpose, trigger condition, and outcome semantics for a simple one-parameter tool. Adequate coverage; nothing essential for correct invocation 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?
Schema description coverage is 100% and the single 'hash' parameter is fully documented (64-char SHA-256, where it is embedded). The description only restates 'by content hash' and adds no format or sourcing detail beyond the schema, so the baseline 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?
States a specific verb (verify) and resource (a signed PhaseFolio export) plus the mechanism (by content hash). No sibling tool does anything similar, so the agent can distinguish it immediately from get_evidence 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?
Gives a concrete triggering situation: 'when a user shares a PhaseFolio asset snapshot and you want to confirm it's authentic before citing the analysis.' This is a clear use context, though it names no alternatives or exclusions (e.g., what to do when no hash is available).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_methodology3 fields changedInput schema / properties / section / descriptionPrevious value: -"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 model 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; 'deal-term-modelling' covers how licensing deal terms map onto a scenario's deal structure (term-model mapping v1): what is modelled, not modelled and refused, the territory restriction and the approximations it names, milestone timing at stage ends, the cost-share rule, and the non-USD conversion-rate refusal; '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' is the retirement notice for the SEC EDGAR deal-term source (retired 2026-09-27), with its frozen versions."New value: +"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 model 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; 'deal-term-modelling' covers how licensing deal terms map onto a scenario's deal structure (term-model mapping v1): what is modelled, not modelled and refused, the territory restriction and the approximations it names, milestone timing at stage ends, the cost-share rule, and the non-USD conversion-rate refusal; 'holding-valuation' covers how a Workspace holding is valued (scenario, share of asset value, look-through estimate, cost, not valued): each method's inputs, reason codes and completeness, the totals rules (never added across bases or currencies, estimates left out by default) and what the look-through estimate ignores; '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' is the retirement notice for the SEC EDGAR deal-term source (retired 2026-09-27), with its frozen versions."Input schema / properties / section / enumPrevious value: -[
- "rnpv",
- "backtest",
- "pos-calibration",
- "ira-framework",
- "development-paths",
- "deal-term-modelling",
- "stage-normalization",
- "evidence-standards",
- "network-benchmarks",
- "cogs-benchmark",
- "sga-benchmark",
- "tax-benchmark",
- "sec-deal-terms"
-]New value: +[
+ "rnpv",
+ "backtest",
+ "pos-calibration",
+ "ira-framework",
+ "development-paths",
+ "deal-term-modelling",
+ "holding-valuation",
+ "stage-normalization",
+ "evidence-standards",
+ "network-benchmarks",
+ "cogs-benchmark",
+ "sga-benchmark",
+ "tax-benchmark",
+ "sec-deal-terms"
+]Output schema / properties / data / properties / section_id / enumPrevious value: -[
- "rnpv",
- "backtest",
- "pos-calibration",
- "ira-framework",
- "development-paths",
- "deal-term-modelling",
- "evidence-standards",
- "network-benchmarks",
- "cogs-benchmark",
- "sga-benchmark",
- "tax-benchmark",
- "sec-deal-terms"
-]New value: +[
+ "rnpv",
+ "backtest",
+ "pos-calibration",
+ "ira-framework",
+ "development-paths",
+ "deal-term-modelling",
+ "holding-valuation",
+ "evidence-standards",
+ "network-benchmarks",
+ "cogs-benchmark",
+ "sga-benchmark",
+ "tax-benchmark",
+ "sec-deal-terms"
+]get_methodology1 field changedInput schema / properties / section / descriptionPrevious value: -"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; 'deal-term-modelling' covers how licensing deal terms map onto a scenario's deal structure (term-model mapping v1): what is modelled, not modelled and refused, the territory restriction and the approximations it names, milestone timing at stage ends, the cost-share rule, and the non-USD conversion-rate refusal; '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' is the retirement notice for the SEC EDGAR deal-term source (retired 2026-09-27), with its frozen versions."New value: +"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 model 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; 'deal-term-modelling' covers how licensing deal terms map onto a scenario's deal structure (term-model mapping v1): what is modelled, not modelled and refused, the territory restriction and the approximations it names, milestone timing at stage ends, the cost-share rule, and the non-USD conversion-rate refusal; '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' is the retirement notice for the SEC EDGAR deal-term source (retired 2026-09-27), with its frozen versions."get_scenario3 fields changedOutput schema / properties / data / properties / model_versionAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Model version that produced `result` (the result's own engine_version key). Null when the scenario has not been computed."
+}Output schema / properties / data / properties / result / descriptionPrevious value: -"Full engine output blob: eNPV (USD M), rNPV (USD M), cumulative_pos, per_stage_breakdown[], top sensitivity drivers, optional Monte Carlo percentiles."New value: +"Full model output blob: eNPV (USD M), rNPV (USD M), cumulative_pos, per_stage_breakdown[], top sensitivity drivers, optional Monte Carlo percentiles."Output schema / properties / data / requiredPrevious value: -[
- "id",
- "label",
- "project_id",
- "is_base",
- "created_at",
- "updated_at",
- "inputs",
- "result",
- "modality",
- "mfp_discount"
-]New value: +[
+ "id",
+ "label",
+ "project_id",
+ "is_base",
+ "created_at",
+ "updated_at",
+ "inputs",
+ "result",
+ "model_version",
+ "modality",
+ "mfp_discount"
+]query_benchmarks1 field changedInput schema / properties / indication / descriptionPrevious value: -"Indication name (e.g. 'NSCLC', 'Rheumatoid Arthritis', 'Atopic Dermatitis'). Free-form; the engine fuzz-matches to the canonical indication taxonomy."New value: +"Indication name (e.g. 'NSCLC', 'Rheumatoid Arthritis', 'Atopic Dermatitis'). Free-form; the model fuzz-matches to the canonical indication taxonomy."query_drug_risk1 field changedOutput schema / properties / data / properties / phase1_orr_treatment / descriptionPrevious value: -"Phase 1 ORR is surfaced but not scored in engine 2.6.0."New value: +"Phase 1 ORR is surfaced but not scored in model 2.6.0."verify_export1 field changedOutput schema / properties / data / oneOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "benchmark_dataset_versions": {
- "description": "Array of benchmark dataset versions used; '[]' for legacy rows."
- },
- "content_hash": {
- "type": "string"
- },
- "engine_version": {
- "description": "Engine version stamp at signing time. Sentinel 'unknown (pre-2026-05)' for legacy rows.",
- "type": "string"
- },
- "evidence_count": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "format": {
- "description": "Export format: 'pdf' or 'xlsx'.",
- "type": "string"
- },
- "indication": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "methodology_version": {
- "description": "Methodology version stamp at signing time, e.g. 'methodology@2026-04'.",
- "type": "string"
- },
- "modality": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "org": {
- "description": "Anonymized originating-org identifier, or display name if the org opted into public attribution.",
- "type": "string"
- },
- "signals_used": {
- "description": "Reviewed drug-specific signal provenance included in the signed content hash; [] for none or legacy rows."
- },
- "signed_at": {
- "description": "ISO 8601 timestamp the artifact was signed by the engine.",
- "type": "string"
- },
- "status": {
- "const": "valid",
- "type": "string"
- }
- },
- "required": [
- "status",
- "content_hash",
- "signed_at",
- "methodology_version",
- "engine_version",
- "benchmark_dataset_versions",
- "signals_used",
- "format",
- "org",
- "indication",
- "modality",
- "evidence_count"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "message": {
- "type": "string"
- },
- "status": {
- "const": "unknown",
- "type": "string"
- }
- },
- "required": [
- "status",
- "message"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "benchmark_dataset_versions": {
+ "description": "Array of benchmark dataset versions used; '[]' for legacy rows."
+ },
+ "content_hash": {
+ "type": "string"
+ },
+ "engine_version": {
+ "description": "Deprecated alias of model_version, kept for existing clients.",
+ "type": "string"
+ },
+ "evidence_count": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "format": {
+ "description": "Export format: 'pdf' or 'xlsx'.",
+ "type": "string"
+ },
+ "indication": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "methodology_version": {
+ "description": "Methodology version stamp at signing time, e.g. 'methodology@2026-04'.",
+ "type": "string"
+ },
+ "modality": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "model_version": {
+ "description": "Model version stamp at signing time. Sentinel 'unknown (pre-2026-05)' for legacy rows.",
+ "type": "string"
+ },
+ "org": {
+ "description": "Anonymized originating-org identifier, or display name if the org opted into public attribution.",
+ "type": "string"
+ },
+ "signals_used": {
+ "description": "Reviewed drug-specific signal provenance included in the signed content hash; [] for none or legacy rows."
+ },
+ "signed_at": {
+ "description": "ISO 8601 timestamp the artifact was signed at.",
+ "type": "string"
+ },
+ "status": {
+ "const": "valid",
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "content_hash",
+ "signed_at",
+ "methodology_version",
+ "model_version",
+ "engine_version",
+ "benchmark_dataset_versions",
+ "signals_used",
+ "format",
+ "org",
+ "indication",
+ "modality",
+ "evidence_count"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "status": {
+ "const": "unknown",
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "message"
+ ],
+ "type": "object"
+ }
+]get_methodology3 fields changedInput schema / properties / section / descriptionPrevious value: -"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' is the retirement notice for the SEC EDGAR deal-term source (retired 2026-09-27), with its frozen versions."New value: +"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; 'deal-term-modelling' covers how licensing deal terms map onto a scenario's deal structure (term-model mapping v1): what is modelled, not modelled and refused, the territory restriction and the approximations it names, milestone timing at stage ends, the cost-share rule, and the non-USD conversion-rate refusal; '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' is the retirement notice for the SEC EDGAR deal-term source (retired 2026-09-27), with its frozen versions."Input schema / properties / section / enumPrevious value: -[
- "rnpv",
- "backtest",
- "pos-calibration",
- "ira-framework",
- "development-paths",
- "stage-normalization",
- "evidence-standards",
- "network-benchmarks",
- "cogs-benchmark",
- "sga-benchmark",
- "tax-benchmark",
- "sec-deal-terms"
-]New value: +[
+ "rnpv",
+ "backtest",
+ "pos-calibration",
+ "ira-framework",
+ "development-paths",
+ "deal-term-modelling",
+ "stage-normalization",
+ "evidence-standards",
+ "network-benchmarks",
+ "cogs-benchmark",
+ "sga-benchmark",
+ "tax-benchmark",
+ "sec-deal-terms"
+]Output schema / properties / data / properties / section_id / enumPrevious value: -[
- "rnpv",
- "backtest",
- "pos-calibration",
- "ira-framework",
- "development-paths",
- "evidence-standards",
- "network-benchmarks",
- "cogs-benchmark",
- "sga-benchmark",
- "tax-benchmark",
- "sec-deal-terms"
-]New value: +[
+ "rnpv",
+ "backtest",
+ "pos-calibration",
+ "ira-framework",
+ "development-paths",
+ "deal-term-modelling",
+ "evidence-standards",
+ "network-benchmarks",
+ "cogs-benchmark",
+ "sga-benchmark",
+ "tax-benchmark",
+ "sec-deal-terms"
+]get_methodology1 field changedInput schema / properties / section / descriptionPrevious value: -"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)."New value: +"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' is the retirement notice for the SEC EDGAR deal-term source (retired 2026-09-27), with its frozen versions."query_evidence_atlasquery_landscapequery_sec_deal_termsget_dossier2 fields changedInput schema / properties / scenario_id / descriptionPrevious value: -"UUID of the scenario to fetch the IC dossier payload for."New value: +"UUID of the scenario to fetch the asset snapshot payload for."Output schema / properties / data / descriptionPrevious value: -"Structured dossier payload mirroring the IC Dossier 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."New value: +"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."query_benchmarks5 fields changedInput schema / properties / metric / descriptionPrevious value: -"Which benchmark family to return: 'pos' (probability of success), 'cost' (per-stage cost distributions), 'duration' (per-stage duration percentiles), or 'all'."New value: +"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."Output schema / properties / data / properties / available_metricsAdded value: +{
+ "description": "Network benchmark metric families with published numeric estimates.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / data / properties / noteAdded value: +{
+ "description": "Plain-language benchmark-availability and provenance note.",
+ "type": "string"
+}Output schema / properties / data / properties / planning_defaults_excludedAdded value: +{
+ "description": "True when manual PhaseFolio planning defaults are intentionally excluded.",
+ "type": "boolean"
+}Output schema / properties / data / requiredPrevious value: -[
- "version",
- "methodology_url"
-]New value: +[
+ "version",
+ "available_metrics",
+ "planning_defaults_excluded",
+ "note",
+ "methodology_url"
+]query_evidence_atlas1 field changedOutput schema / properties / data / properties / programs / descriptionPrevious value: -"Program universe rows with CT.gov/FDA source links, registry-derived trial summary fields, and source-linked financial_links facts. Interpreted efficacy, PoS, and verdict fields are absent."New value: +"Program universe rows with CT.gov/FDA source links, registry-derived trial summary fields, source-linked financial_links facts, and explicit event_links when requested. Pending AI-serviced event rows remain agent_labeled, human_verified=false, review_status=pending_human_review, and require include_unverified=true."query_evidence_atlas1 field changedOutput schema / properties / data / properties / programs / descriptionPrevious value: -"Program universe rows with CT.gov/FDA source links and registry-derived trial summary fields. Interpreted efficacy, PoS, and verdict fields are absent."New value: +"Program universe rows with CT.gov/FDA source links, registry-derived trial summary fields, and source-linked financial_links facts. Interpreted efficacy, PoS, and verdict fields are absent."query_evidence_atlasget_methodology1 field changedInput schema / properties / section / descriptionPrevious value: -"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, the eight 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; '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)."New value: +"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)."verify_export2 fields changedInput schema / properties / artifact_urlRemoved value: -{
- "description": "Public URL of the signed artifact. The engine fetches it, computes the hash, and verifies — slower but works when only the URL is known.",
- "format": "uri",
- "type": "string"
-}Input schema / requiredAdded value: +[
+ "hash"
+]get_methodology2 fields changedInput schema / properties / section / descriptionPrevious value: -"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, the eight 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; 'development-paths' covers development-path tiers, automatic-effect policy, and the no path-based PoS/default-multiplier rule; '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)."New value: +"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, the eight 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; '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)."Input schema / properties / section / enumPrevious value: -[
- "rnpv",
- "backtest",
- "pos-calibration",
- "ira-framework",
- "development-paths",
- "evidence-standards",
- "network-benchmarks",
- "cogs-benchmark",
- "sga-benchmark",
- "tax-benchmark",
- "sec-deal-terms"
-]New value: +[
+ "rnpv",
+ "backtest",
+ "pos-calibration",
+ "ira-framework",
+ "development-paths",
+ "stage-normalization",
+ "evidence-standards",
+ "network-benchmarks",
+ "cogs-benchmark",
+ "sga-benchmark",
+ "tax-benchmark",
+ "sec-deal-terms"
+]get_methodology3 fields changedInput schema / properties / section / descriptionPrevious value: -"Which methodology section to fetch. 'backtest' covers the validation methodology and AUC/CI numbers; 'pos-calibration' covers the indication × modality × biomarker matrix, the eight 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; 'development-paths' covers development-path tiers, automatic-effect policy, and the no path-based PoS/default-multiplier rule; '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)."New value: +"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, the eight 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; 'development-paths' covers development-path tiers, automatic-effect policy, and the no path-based PoS/default-multiplier rule; '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)."Input schema / properties / section / enumPrevious value: -[
- "backtest",
- "pos-calibration",
- "ira-framework",
- "development-paths",
- "evidence-standards",
- "network-benchmarks",
- "cogs-benchmark",
- "sga-benchmark",
- "tax-benchmark",
- "sec-deal-terms"
-]New value: +[
+ "rnpv",
+ "backtest",
+ "pos-calibration",
+ "ira-framework",
+ "development-paths",
+ "evidence-standards",
+ "network-benchmarks",
+ "cogs-benchmark",
+ "sga-benchmark",
+ "tax-benchmark",
+ "sec-deal-terms"
+]Output schema / properties / data / properties / section_id / enumPrevious value: -[
- "backtest",
- "pos-calibration",
- "ira-framework",
- "development-paths",
- "evidence-standards",
- "network-benchmarks",
- "cogs-benchmark",
- "sga-benchmark",
- "tax-benchmark",
- "sec-deal-terms"
-]New value: +[
+ "rnpv",
+ "backtest",
+ "pos-calibration",
+ "ira-framework",
+ "development-paths",
+ "evidence-standards",
+ "network-benchmarks",
+ "cogs-benchmark",
+ "sga-benchmark",
+ "tax-benchmark",
+ "sec-deal-terms"
+]get_methodology3 fields changedInput schema / properties / section / descriptionPrevious value: -"Which methodology section to fetch. 'backtest' covers the validation methodology and AUC/CI numbers; 'pos-calibration' covers the indication × modality × biomarker matrix, the eight 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; '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)."New value: +"Which methodology section to fetch. 'backtest' covers the validation methodology and AUC/CI numbers; 'pos-calibration' covers the indication × modality × biomarker matrix, the eight 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; 'development-paths' covers development-path tiers, automatic-effect policy, and the no path-based PoS/default-multiplier rule; '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)."Input schema / properties / section / enumPrevious value: -[
- "backtest",
- "pos-calibration",
- "ira-framework",
- "evidence-standards",
- "network-benchmarks",
- "cogs-benchmark",
- "sga-benchmark",
- "tax-benchmark",
- "sec-deal-terms"
-]New value: +[
+ "backtest",
+ "pos-calibration",
+ "ira-framework",
+ "development-paths",
+ "evidence-standards",
+ "network-benchmarks",
+ "cogs-benchmark",
+ "sga-benchmark",
+ "tax-benchmark",
+ "sec-deal-terms"
+]Output schema / properties / data / properties / section_id / enumPrevious value: -[
- "backtest",
- "pos-calibration",
- "ira-framework",
- "evidence-standards",
- "network-benchmarks",
- "cogs-benchmark",
- "sga-benchmark",
- "tax-benchmark",
- "sec-deal-terms"
-]New value: +[
+ "backtest",
+ "pos-calibration",
+ "ira-framework",
+ "development-paths",
+ "evidence-standards",
+ "network-benchmarks",
+ "cogs-benchmark",
+ "sga-benchmark",
+ "tax-benchmark",
+ "sec-deal-terms"
+]triage_assetget_methodology1 field changedInput schema / properties / section / descriptionPrevious value: -"Which methodology section to fetch. 'backtest' covers the validation methodology and AUC/CI numbers; 'pos-calibration' covers the indication × modality × biomarker matrix and multipliers; 'ira-framework' covers the Year-9/Year-13 MFP cliff modeling; '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)."New value: +"Which methodology section to fetch. 'backtest' covers the validation methodology and AUC/CI numbers; 'pos-calibration' covers the indication × modality × biomarker matrix, the eight 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; '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)."query_drug_riskverify_export1 field changedOutput schema / properties / data / oneOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "benchmark_dataset_versions": {
- "description": "Array of benchmark dataset versions used; '[]' for legacy rows."
- },
- "content_hash": {
- "type": "string"
- },
- "engine_version": {
- "description": "Engine version stamp at signing time. Sentinel 'unknown (pre-2026-05)' for legacy rows.",
- "type": "string"
- },
- "evidence_count": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "format": {
- "description": "Export format: 'pdf' or 'xlsx'.",
- "type": "string"
- },
- "indication": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "methodology_version": {
- "description": "Methodology version stamp at signing time, e.g. 'methodology@2026-04'.",
- "type": "string"
- },
- "modality": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "org": {
- "description": "Anonymized originating-org identifier, or display name if the org opted into public attribution.",
- "type": "string"
- },
- "signed_at": {
- "description": "ISO 8601 timestamp the artifact was signed by the engine.",
- "type": "string"
- },
- "status": {
- "const": "valid",
- "type": "string"
- }
- },
- "required": [
- "status",
- "content_hash",
- "signed_at",
- "methodology_version",
- "engine_version",
- "benchmark_dataset_versions",
- "format",
- "org",
- "indication",
- "modality",
- "evidence_count"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "message": {
- "type": "string"
- },
- "status": {
- "const": "unknown",
- "type": "string"
- }
- },
- "required": [
- "status",
- "message"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "benchmark_dataset_versions": {
+ "description": "Array of benchmark dataset versions used; '[]' for legacy rows."
+ },
+ "content_hash": {
+ "type": "string"
+ },
+ "engine_version": {
+ "description": "Engine version stamp at signing time. Sentinel 'unknown (pre-2026-05)' for legacy rows.",
+ "type": "string"
+ },
+ "evidence_count": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "format": {
+ "description": "Export format: 'pdf' or 'xlsx'.",
+ "type": "string"
+ },
+ "indication": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "methodology_version": {
+ "description": "Methodology version stamp at signing time, e.g. 'methodology@2026-04'.",
+ "type": "string"
+ },
+ "modality": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "org": {
+ "description": "Anonymized originating-org identifier, or display name if the org opted into public attribution.",
+ "type": "string"
+ },
+ "signals_used": {
+ "description": "Reviewed drug-specific signal provenance included in the signed content hash; [] for none or legacy rows."
+ },
+ "signed_at": {
+ "description": "ISO 8601 timestamp the artifact was signed by the engine.",
+ "type": "string"
+ },
+ "status": {
+ "const": "valid",
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "content_hash",
+ "signed_at",
+ "methodology_version",
+ "engine_version",
+ "benchmark_dataset_versions",
+ "signals_used",
+ "format",
+ "org",
+ "indication",
+ "modality",
+ "evidence_count"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "status": {
+ "const": "unknown",
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "message"
+ ],
+ "type": "object"
+ }
+]query_sec_deal_termsget_methodology3 fields changedInput schema / properties / section / descriptionPrevious value: -"Which methodology section to fetch. 'backtest' covers the validation methodology and AUC/CI numbers; 'pos-calibration' covers the indication × modality × biomarker matrix and multipliers; 'ira-framework' covers the Year-9/Year-13 MFP cliff modeling; '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."New value: +"Which methodology section to fetch. 'backtest' covers the validation methodology and AUC/CI numbers; 'pos-calibration' covers the indication × modality × biomarker matrix and multipliers; 'ira-framework' covers the Year-9/Year-13 MFP cliff modeling; '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)."Input schema / properties / section / enumPrevious value: -[
- "backtest",
- "pos-calibration",
- "ira-framework",
- "evidence-standards",
- "network-benchmarks",
- "cogs-benchmark",
- "sga-benchmark",
- "tax-benchmark"
-]New value: +[
+ "backtest",
+ "pos-calibration",
+ "ira-framework",
+ "evidence-standards",
+ "network-benchmarks",
+ "cogs-benchmark",
+ "sga-benchmark",
+ "tax-benchmark",
+ "sec-deal-terms"
+]Output schema / properties / data / properties / section_id / enumPrevious value: -[
- "backtest",
- "pos-calibration",
- "ira-framework",
- "evidence-standards",
- "network-benchmarks",
- "cogs-benchmark",
- "sga-benchmark",
- "tax-benchmark"
-]New value: +[
+ "backtest",
+ "pos-calibration",
+ "ira-framework",
+ "evidence-standards",
+ "network-benchmarks",
+ "cogs-benchmark",
+ "sga-benchmark",
+ "tax-benchmark",
+ "sec-deal-terms"
+]get_methodology3 fields changedInput schema / properties / section / descriptionPrevious value: -"Which methodology section to fetch. 'backtest' covers the validation methodology and AUC/CI numbers; 'pos-calibration' covers the indication × modality × biomarker matrix and multipliers; 'ira-framework' covers the Year-9/Year-13 MFP cliff modeling; '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."New value: +"Which methodology section to fetch. 'backtest' covers the validation methodology and AUC/CI numbers; 'pos-calibration' covers the indication × modality × biomarker matrix and multipliers; 'ira-framework' covers the Year-9/Year-13 MFP cliff modeling; '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."Input schema / properties / section / enumPrevious value: -[
- "backtest",
- "pos-calibration",
- "ira-framework",
- "evidence-standards",
- "network-benchmarks",
- "cogs-benchmark"
-]New value: +[
+ "backtest",
+ "pos-calibration",
+ "ira-framework",
+ "evidence-standards",
+ "network-benchmarks",
+ "cogs-benchmark",
+ "sga-benchmark",
+ "tax-benchmark"
+]Output schema / properties / data / properties / section_id / enumPrevious value: -[
- "backtest",
- "pos-calibration",
- "ira-framework",
- "evidence-standards",
- "network-benchmarks",
- "cogs-benchmark"
-]New value: +[
+ "backtest",
+ "pos-calibration",
+ "ira-framework",
+ "evidence-standards",
+ "network-benchmarks",
+ "cogs-benchmark",
+ "sga-benchmark",
+ "tax-benchmark"
+]Biotech intelligence for AI agents: drugs, targets, diagnostics, PoS estimates, and writeups.
Machine-native utility network: verified evidence services for autonomous agents.
Agent-first marketplace for real-world assets — agro and energy first; humans approve every write.
Blockchain SSN for AI agents. MCP gateway that blocks at the point of action, tamper evident audit.
Add one secure layer between your agents and this server.
