Maven Bio

View saved version →

---
name: asset-profile
description: "Build a full intelligence packet on one named drug or asset: development status, trial evidence, competitive position, catalysts, and risks. Use when someone names a single asset and wants depth, for example 'tell me everything about X', 'profile this drug', 'is X differentiated'. Use profile-entity instead when only a single structured fact sheet is wanted."
---

# Asset Profile

## Using this skill

Use the connected Maven Bio MCP server at `https://mcp.mavenbio.com/`. Follow the user's explicit scope, depth, and output preferences; the workflow and output structure below are defaults. Report coverage limits instead of silently narrowing an explicitly requested set.

Hyphenated primitive names refer to other skills in this Maven Bio bundle. Consult the relevant skill when composing its workflow. Use the available MCP tool schemas for arguments; pass document identifiers to `read_document` through `ids`, and include a claim-specific `query` when using `format="citations"`.

This workflow produces a structured profile for one asset without assuming a final memo or deck format.

## Primary Primitives

- `profile-entity`
- `benchmark-assets`
- `trace-events`
- `synthesize-evidence`

## Optional Primitives

- `identify-analogs`
- `size-market`
- `synthesize-evidence` (when the asset is approved or near-approval and designation, label, or exclusivity claims need to be tied back to specific filings)
- `validate-target` (when the asset's thesis depends on its target's genetic validation)

## Output Contract

Return a structured asset intelligence package that can include:

- asset overview
- development status
- supporting trial or document evidence
- competitive framing
- recent catalysts
- key risks and unresolved questions

## Workflow Rules

- treat entity profiling as the baseline fact pattern, not the final synthesis
- when calling `research_entity`, keep the raw asset name in `name` and put sponsor/company/disambiguating text in `context`
- use document augmentation to strengthen trial, catalyst, forecast, and competitive claims
- if host web fetch is blocked, prefer `search_documents` and `read_document` over repeated blocked fetch attempts
- if a composite asset name fails to resolve, retry with the raw asset name and move sponsor/company details into the optional context hint
- if the asset is approved in any region, include a regulatory timeline (designations, approval dates, label revisions) built from `search_documents` with `source_types=["fda_filings"]` and `read_document`; cite the filing and its date for each milestone, and state exclusivity or LOE timing as a gap when no filing supports it
- For independent evidence workstreams, follow the [evidence research procedure](references/evidence-research.md) for each scoped pass, then reconcile the claims before synthesis. Run passes sequentially, or in parallel when the host supports it and the task authorizes it.

Referenced files: 3

View saved version →

---
name: benchmark-assets
description: "Compare named assets side by side on a common set of dimensions and return a structured benchmark with explicit evidence strength. Use for direct comparisons, for example 'how does X compare to the other IL-23s', 'benchmark these four programs'. Use identify-analogs when precedents to reason from are wanted rather than a head-to-head table."
---

# Benchmark Assets

## Using this skill

Use the connected Maven Bio MCP server at `https://mcp.mavenbio.com/`. Follow the user's explicit scope, depth, and output preferences; the workflow and output structure below are defaults. Report coverage limits instead of silently narrowing an explicitly requested set.

Hyphenated primitive names refer to other skills in this Maven Bio bundle. Consult the relevant skill when composing its workflow. Use the available MCP tool schemas for arguments; pass document identifiers to `read_document` through `ids`, and include a claim-specific `query` when using `format="citations"`.

This primitive standardizes comparisons across assets without imposing a final table or slide format.

## Use When

- the user wants side-by-side comparison
- a workflow needs comparable dimensions across multiple assets
- you need a reusable comparison object before synthesis

## Core Tools

- `match_entity`
- `search_entities`
- `research_entity`
- `search_documents`
- `read_document` to read a located document (when a benchmark dimension is approval status, designations, or label content, find the label first with `search_documents(source_types=["fda_filings"])` -- `source_types` is a `search_documents` filter, not a `read_document` one)

Use `match_entity` to canonicalize each named asset before benchmarking. Keep the raw asset name in `name` and put sponsor/company/disambiguating text in `context`. Use `search_entities` when you are discovering the benchmark set by criteria rather than starting from a fixed named list.

## Output Contract

Return benchmark items where each asset has dimensions such as:

- mechanism
- lead indication
- highest stage
- differentiating evidence
- key risks

Each dimension should include:

- `value`
- `evidence_rating`
- `citations`
- optional `notes`

## Scaling the Benchmark

The `research_entity`-per-asset path is the right one for small-N comparisons, where
the user needs deep narrative context per asset rather than just structured dimensions.

For larger sets, do not silently degrade the depth of each row to fit the budget.
Narrow the benchmark set first (tighten the phase, indication, or modality scope via
`search_entities`), or reduce the number of comparison dimensions, and say which of
the two you did. A benchmark of 30 assets at one line each is less useful than a
benchmark of 8 assets that actually supports its claims.
- For independent evidence workstreams, follow the [evidence research procedure](references/evidence-research.md) for each scoped pass, then reconcile the claims before synthesis. Run passes sequentially, or in parallel when the host supports it and the task authorizes it.

## Optional Primitives

- `validate-target` (when a benchmark dimension is target genetic validation or tractability)

## Quality Bar

- keep dimensions comparable across assets
- separate directly supported facts from analytic judgment
- when one asset has missing evidence, preserve the asymmetry rather than smoothing it over
- when benchmarking dimensions touch label content, locate each asset's label with `search_documents(source_types=["fda_filings"])` and read the specific document with `read_document`; prefer `format="sections"` to find the relevant section before pulling full text, and cite the document plus its date on each cell

Referenced files: 3

View saved version →

---
name: company-portfolio
description: "Build a full intelligence package on one company: pipeline, recent events, capital position, and strategic posture. Use when someone names a company and wants depth, for example 'profile Vertex', 'what is going on at X', 'walk me through their pipeline'. Use profile-entity instead when only a single structured fact sheet is wanted."
---

# Company Portfolio

## Using this skill

Use the connected Maven Bio MCP server at `https://mcp.mavenbio.com/`. Follow the user's explicit scope, depth, and output preferences; the workflow and output structure below are defaults. Report coverage limits instead of silently narrowing an explicitly requested set.

Hyphenated primitive names refer to other skills in this Maven Bio bundle. Consult the relevant skill when composing its workflow. Use the available MCP tool schemas for arguments; pass document identifiers to `read_document` through `ids`, and include a claim-specific `query` when using `format="citations"`.

This workflow produces company-level intelligence without assuming a report or table deliverable.

## Primary Primitives

- `profile-entity`
- `enumerate-entities`
- `trace-events`
- `trace-financings`
- `synthesize-evidence`

## Optional Primitives

- `identify-analogs`
- `benchmark-assets`
- `synthesize-evidence` (when LOE timing, exclusivity calendar, or label-extension opportunities shape the strategic posture and each date needs a source)

## Output Contract

Return a company intelligence package that can include:

- company overview
- pipeline snapshot
- recent events
- capital posture (recent rounds, total raised in window, lead investors, financing trajectory, runway implication)
- public-market financial caveats when applicable (market cap, cash position, revenue scale)
- strategic themes
- discussion topics or diligence gaps when relevant

## Aggregation Shortcuts

For the capital-trajectory and pipeline-shape views of one company, prefer `aggregate_records` over manually aggregating `research_entity(..., aspects=["financings"])` rounds:

- Financing trajectory: `aggregate_records(entity_type="financing", query="rounds for {company} by year with total value")`
- Pipeline shape: `aggregate_records(entity_type="drug", query="active programs for {company} by phase and indication")`

## Workflow Rules

