phasefolio

verify_export

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

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).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed2 schema fields changedJun 22, 2026

removedInput schema / properties / artifact_url

Removed 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"
-}

addedInput schema / required
```
Added value: +[
+  "hash"
+]
```

Changed1 schema field changedMay 27, 2026

changedOutput schema / properties / data / oneOf

Previous 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"
+  }
+]

First observedMay 3, 2026

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context by spelling out the return values (verification status, issued timestamp, methodology version, anonymized originating-org identifier) and the intended use case (authenticity confirmation). This goes beyond the annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the core action, and includes all necessary information without redundancy. The first sentence states the operation and return values; the second gives the use case. Every sentence earns its place, with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple verification tool with one parameter, an output schema, and comprehensive annotations, the description covers all necessary aspects: what it does, what it returns, and when to use it. It is fully self-contained and leaves no significant gaps for an agent to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage: the hash parameter is fully described with its format, purpose, and where to find it in export files. Since the schema already provides complete parameter semantics, the description does not need to add more. The tool description also references 'content hash,' aligning with the schema. Baseline 3 is appropriate per the rubric.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Verify a signed PhaseFolio export by content hash.' It specifies the resource (signed PhaseFolio export) and the method (content hash), and distinguishes it from all sibling tools (none of which are about verification). It also lists the returned fields, making the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage context: 'Use this when a user shares a PhaseFolio asset snapshot and you want to confirm it's authentic before citing the analysis.' This gives a clear 'when to use' scenario. It does not explicitly mention when not to use or name alternative tools, but the guidance is concrete and sufficient for an agent to select the tool appropriately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All phasefolio tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct entity or operation: get_* fetches specific objects, query_* searches datasets, list_scenarios enumerates, while triage_asset and verify_export are standalone actions. There is no functional overlap or ambiguity among the 13 tools.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in lowercase with underscores. The verbs (get, list, query, triage, verify) clearly indicate the action, and nouns identify the target. This uniform scheme makes the tool purpose predictable.

Tool Count5/5

With 13 tools, the server is well-scoped within the ideal 3–15 range. Each tool addresses a specific aspect of the drug-development analysis domain (project/scenario context, evidence, methodology, benchmarks, risk, landscape, SEC deals, dossier, verification, triage) without redundancy.

Completeness4/5

The read-side surface is thorough for the domain: projects, scenarios, evidence, methodology, benchmarks, drug risk, landscape, SEC deals, dossier, export verification, and triage are all covered. The only minor gap is the lack of a list_projects tool, but get_project can fetch a known project, providing a workaround.

Resources

Need Help?