phasefolio

query_benchmarks

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes	L1 (no-auth) returns a versioned headline set; L3 (bearer) will return granular slices once enough orgs are on the network.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 28, 2026

changedInput schema / properties / indication / description

Previous 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."

Changed5 schema fields changedJul 27, 2026

changedInput schema / properties / metric / description

Previous 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."

addedOutput schema / properties / data / properties / available_metrics

Added value: +{
+  "description": "Network benchmark metric families with published numeric estimates.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / data / properties / note

Added value: +{
+  "description": "Plain-language benchmark-availability and provenance note.",
+  "type": "string"
+}

addedOutput schema / properties / data / properties / planning_defaults_excluded

Added value: +{
+  "description": "True when manual PhaseFolio planning defaults are intentionally excluded.",
+  "type": "boolean"
+}

changedOutput schema / properties / data / required

Previous value: -[
-  "version",
-  "methodology_url"
-]New value: +[
+  "version",
+  "available_metrics",
+  "planning_defaults_excluded",
+  "note",
+  "methodology_url"
+]

First observedMay 3, 2026

TDQS

A3.9/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

All phasefolio tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?