- treat company/entity profiling as the baseline fact pattern, not the final synthesis
- pair `aspects=["financials"]` with `aspects=["financings"]` on `research_entity` for the public and private capital pictures; for VCs, corporate venture arms, and strategic investors, also pull `aspects=["investments"]`
- treat the `related_previews.financings` and `related_previews.investments` teaser on the default company response as a routing prompt, not as evidence; opt into the full aspect when the funding picture matters to the analysis
- on every financing row, separate the confirmed-value slice from the unconfirmed slice; never aggregate `total_value_usd: null` rounds into a "total raised" headline without footnoting
- augment important company, pipeline, event, and round-level claims with `search_documents` and `read_document`; the structured row is metadata, not citable evidence
- for portfolios with approved assets, surface upcoming patent expiries, biosimilar entry windows, and label-extension opportunities from primary filings via `search_documents(source_types=["fda_filings", "sec_filings"])` and `read_document`; where no filing supports a date, record it as a gap rather than estimating it
- if host web fetch is blocked, prefer Maven-indexed document retrieval over repeated blocked fetch attempts
- For independent evidence workstreams, follow the [evidence research procedure](references/evidence-research.md) for each scoped pass, then reconcile the claims before synthesis. Run passes sequentially, or in parallel when the host supports it and the task authorizes it.

## BD and Diligence Posture

For BD, corp dev, and acquisition-target diligence, the company portfolio should surface a runway-implication slice in addition to the pipeline picture:

- the most recent round (date, type, value, lead investor) versus the company's burn signals from `aspects=["financials"]`
- the financing trajectory (accelerating, flat, or aging since last round)
- investor concentration and lead-investor signal
- the comp-set position relative to peers identified through `identify-analogs` or `enumerate-entities`

A capital-thin or aging-Series-B+ recipient with active mid-stage trials is a candidate signal. A well-funded recipient with a recent strategic investor is a different posture. Make the difference visible rather than collapsing both into "company overview."

For investment-team workflows oriented around capital momentum across a space rather than one company, route to `funding-landscape` instead of building one company portfolio at a time.

Referenced files: 3

View saved version →

---
name: competitive-pipeline
description: "Map who is developing what for an indication, mechanism, or target, grouped by phase, company, or mechanism. Use for competitive questions, for example 'map the NSCLC landscape', 'who else is working on TL1A', 'what is the competition for X'. This is drug-program-centric: use indication-research when the question is about the disease itself, and funding-landscape when it is about capital flow."
---

# Competitive Pipeline

## Using this skill

Use the connected Maven Bio MCP server at `https://mcp.mavenbio.com/`. Follow the user's explicit scope, depth, and output preferences; the workflow and output structure below are defaults. Report coverage limits instead of silently narrowing an explicitly requested set.

Hyphenated primitive names refer to other skills in this Maven Bio bundle. Consult the relevant skill when composing its workflow. Use the available MCP tool schemas for arguments; pass document identifiers to `read_document` through `ids`, and include a claim-specific `query` when using `format="citations"`.

This workflow coordinates primitives to produce a reusable pipeline intelligence package.

The pipeline view is drug-program-centric (which assets are in development, at what phase, with what mechanism). For the capital-flow view of the same space (recent rounds, total raised, investor mix, deal cadence), route to `funding-landscape` instead. The two layers are independent and a complete competitive picture often needs both.

## Primary Primitives

- `enumerate-entities`
- `profile-entity`
- `synthesize-evidence`

## Optional Primitives

- `trace-events`
- `benchmark-assets`
- `synthesize-evidence` -- when the pipeline question includes per-row evaluation criteria beyond catalog metadata (e.g., "which of these have an oral formulation", "which target KRAS G12C specifically"); narrow the set before evaluating rather than thinning the evidence per row
- `validate-target` -- when the pipeline view ranks programs by target genetic validation or specificity

## Output Contract

Return a structured package that can include:

- scoped asset universe
- core confirmed asset set
- watchlist / uncertain asset set
- per-asset evidence-backed profiles
- verification gaps and rows needing follow-up
- key competitive dimensions
- recent catalysts or notable events
- gaps, exclusions, and scope caveats

For pipeline tables or asset lists, use two tiers:

- **Core confirmed**: assets with indication-relevant trial identifiers in the structured payload, or assets confirmed in-session with `read_document`, `research_entity`, or another document/read path.
- **Watchlist / uncertain**: assets without indication-relevant trial identifiers, assets supported only by discovery/search snippets, ambiguous sponsor/name/status matches, conflicting evidence, or assets that need follow-up before promotion.

## Aggregation Shortcuts

For the shape of the pipeline (counts by phase, by mechanism, by sponsor) rather than per-asset detail, use `aggregate_records(entity_type="drug", ...)`. This complements `research_landscape` (which returns the asset list) by giving a chart-ready distribution in a single call.

- Phase distribution: `query="active drugs in {indication} grouped by phase"`
- Mechanism crowding: `query="active drugs in {indication} grouped by mechanism, top 25"`
- Sponsor concentration: `query="active drugs in {indication} grouped by company, top 25"` (note: `companies` is M2M-exploded; co-developed assets count once per owning company)

`aggregate_records` is for the count layer, not the evidence layer. Any quoted statistic still needs a document or trial identifier behind it before it goes into the core confirmed tier.

## Core Research Pattern

This workflow should follow a three-step pattern:

1. **Enumerate** the baseline pipeline universe with structured MCP tools. For the aggregate shape (phase distribution, mechanism crowding, sponsor concentration), use `aggregate_records` to get the picture before enumerating individual assets.
2. **Augment** that baseline with `search_documents`, `read_document`, and event/document checks
3. **Reconcile** the final asset set and key claims before returning the package

`research_landscape` and related structured tools are the right starting point, but they are not the full truth source for a master pipeline analysis. Use document search to surface:

- assets missing from the structured layer
- recent status changes or new disclosures
- naming, ownership, or mechanism discrepancies
- stronger support for the highest-impact competitive claims

## Workflow Rules

- treat scoping as a first-class step
- keep inclusion logic explicit
- treat structured search as the baseline universe, not the final truth
- require a document augmentation pass before finalizing the package
- do not finalize a pipeline after only `research_landscape`, `search_entities`, `fetch_related`, or entity profiles
- before final output, run a scope-reconciliation gate:
  - compare the returned row count to the expected order of magnitude implied by the prompt or prior context
  - check that major mechanism/modality classes and phase/status buckets requested by the user are represented
  - check known anchor assets from the prompt, retrieved documents, or domain context
  - decide whether missing anchors are true exclusions, unresolved gaps, or a signal to broaden the search
- split pipeline outputs into core confirmed rows and watchlist / uncertain rows when row-level confidence varies
- do not promote a structured-search row without an indication-relevant NCT or trial identifier into the core confirmed tier unless you confirmed it in-session with `read_document`, `research_entity`, or another read/fetch path
- confirm key per-asset facts from `search_entities` and `research_landscape` with `search_documents` plus `read_document` or `research_entity` before treating them as evidence-backed claims
- reconcile contradictions between structured outputs and document findings
- use evidence synthesis for the claims that matter most
- avoid assuming a final report, table, or chart format
- group programs by trial phase AND approval status. An approved drug is not Phase 4; for any asset that may already be approved in a covered region, confirm against the catalog phase (`Approved`/`Filed`) and, where the distinction carries the answer, against an FDA filing via `search_documents` plus `read_document`
- For independent evidence workstreams, follow the [evidence research procedure](references/evidence-research.md) for each scoped pass, then reconcile the claims before synthesis. Run passes sequentially, or in parallel when the host supports it and the task authorizes it.

## Fallback Rules

- If you are resolving one named asset, company, or indication, use `match_entity`; reserve `search_entities` for broader criteria-based discovery.
- When calling `match_entity`, keep the raw entity name in `name` and put sponsor/company/disambiguating text in `context`.
- When calling `research_landscape`, keep the raw indication name in `indication` and put extra disambiguating text in `context`.
- If `research_landscape` or related structured enumeration looks too small, run a secondary `search_entities` pass and broad `search_documents` augmentation before finalizing.
- If structured enumeration looks large but noisy, keep the broad set as discovery scaffolding, then use document evidence and explicit exclusion rules to separate core confirmed rows from watchlist rows.
- If a named asset fails to resolve, retry with the raw entity name and move sponsor/company text into the optional context hint.
- If host web fetch is blocked, use `search_documents` plus `read_document`.

Referenced files: 3

View saved version →

---
name: deal-activity
description: "Trace BD deals (licensing, M&A, R&D collaborations, joint ventures) for a company, asset, indication, or deal type, and return structured deal-level evidence with provenance. Use for transaction questions, for example 'who has licensed X', 'what deals have been done in obesity'."
---

# Deal Activity

## Using this skill

Use the connected Maven Bio MCP server at `https://mcp.mavenbio.com/`. Follow the user's explicit scope, depth, and output preferences; the workflow and output structure below are defaults. Report coverage limits instead of silently narrowing an explicitly requested set.

Hyphenated primitive names refer to other skills in this Maven Bio bundle. Consult the relevant skill when composing its workflow. Use the available MCP tool schemas for arguments; pass document identifiers to `read_document` through `ids`, and include a claim-specific `query` when using `format="citations"`.

This primitive turns a business-development question into a structured deal set with explicit value disclosure status, party roles, and document provenance.

## Use When

- the question is fundamentally about deals or transactions, not financing rounds, drug programs, or trials
- a workflow needs cross-company BD activity for a company, an asset, an indication, or a deal type
- you need deal-level evidence (date, type, parties and their roles, value, supporting documents) before reasoning about strategy, valuation benchmarks, or BD momentum

## Core Tools

- `get_deals` for structured cross-company filters (party `company`/`company_id` plus `role`, `deal_type`, USD value range, date window, sort by `total_deal_value_usd`)
- `search_entities("deal", ...)` for natural-language deal discovery and fuzzy phrasings the structured params cannot express
- `research_entity(name, "company", aspects=["deals"])` for the deals a named company is a party to, with a per-row role
- `get_recent_events(entity_name=...)` for the recency-ordered news feed when the question is "what was announced lately"
- `read_document` against the deal's `document_ids` to back any material claim

## Tool Choice

- if the agent already knows the named company, use `research_entity(..., aspects=["deals"])` -- one credit, one shape, no resolution overhead
- if the question is structured ("licensing deals in oncology since 2024 over $500M", "every deal where Pfizer is the out-licensor", "M&A over $1B"), use `get_deals` with typed filters and `role`
- if the question is fuzzy or compositional ("immuno-oncology dealmaking momentum", "recent platform tie-ups"), use `search_entities("deal", ...)` and let the natural-language path translate it
- for "what's new this week" feed-style questions, use `get_recent_events` rather than `get_deals`; the latter is structured search, the former is recency-ordered

## Output Contract

Return a structured deal list with:

- `deal_id` (the prefixed `deal_` identifier)
- `event_date`
- `deal_type` (canonical: Licensing, R&D collaboration, Manufacturing collaboration, Commercialization agreement, Joint venture, M&A - company, M&A - product/asset, Spinoff, Platform/technology access, Service agreement, Other) and `deal_subtype` where present
- parties as `{id, name, role}` (roles: Licensor, Licensee, Collaborator, Acquirer, Acquiree, Investor, Investee, Manufacturer, Distributor, Sponsor, Partner, Seller, Service Provider, Customer)
- `total_deal_value_usd` and `value_status` (`"confirmed"` or `"unconfirmed"`); near-term and milestone payment fields follow the same value-status contract
- linked drugs, indications, and trials as `{id, name}` pairs
- supporting `document_ids` for chaining into `read_document`
- evidence rating per material claim
- explicit gaps for unconfirmed values, missing counterparties, or contradictory sources

## Aggregation Shortcut

If the question is "totals, distributions, or rankings across a deal slice," prefer `aggregate_records(entity_type="deal", ...)` and use `get_deals` to fetch deal-level evidence for the claims you cite. Party fields are M2M-exploded (a deal with three parties counts in all three groups); separate the confirmed-value denominator rather than treating an unconfirmed value as zero.

## Quality Bar

- never present `total_deal_value_usd: null` as "the deal was undisclosed" -- the correct phrasing is "Maven's data does not have the value." The deal may have a publicly disclosed amount Maven has not captured. Verify externally if the value is critical.
- when reporting aggregate totals (sum of deal value, average upfront), separate the confirmed-value slice from the unconfirmed slice
- treat the canonical deal types and roles as closed enums; if a caller-supplied alias resolves to a canonical value ("M&A" -> "M&A - company", "buyer" -> "Acquirer", "out-licensor" -> "Licensor"), surface the resolution explicitly so downstream readers see the normalization
- for deal-level claims (upfront vs milestones vs royalties, biobucks headline, territory scope), require document evidence from `read_document`; the structured row alone is metadata, not citable evidence
- distinguish a deal's headline `total_deal_value_usd` (often a biobucks potential) from realized economics; do not conflate total potential with upfront
- when sorting by deal size, use `sort_by="total_deal_value_usd"` and note that unconfirmed-value deals are ordered last

## Fallback Rules

- if a party name does not resolve, the response surfaces ranked candidates under `unresolved_filters` keyed per input. Retry with a candidate name in one round-trip rather than guessing; if every party name is unresolved the call errors with `entity_not_found`
- if a `deal_type` or `role` value does not match the canonical enum, the response either auto-corrects (case-fold or alias) and surfaces the correction, or rejects with the canonical list. Use the canonical list, do not invent new types or roles
- if `get_deals` returns zero rows for a structured query, retry with `search_entities("deal", "<the same intent in natural language>")` before concluding no deals exist
- if host web fetch is blocked, prefer `search_documents` plus `read_document` against the deal's `document_ids` rather than retrying blocked external fetches
- if a deal question remains blocked after the above, state the gap explicitly in the output rather than substituting a weaker proxy answer

Referenced files: 2

View saved version →

---
name: enumerate-entities
description: "Build the scoped list of drugs, companies, trials, mechanisms, or targets matching a set of criteria, without analyzing each one. Use when the job is to define the right set first, for example 'list every Phase 3 KRAS G12C program'. This is a building block: use competitive-pipeline when the landscape should be analyzed rather than listed."
---

# Enumerate Entities

## Using this skill

Use the connected Maven Bio MCP server at `https://mcp.mavenbio.com/`. Follow the user's explicit scope, depth, and output preferences; the workflow and output structure below are defaults. Report coverage limits instead of silently narrowing an explicitly requested set.

Hyphenated primitive names refer to other skills in this Maven Bio bundle. Consult the relevant skill when composing its workflow. Use the available MCP tool schemas for arguments; pass document identifiers to `read_document` through `ids`, and include a claim-specific `query` when using `format="citations"`.

This primitive is for **scope definition**, not final deliverable formatting.

## Use When

- the user wants the universe of entities in a space
- you need the candidate set before benchmarking or profiling
- the first problem is recall and scoping, not narrative synthesis

## Core Tools

- `match_entity`
- `search_entities`
- `research_landscape`
- `fetch_related`
- `get_financings` for financing-criterion enumeration (e.g., recipients of recent Series B+ rounds in a space, or rounds led by a specific investor set)

## Output Contract

Return a structured entity list with:

- entity id
- entity name
- entity type
- why it is in scope
- evidence status for the inclusion decision
- gaps or ambiguity notes

This primitive is allowed to return `citation_status: unresolved` when the output is still discovery scaffolding rather than document-backed evidence.

## When Enumeration Is Not Enough

Enumeration answers "which entities are in scope". It does not answer questions that
require per-row evaluation against custom criteria rather than catalog metadata:

- the user wants to filter the enumerated set by conditions that require LLM judgment (e.g., "targets KRAS G12C specifically", "has an oral formulation")
- the user wants enrichment dimensions extracted per entity with evidence (e.g., "lead indication", "differentiating feature")
- the evaluation criteria are custom to the question, not fixed catalog fields like phase or mechanism

`enumerate-entities` defines the candidate universe; `synthesize-evidence` evaluates it. When the universe is larger than the evaluation budget, narrow the enumeration criteria rather than reducing the evidence gathered per entity.

## Baseline, Not Completion

Enumeration defines the **baseline universe**. It does not, by itself, complete a master analysis.

For broad analyses such as landscapes, pipelines, benchmark sets, or strategic maps:

- use this primitive to establish the candidate set
- then run a document augmentation pass with `search_documents`, `read_document`, and relevant event checks
- reconcile newly surfaced entities, recent changes, or contradictory evidence before treating the set as final
- run a scope-reconciliation gate before downstream finalization: compare the candidate count, class coverage, phase/status coverage, and known anchor entities against the requested scope
- if the candidate set is suspiciously sparse, too broad, or missing expected anchors, treat that as a research gap and broaden/narrow the search before finalizing

If the entity list is still only discovery scaffolding, keep that explicit in the output.

## Fallback Rules

- If a resolver-backed tool fails on a composite name, retry with the raw entity name and move sponsor/company text into the optional context hint.
- Use `match_entity` when the task starts from one known entity name and you need the canonical Maven entity.
- When calling `match_entity`, keep the raw entity name in `name` and put sponsor/company/disambiguating text in `context`.
- When calling `research_landscape`, keep the raw indication name in `indication` and put extra disambiguating text in `context`.
- Use `search_entities` when the task is to discover or enumerate entities by criteria, filters, or market description.
- For financing-criterion enumeration (recipients of rounds, investor-led sets, capital-flow scoping in a space), use `get_financings` directly when the question is structured (recipient / investor / type / value / date), or `search_entities("financing", ...)` when the question is a natural-language phrasing. The recipient-side ontology axes (indication, modality, mechanism, target) are reachable through `search_entities("financing", ...)` even when not exposed as typed `get_financings` params.
- If the baseline set looks suspiciously sparse, follow with `search_entities` and a document augmentation pass.
- If the baseline set looks noisy or over-broad, preserve a watchlist/exclusions tier rather than collapsing every candidate into the core set.
- If document search surfaces new candidates not seen in the structured layer, preserve them explicitly for reconciliation.

## Aggregation Shortcut

Once a universe is scoped, `aggregate_records(entity_type=X, query="...grouped by Y")` answers "how many in each bucket" without paginating the full enumeration. Use it as a sanity check on the size and shape of the enumerated set before downstream skills consume it.

## Quality Bar

- use explicit scoping criteria
- separate in-scope, borderline, and excluded entities when useful
- do not present enumeration as proof of a downstream factual claim
- do not treat structured enumeration as the final truth for a master analysis without a document augmentation pass
- do not treat an entity set as complete until the scope-reconciliation gate has been run or the remaining uncertainty is stated explicitly
- note ambiguity when the entity set may be incomplete

Referenced files: 2

View saved version →

---
name: financial-forecast
description: "Assemble the assumptions behind a revenue or valuation forecast: population, penetration, pricing, timing, and competitive erosion, each with its evidence. Use when someone is building a model, for example 'what assumptions should I use for X', 'help me forecast peak sales'. Returns assumptions, not a finished spreadsheet or narrative. Use size-market when only sizing is wanted."
---

# Financial Forecast

## Using this skill

Use the connected Maven Bio MCP server at `https://mcp.mavenbio.com/`. Follow the user's explicit scope, depth, and output preferences; the workflow and output structure below are defaults. Report coverage limits instead of silently narrowing an explicitly requested set.

Hyphenated primitive names refer to other skills in this Maven Bio bundle. Consult the relevant skill when composing its workflow. Use the available MCP tool schemas for arguments; pass document identifiers to `read_document` through `ids`, and include a claim-specific `query` when using `format="citations"`.

This workflow is for forecast intelligence, not spreadsheet rendering.

## Primary Primitives

- `size-market`
- `identify-analogs`
- `enumerate-entities`
- `trace-events`
- `synthesize-evidence`
- `profile-entity`

## Optional Primitives

- `benchmark-assets`

## Output Contract

Return a forecast assumption package that can include:

- market assumptions
- analog references
- asset-specific development or competitive assumptions
- scenario caveats
- evidence ratings and citations for material assumptions
- unresolved forecast sensitivities

## Workflow Rules

- treat structured MCP outputs as the starting assumption stack, not the final forecast truth
- use document augmentation for pricing, analog, catalyst, and competitor assumptions that materially affect the package
- if host web fetch is blocked, use `search_documents` and `read_document` as the fallback path before declaring a gap
- For independent evidence workstreams, follow the [evidence research procedure](references/evidence-research.md) for each scoped pass, then reconcile the claims before synthesis. Run passes sequentially, or in parallel when the host supports it and the task authorizes it.

Referenced files: 3

View saved version →

---
name: funding-landscape
description: "Map capital flow across a space: who is funding an indication, mechanism, target, or investor set, how much, and how it has moved over time. Use for market-level money questions, for example 'who is funding TL1A', 'how much has gone into obesity'. Use trace-financings when someone wants the round-by-round record for one company, and competitive-pipeline for drug programs rather than capital."
---

# Funding Landscape

## Using this skill

Use the connected Maven Bio MCP server at `https://mcp.mavenbio.com/`. Follow the user's explicit scope, depth, and output preferences; the workflow and output structure below are defaults. Report coverage limits instead of silently narrowing an explicitly requested set.

Hyphenated primitive names refer to other skills in this Maven Bio bundle. Consult the relevant skill when composing its workflow. Use the available MCP tool schemas for arguments; pass document identifiers to `read_document` through `ids`, and include a claim-specific `query` when using `format="citations"`.

This workflow produces a capital-flow intelligence package for a space, not a drug-program landscape.

## Use When

- an investment team wants recent funding activity in an indication, mechanism, or target
- a BD or corp dev team wants the round-size and investor-mix picture for a space they are evaluating
- a portfolio strategist wants to gauge capital momentum, sentiment, or new-entrant pressure in a competitive area
- the question is about money flowing into a space, not about which drugs are in development there

For the drug-program-centric question (which assets are in trials, at what phase, with what mechanism), use `competitive-pipeline` instead.

## Primary Primitives

- `enumerate-entities` to scope the right indication, mechanism, target, or investor set
- `trace-financings` for round-level capital activity
- `synthesize-evidence` for any quantitative claim that will be cited (totals, top-investor lists, deal cadence)

## Optional Primitives

- `trace-events` for post-round announcements, deals, or regulatory milestones tied to recipients
- `profile-entity` for a focused dive on a notable recipient or investor surfaced by the round set

## Output Contract

Return a funding intelligence package that can include:

- scope summary (which indication / mechanism / target / investor set the package covers, and the time window)
- total raised in window (USD), with the confirmed and unconfirmed slices reported separately
- round count and round-type distribution (Pre-Seed through IPO and beyond)
- top recipients by total raised, each with round count and most recent round
- top investors by activity in the space (count of rounds participated, lead-investor signal where derivable)
- deal cadence (rounds per quarter or per month) so the reader can see acceleration or cooling
- notable rounds (top by value, oversubscribed, strategic investor presence, post-IPO follow-on)
- market signal interpretation (acceleration vs cooling, sub-mechanism momentum, investor concentration)
- explicit gaps and boundary conditions

## Aggregation Shortcuts

When the question is about distributions, rankings, or trends rather than individual rounds, prefer `aggregate_records(entity_type="financing", ...)` over enumerate-and-count. Canonical calls:

- Round-type distribution: `query="rounds in {scope} by financing type with total value and count"`
- Deal cadence: `query="rounds in {scope} by quarter since {date}"`
- Top investors: `query="rounds in {scope} grouped by investor, top 25"`

The `investors` field is M2M-exploded (one round with three investors counts in all three groups). `total_value_input_count` separates confirmed-value rounds from unconfirmed. Use `get_financings` for the round-level evidence that backs any claim you cite.

Government grants (NIH, NCI, NIAID, Innovate UK, Bpifrance) will top investor-count rankings if not filtered. For BD/corp dev personas, exclude grant funders or report them in a separate slice.

## Core Research Pattern

1. **Scope** the right ontology entry. Resolve the indication / mechanism / target (or, for a broad area, a top-level indication) with `match_entity`, or use the recipient-side filters (indication / modality / mechanism / target) surfaced through `search_entities("financing", ...)`. Define the time window explicitly. Decide whether the scope is recipient-side, investor-side, or both.
2. **Enumerate** the round set. For structured filters use `get_financings` directly; for ontology-anchored or fuzzy queries use `search_entities("financing", ...)`. Page through the full matching set, not a sample. For the aggregate shape (round-type distribution, deal cadence, top investors), use `aggregate_records` to get the picture in a single call before drilling into individual rounds.
3. **Augment** with documents and events. For high-signal rounds (top by value, strategic investor, recent), pull supporting `document_ids` via `read_document`, and catch newer rounds with `get_financings` scoped to the company (financing recency is not in `get_recent_events`).
4. **Reconcile** before finalizing. Compare round count and total raised against any prior expectation or anchor knowledge. If counts look suspiciously low, broaden the scope or rerun with a sibling ontology axis (parent indication instead of subtype). If they look noisy, separate the confirmed-value slice from the unconfirmed slice.

## Workflow Rules

- treat the unconfirmed-value slice as a separate visible bucket; never aggregate `total_value_usd: null` rounds into "total raised" without a footnote
- when reporting deal cadence, anchor on quarter-ending dates and call out the trailing-quarter window explicitly
- when reporting top investors, distinguish lead-investor presence (derivable from round documents) from participating-investor presence (the raw investor list)
- pair recent funding cadence with `get_recent_events` so the reader sees both the round and any post-round announcements (clinical readouts, deals, FDA actions) that contextualize the capital
- for VC and corporate venture investor lookups, the natural axis is `aspects=["investments"]` on `research_entity`, not the recipient-side filters
- do not present a funding landscape as proof of clinical or regulatory progress; the two layers are independent and the reader needs both
- distinguish private capital (financing rounds) from public-market signals (market cap, cash, runway from financial statements). The latter lives on `get_financials`; mention it when comparing public-comp valuations
- when the user is a BD or corp dev team sizing acquisition targets, surface a runway-implication slice: companies with thin recent funding, an old last round, or an aging Series B+ are candidate signals (combine with `get_financials` on public comps for full posture)
- For independent evidence workstreams, follow the [evidence research procedure](references/evidence-research.md) for each scoped pass, then reconcile the claims before synthesis. Run passes sequentially, or in parallel when the host supports it and the task authorizes it.

## Fallback Rules

- if the indication fails to resolve, retry with the raw name and move disambiguating text into the optional context hint; if it still fails, broaden to the parent indication and note the scope drift
- if `get_financings` returns zero rounds for a structured query, retry the same intent through `search_entities("financing", ...)` and check whether SSF resolves the scope differently before concluding no activity exists
- if the round set is suspiciously sparse, run sibling-axis enumeration (parent indication, broader mechanism class) and preserve the broader set as discovery scaffolding before finalizing
- if the round set is large and noisy, partition into core confirmed rounds (with supporting documents read in-session) and watchlist rounds (structured-only or thin documents) rather than collapsing every round into the headline narrative
- if a notable round's investor list is dominated by stub companies (`display_only=True` thin profiles), preserve the asymmetry; do not promote a stub-only round to the same evidence tier as a fully-resolved round
- if host web fetch is blocked, augment with `search_documents` plus `read_document` against round-linked documents rather than repeated blocked fetches
- if a workflow gap remains after the above (e.g., the user wants a filter that does not exist on `get_financings`), record it explicitly in the output rather than silently approximating it with a filter that means something else

## Persona Notes

- **Investment teams** typically want recent activity in a thesis space, lead-investor signal, and round-size distribution. Default the time window to trailing 12-24 months and lead with notable rounds plus deal cadence.
- **Pharma BD / corp dev** typically want acquisition-target screening or deal-target identification. Combine the recipient-side round set with `get_financials` on public comps and a runway-implication slice. Surface candidates with thin or aging funding as signal.
- **In-house pharma portfolio / strategy** typically want competitor capital posture and new-entrant detection. Anchor the scope on the same mechanism, target, or indication their internal asset operates in, and pair with `competitive-pipeline` for the program-level view.

Referenced files: 3

View saved version →

---
name: identify-analogs
description: "Find historical or competitive precedents that inform an asset, company, or market question, and explain why each is a fair comparison. Use for precedent reasoning, for example 'what is the closest analog to this launch', 'what should we price off'. Use benchmark-assets for a direct side-by-side comparison of named assets instead."
---

# Identify Analogs

## Using this skill

Use the connected Maven Bio MCP server at `https://mcp.mavenbio.com/`. Follow the user's explicit scope, depth, and output preferences; the workflow and output structure below are defaults. Report coverage limits instead of silently narrowing an explicitly requested set.

Hyphenated primitive names refer to other skills in this Maven Bio bundle. Consult the relevant skill when composing its workflow. Use the available MCP tool schemas for arguments; pass document identifiers to `read_document` through `ids`, and include a claim-specific `query` when using `format="citations"`.

This primitive finds reference cases that help frame expectations without forcing a final output format.

## Use When

- a workflow needs comparable launches or programs
- the user asks for historical analogs
- you need precedent cases to anchor sizing, positioning, or forecast logic

## Core Tools

- `match_entity`
- `search_entities`
- `research_entity`
- `fetch_related`
- `search_documents`
- `read_document`
- `get_recent_events` (when the analogy turns on how a comparable asset's milestones actually unfolded)

Use `match_entity` when you already know the specific entity you want to anchor analog selection around. Keep the raw entity name in `name` and put sponsor/company/disambiguating text in `context`. Use `search_entities` when you are discovering analog candidates by criteria.

## Output Contract

Return a structured analog set with:

- analog entity
- why it is comparable
- evidence-backed dimensions of similarity
- differences or boundary conditions
- evidence ratings and citations

## Optional Primitives

- `validate-target` (when analog selection depends on shared, genetically-validated targets)

## Quality Bar

- explain why each analog belongs in the set
- avoid superficial similarity without mechanism or market logic
- keep disanalogies visible
- treat analog selection as an analytic judgment supported by evidence, not as a fact
- timing-based analogies (LOE-driven generic entry, biosimilar windows, post-exclusivity uptake) require comparable regulatory milestones on both the anchor and each analog; source those milestones from FDA or SEC filings via `search_documents` plus `read_document` before drawing a timing inference, and drop the analogy rather than inferring a date neither filing supports

Referenced files: 2

View saved version →

---
name: indication-research
description: "Build an evidence-backed picture of a disease: clinical context, epidemiology, unmet need, standard of care, and how the pipeline addresses it. Use for disease-first questions, for example 'tell me about ulcerative colitis', 'what is the unmet need in NASH'. Use competitive-pipeline when the question is really about competing drug programs, and size-market when only sizing is wanted."
---

# Indication Research

## Using this skill

Use the connected Maven Bio MCP server at `https://mcp.mavenbio.com/`. Follow the user's explicit scope, depth, and output preferences; the workflow and output structure below are defaults. Report coverage limits instead of silently narrowing an explicitly requested set.

Hyphenated primitive names refer to other skills in this Maven Bio bundle. Consult the relevant skill when composing its workflow. Use the available MCP tool schemas for arguments; pass document identifiers to `read_document` through `ids`, and include a claim-specific `query` when using `format="citations"`.

This workflow gathers the structured research needed to understand an indication without forcing a final document format.

## Primary Primitives

- `size-market`
- `enumerate-entities`
- `synthesize-evidence`

## Optional Primitives

- `trace-events`
- `profile-entity`
- `benchmark-assets`
- `synthesize-evidence` (when the unmet-need or pipeline framing turns on what is already approved and what the approved labels actually say)
- `validate-target` (when the disease primer needs target-level genetic support for key mechanisms)

## Output Contract

Return an indication research package that can include:

- disease context
- epidemiology or sizing assumptions
- current standard-of-care observations
- unmet need framing
- competitive pipeline observations
- evidence gaps and boundary conditions

## Core Research Pattern

For indication-level research, use a layered approach:

1. use structured MCP tools to define the baseline disease, population, and pipeline picture
2. use `search_documents`, `read_document`, and relevant recent-event checks to augment that picture
3. reconcile the final analysis before returning it

In particular, the competitive pipeline portion should not stop at `research_landscape` or other structured enumeration. Treat those outputs as the baseline set, then augment with documents to catch recent updates, missing programs, or evidence that materially changes interpretation.

When the approved-treatment landscape matters (it usually does for unmet-need framing), enumerate the approved drugs in the indication and anchor competitive language in primary-source label text rather than press releases: `search_documents(source_types=["fda_filings"])` scoped to each drug, then `read_document` with `format="sections"` to locate the approved-indication wording before pulling full text. Read labels only for the drugs you will actually cite.

For disease context, sizing, standard of care, and unmet need, do not rely on generic narrative retrieval alone when the user asks for specific quantitative claims. Build a small numeric checklist, retrieve sources for each high-signal number with `search_documents` and `read_document`, and only then synthesize the narrative.

When the request includes many specific rates, percentages, costs, time windows, or other figures, invoke `synthesize-evidence` in Numeric Claim Audit Mode before writing prose. The indication package should preserve the working claim table or summarize unresolved numeric gaps.

Keep the raw indication name in `research_landscape.indication` and move sponsor/company/disambiguating text into `context`. Apply the same pattern to any `research_entity` calls for named assets or companies referenced during the workflow.
- For independent evidence workstreams, follow the [evidence research procedure](references/evidence-research.md) for each scoped pass, then reconcile the claims before synthesis. Run passes sequentially, or in parallel when the host supports it and the task authorizes it.

## Fallback Rules

- If the indication or a referenced entity fails to resolve, retry with the raw name and move extra identifying text into the optional context hint.
- If the pipeline baseline appears sparse, run secondary entity discovery and document augmentation before finalizing.
- If the narrative requires specific figures, run a checklist verification pass and preserve any missing figures as gaps rather than substituting adjacent numbers silently.
- If host web fetch is blocked, prefer `search_documents` and `read_document` rather than repeated blocked fetch attempts.

Referenced files: 3

View saved version →

---
name: profile-entity
description: "Return one structured, evidence-backed fact sheet for a single known drug, company, trial, mechanism, or target. This is a building block the workflow skills compose. Use it directly only when someone wants the raw fact pattern for one entity; for a full asset picture use asset-profile, and for a full company picture use company-portfolio."
---

# Profile Entity

## Using this skill

Use the connected Maven Bio MCP server at `https://mcp.mavenbio.com/`. Follow the user's explicit scope, depth, and output preferences; the workflow and output structure below are defaults. Report coverage limits instead of silently narrowing an explicitly requested set.

Hyphenated primitive names refer to other skills in this Maven Bio bundle. Consult the relevant skill when composing its workflow. Use the available MCP tool schemas for arguments; pass document identifiers to `read_document` through `ids`, and include a claim-specific `query` when using `format="citations"`.

This primitive turns one known entity into a structured fact pattern with explicit provenance.

## Use When

- the user wants depth on a specific named entity
- a workflow needs entity-level facts before synthesis
- you need mechanism, trial, event, document, or per-indication development detail tied to one entity

## Core Tools

- `research_entity`
- `search_documents`
- `read_document`
- `get_recent_events`
- `search_documents` with `source_types=["fda_filings"]` (drug entities, when an approval, designation, or label snapshot matters)

## Output Contract

Return structured findings such as:

- entity summary
- key facts
- evidence-backed claims
- important unknowns

Each claim should include:

- `claim`
- `evidence_rating`
- `citations`
- optional `notes`

## Quality Bar

- use `research_entity` for discovery and structure
- request `aspects=["indication_phases"]` on `research_entity` when you want the asset's per-indication phase/status footprint
- for company entities, request `aspects=["financings"]` for rounds the company received and `aspects=["investments"]` for rounds the company invested in (useful for VCs, corporate venture arms, and strategic investors). Both are opt-in
- the default company response includes a lightweight `related_previews.financings` and `related_previews.investments` teaser (count plus a few sample rounds). Treat these as prompts for whether to opt into the full per-round detail rather than as evidence in their own right
- on every financing row, `value_status` disambiguates `total_value_usd`. `"confirmed"` means Maven has a USD value. `"unconfirmed"` means Maven's data does not have the amount, not that the round was undisclosed in the world. Verify externally if the value is critical
- distinguish `aspects=["financials"]` (public-market financial statements: revenue, EBITDA, market cap, cash) from `aspects=["financings"]` (private/round-level capital activity). Both can apply to the same company; pair them when reasoning about runway or capital posture
- treat `related_previews.documents` and `related_previews.events` as prompts for what to inspect next when you requested a narrower aspect
- use `search_documents` and `read_document` when a claim needs evidence
- for approved drugs, build the approval snapshot from primary filings via `search_documents(source_types=["fda_filings"])` plus `read_document`, and cite the document and its date for any label-sourced claim; report exclusivity or LOE timing as a gap when no filing supports it
- keep the raw entity name in the main tool field and move sponsor/company text into the optional context hint
- do not treat entity metadata alone as direct evidence
- if host web fetch is blocked, use `search_documents` and `read_document` instead of treating the block as the end of the research path
- keep missing or weakly supported facts visible as gaps

Referenced files: 2

View saved version →

---
name: size-market
description: "Estimate patient population and market size with explicit assumptions, evidence strength, and remaining uncertainty. Use when sizing is the question, for example 'how big is the market for X', 'how many patients are eligible'. Use financial-forecast when revenue projection assumptions are wanted, and indication-research for the broader disease picture."
---

# Size Market

## Using this skill

Use the connected Maven Bio MCP server at `https://mcp.mavenbio.com/`. Follow the user's explicit scope, depth, and output preferences; the workflow and output structure below are defaults. Report coverage limits instead of silently narrowing an explicitly requested set.

Hyphenated primitive names refer to other skills in this Maven Bio bundle. Consult the relevant skill when composing its workflow. Use the available MCP tool schemas for arguments; pass document identifiers to `read_document` through `ids`, and include a claim-specific `query` when using `format="citations"`.

This primitive produces structured population and market-sizing assumptions, not a finished financial model.

## Use When

- the user asks for prevalence, incidence, addressable population, or market size
- a workflow needs sizing assumptions before forecast or prioritization
- you need an explicit epidemiology funnel with evidence discipline

## Core Tools

- `match_entity`
- `search_documents`
- `read_document`
- `search_entities`
- `research_entity`

Use `match_entity` when the market-sizing task starts from one known asset, company, or indication. Keep the raw entity name in `name` and put sponsor/company/disambiguating text in `context`. Use `search_entities` when you need to discover a broader entity set by criteria.

## Output Contract

Return a sizing object with:

- population layers or funnel steps
- assumption values
- evidence ratings
- citations
- caveats

## Quality Bar

- show the decomposition rather than only the final number
- cite assumptions at the layer where they enter the logic
- label extrapolations or weak steps honestly
- preserve uncertainty instead of false precision

Referenced files: 2

View saved version →

---
name: synthesize-evidence
description: "Turn already-discovered facts into evidence-backed claims with evidence ratings, verbatim quotes, and canonical source references. Use as the final evidence pass before presenting findings, or when a claim must be tied back to a specific filing. This is a building block the workflow skills compose."
---

# Synthesize Evidence

## Using this skill

Use the connected Maven Bio MCP server at `https://mcp.mavenbio.com/`. Follow the user's explicit scope, depth, and output preferences; the workflow and output structure below are defaults. Report coverage limits instead of silently narrowing an explicitly requested set.

Hyphenated primitive names refer to other skills in this Maven Bio bundle. Consult the relevant skill when composing its workflow. Use the available MCP tool schemas for arguments; pass document identifiers to `read_document` through `ids`, and include a claim-specific `query` when using `format="citations"`.

This primitive is the bridge from research findings to defensible claims.

## Use When

- a claim needs stronger support
- a workflow has facts but not enough provenance
- you need to downgrade or tighten a statement based on what the documents actually say
- a narrative depends on quantitative claims such as incidence, prevalence, utilization, outcomes, cost, treatment windows, response rates, or safety rates

## Core Tools

- `search_documents`
- `read_document`
- `get_recent_events`
- `search_documents` with `source_types=["fda_filings"]` (when claim provenance is a regulator label)

## Output Contract

Return structured claim objects:

- `claim`
- `evidence_rating`
- `citations`
- `notes`
- `gaps`

Example citation object:

```json
{
  "source_ref": {
    "id": "doc_abc123",
    "kind": "document",
    "tool": "read_document",
    "url": "https://example.com/doc"
  },
  "quote": "verbatim supporting text"
}
```

## Numeric Claim Audit Mode

Use this mode when the output needs quantified disease burden, treatment utilization, standard-of-care rates, clinical outcomes, safety rates, pricing, market size, or other numeric claims.

Before writing prose:

1. Extract a checklist of required numeric claims from the user request.
2. For each claim, run targeted `search_documents` queries rather than one broad topic search.
3. Read the strongest source candidates with `read_document`, usually `format="sections"` or `format="citations"`.
4. Return a working claim table with:
   - `claim_needed`
   - `value_found`
   - `source_ref`
   - `quote`
   - `evidence_rating`
   - `status`: `found`, `adjacent`, `conflicting`, or `missing`
   - `notes`
5. Only synthesize numbers marked `found` or clearly `adjacent`; preserve `conflicting` and `missing` items as gaps.

Do not substitute a nearby number silently. For example, if the user asks for AIS share of all strokes and the source only supports global ischemic-stroke share, record the mismatch rather than treating it as the requested number.

## Quality Bar

- use verbatim supporting quotes
- prefer primary or authoritative documents when available
- use the actual document ID, NCT ID, or URL returned by the tool result; do not invent plugin-local aliases
- for regulatory claims (approval status, label content, exclusivity, designations), cite the document ID (`doc_...`) plus its date. Direct quotes from the label text are preferred over paraphrase: locate the filing with `search_documents(source_types=["fda_filings"])`, use `read_document` with `format="sections"` to find the relevant section, then pull `format="text"` narrowly for the passage you will quote
- if host web fetch is blocked, treat `search_documents` plus `read_document` as the standard fallback path
- downgrade evidence strength when the support is indirect
- if the support is missing, record the gap instead of forcing a claim
- do not write final narrative prose until high-signal numeric claims have been audited into structured claim objects

Referenced files: 2

View saved version →

---
name: trace-events
description: "Return the recent event stream (FDA actions, trial readouts, press releases) for a named drug, company, trial, or indication, with structured evidence per event. Use for recency questions, for example 'what happened with X recently', 'any news on this program'. This is a building block the workflow skills compose."
---

# Trace Events

## Using this skill

Use the connected Maven Bio MCP server at `https://mcp.mavenbio.com/`. Follow the user's explicit scope, depth, and output preferences; the workflow and output structure below are defaults. Report coverage limits instead of silently narrowing an explicitly requested set.

Hyphenated primitive names refer to other skills in this Maven Bio bundle. Consult the relevant skill when composing its workflow. Use the available MCP tool schemas for arguments; pass document identifiers to `read_document` through `ids`, and include a claim-specific `query` when using `format="citations"`.

This primitive is for timeline-style intelligence and recent developments.

## Use When

- the user asks what happened recently
- a workflow needs catalysts, recent news, or regulatory updates
- you need a recent-event layer around an entity or indication

## Core Tools

- `get_recent_events`
- `read_document`
- `search_documents`

## Output Contract

Return a structured event list with:

- date
- event type
- summary
- evidence rating
- citations
- unresolved questions

## Quality Bar

- use event feeds for discovery
- strengthen material claims with document reads when needed
- keep chronology explicit
- preserve ambiguity if event interpretation is uncertain

Referenced files: 2

View saved version →

---
name: trace-financings
description: "Return the round-by-round financing record (amounts, dates, investors, provenance) for a named company, or filtered by indication, mechanism, target, or investor. Use when someone wants the actual rounds, for example 'list the funding rounds for X', 'who invested in their Series B'. Use funding-landscape when they want a market-level capital picture rather than a round list."
---

# Trace Financings

## Using this skill

Use the connected Maven Bio MCP server at `https://mcp.mavenbio.com/`. Follow the user's explicit scope, depth, and output preferences; the workflow and output structure below are defaults. Report coverage limits instead of silently narrowing an explicitly requested set.

Hyphenated primitive names refer to other skills in this Maven Bio bundle. Consult the relevant skill when composing its workflow. Use the available MCP tool schemas for arguments; pass document identifiers to `read_document` through `ids`, and include a claim-specific `query` when using `format="citations"`.

This primitive turns a funding question into a structured round set with explicit value disclosure status, investor mix, and document provenance.

## Use When

- the question is fundamentally about funding rounds, not drug programs or trials
- a workflow needs capital activity for a company, an indication, a mechanism, a target, or an investor
- you need round-level evidence (date, type, value, recipient, investors, supporting documents) before reasoning about runway, momentum, or investor signal

## Core Tools

- `get_financings` for structured cross-company filters (recipient, investor, financing_type, value range, date window, current-only, sort by total_value)
- `search_entities("financing", ...)` for natural-language financing discovery and fuzzy phrasings the structured params cannot express
- `research_entity(name, "company", aspects=["financings"])` for rounds where a named company was the recipient
- `research_entity(name, "company", aspects=["investments"])` for rounds where a named company was an investor (VCs, corporate venture arms, strategic investors)
- `get_financings` with a recent date window (newest first) for the recency feed of newly announced rounds -- financing recency is not in `get_recent_events`
- `read_document` against the round's `document_ids` to back any material claim

## Tool Choice

- if the agent already knows the named company, use `research_entity` aspects -- one credit, one shape, no resolution overhead
- if the question is structured ("Series B+ rounds in NSCLC since 2024", "rounds led by ARCH or Founders Fund", "rounds over $100M"), use `get_financings` with typed filters
- if the question is fuzzy or compositional ("late-stage immuno-oncology momentum", "biotech IPOs this year"), use `search_entities("financing", ...)` and let the natural-language path translate it
- for "what's new this week" feed-style questions, use `get_financings` with a recent date window; financing recency lives in `get_financings`, not `get_recent_events` (which covers only fda/trial/press)

## Output Contract

Return a structured round list with:

- `round_id` (the prefixed `fin_` identifier)
- `financing_date`
- `financing_type` (canonical: Pre-Seed, Seed, Series A, Series B, Series C, Series D+, IPO, Post-IPO Equity, Debt Financing, Grant, Strategic Investment, Acquisition, Other Financing)
- recipient companies as `{id, name}` pairs
- investor companies as `{id, name}` pairs
- `total_value_usd` and `value_status` (`"confirmed"` or `"unconfirmed"`)
- supporting `document_ids` for chaining into `read_document`
- evidence rating per material claim
- explicit gaps for unconfirmed rounds, missing investors, or contradictory sources

## Aggregation Shortcut

If the question is "totals, distributions, or rankings across a financing slice," prefer `aggregate_records(entity_type="financing", ...)` and use `get_financings` to fetch round-level evidence for the claims you cite. `median`/`avg` aggregations on `total_value` already separate the confirmed-value denominator via `_input_count`.

## Quality Bar

- never present `total_value_usd: null` as "the round was undisclosed" -- the correct phrasing is "Maven's data does not have the value." The round may have a publicly disclosed amount Maven has not captured. Verify externally if the value is critical.
- when reporting aggregate totals (sum raised, average round size), separate the confirmed-value slice from the unconfirmed slice rather than treating null as zero
- treat the canonical financing types as a closed enum; if a caller-supplied type alias resolves to a canonical value, surface the resolution explicitly so downstream readers see the normalization
- for round-level claims (lead investor, oversubscription, valuation, post-money), require document evidence from `read_document`; the structured row alone is metadata, not citable evidence
- the investor list may include thin-profile stub companies for previously-unknown investors -- these resolve via `research_entity` but with limited data; preserve the asymmetry rather than smoothing it over
- distinguish `get_financings` (private/round-level capital activity) from `get_financials` (public-market financial statements: revenue, EBITDA, market cap, cash). Both can apply to the same company; do not conflate them
- when sorting by deal size, use `sort_by="total_value"` and note that unconfirmed rounds are ordered last

## Fallback Rules

- if a recipient or investor name does not resolve, the response surfaces ranked candidates under `error.alternatives` keyed per input. Retry with a candidate name in one round-trip rather than guessing
- if a `financing_type` value does not match the canonical enum, the response either auto-corrects (case-fold or alias) and surfaces the correction, or rejects with the canonical list under `error.alternatives`. Use the canonical list, do not invent new types
- if `get_financings` returns zero rows for a structured query, retry with `search_entities("financing", "<the same intent in natural language>")` before concluding no rounds exist
- for indication / mechanism / target ontology axes, the recipient-side filters live on `search_entities("financing", ...)`; the structured `get_financings` surface does not expose them as typed params
- if host web fetch is blocked, prefer `search_documents` plus `read_document` against the round's `document_ids` rather than retrying blocked external fetches
- if a financing question remains blocked after the above, state the gap explicitly in the output rather than substituting a weaker proxy answer

Referenced files: 2

View saved version →

---
name: validate-target
description: "Validate the genetic basis of a drug target: gene-disease association strength, gene constraint, tractability, and known drugs, from public biomedical databases. Use when a thesis turns on whether a target is genetically validated."
---

# Validate Target

## Using this skill

Use the connected Maven Bio MCP server at `https://mcp.mavenbio.com/`. Follow the user's explicit scope, depth, and output preferences; the workflow and output structure below are defaults. Report coverage limits instead of silently narrowing an explicitly requested set.

Hyphenated primitive names refer to other skills in this Maven Bio bundle. Consult the relevant skill when composing its workflow. Use the available MCP tool schemas for arguments; pass document identifiers to `read_document` through `ids`, and include a claim-specific `query` when using `format="citations"`.

This primitive answers "is this target genetically validated, and how strongly" with evidence from public databases (Open Targets, gnomAD, GWAS Catalog).

## Use When

- the thesis or landscape turns on a target's genetic validation
- a workflow needs gene-disease association strength before ranking programs
- you need target tractability / druggability or gene constraint (LOEUF)
- you need the drugs in development against a target, or repurposing hypotheses (speculative)

## Core Tools

- `match_entity` - confirm the gene / disease / target is the one you mean, and pick up its canonical name and synonyms. Use the resolved *name*, not the returned `tgt_` id, when calling `research_bio_evidence`.
- `research_bio_evidence(name, entity_type, aspects)` - the bio evidence tool. Select `aspects`:
  - `tractability` - target druggability
  - `constraint` - gene constraint (gnomAD LOEUF)
  - `associations` - gene<->disease association (genetic + L2G + overall score); pass `context=<disease>` to scope a target to one disease
  - `known_drugs` - drugs and clinical candidates in development against the target
  - `repurposing` - repurposing candidates (opt-in; always speculative)
- `research_entity`, `search_documents`, `read_document` - strengthen or cross-check bio findings against the Maven corpus

## Output Contract

Return a structured target-validation object that can include:

- resolved target (gene symbol) and disease (EFO/MONDO id)
- association strength with `evidence_rating` (Direct for curated DB associations, Indirect for inferred/aggregated scores)
- gene constraint and tractability with `evidence_rating`
- drugs in development against the target
- repurposing hypotheses, each explicitly marked speculative
- explicit gaps (unresolved ids, fuzzy disease-ontology matches, no association found)

Each claim carries: `claim`, `evidence_rating`, `citations` ([{source_id, quote}]), optional `notes`. Evidence is structured metadata attached to claims, not inline prose markup.

## Quality Bar

- a fuzzy disease-ontology match downgrades the evidence_rating one level and is flagged
- repurposing output is always labeled speculative; never Direct Evidence
- a curated database association (with a source record) is Direct; an inferred score is Indirect
- do not treat an entity-resolution result as a citation
- pass `research_bio_evidence` a raw gene symbol or disease name (`PCSK9`, `NASH`), never a Maven `tgt_`/`ind_` id. It resolves against external databases, which do not know Maven ids, and an id silently returns `resolved: false` with no error rather than failing loudly. For a target-disease pair, put the disease in `context`
- check `resolution.resolved` on every `research_bio_evidence` response before reading the payload. When it is false, retry once with an official gene symbol or a documented synonym from `match_entity` before concluding anything
- report an unvalidated target only when a resolved lookup came back with no association. `resolved: false` means the name did not match, not that the target lacks evidence; the two must never be reported the same way

Referenced files: 2