Polygraph MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| can_i_trustB | Answer whether an asset's declared lineage held up under runtime capture. This is the question Polygraph exists for. Returns the verdict Polygraph reached, the evidence behind it, and an explicit statement of what the verdict does and does not establish. |
| get_integrity_scoreB | Get the Lineage Integrity Score for a job, with its components. The score is the Jaccard index of declared vs observed edges. Precision and recall are returned separately because a low score from stale claims and a low score from missing sources need different fixes. |
| list_undeclared_sourcesA | List assets the runtime reads that the catalog never declared. These are usually the most consequential findings: nobody reviewing the catalog could have known these assets are inputs. |
| list_phantom_edgesA | List declared lineage edges that carried no data in the captured run. Usually stale declarations left behind by a refactor. A genuinely conditional edge whose branch was not taken looks identical, so these need human judgement rather than automatic deletion. |
| get_incident_reportB | Retrieve a Polygraph incident report from DataHub's knowledge base. Incident reports name the operation responsible for a model-quality collapse, the owning team, and the real before/after metrics. |
| explain_verdict_semanticsA | Explain exactly what Polygraph's three verdicts mean and do not mean. Call this before presenting verdicts to a person. The verdicts are easy to overstate, and overstating them is the failure mode Polygraph exists to prevent in the first place. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Most tools are clearly distinct: list_undeclared_sources and list_phantom_edges target different finding types, and get_incident_report and explain_verdict_semantics are self-contained. However, can_i_trust and get_integrity_score both address lineage trust at different granularities (asset verdict vs job score), which could cause an agent to misselect without careful reading.
Five of six tools follow a consistent snake_case verb_noun pattern (get_integrity_score, list_*, get_incident_report, explain_verdict_semantics). can_i_trust is also snake_case but is a question phrase rather than verb_noun, a minor deviation.
Six tools are well-scoped for a specialized lineage integrity server: they cover the core questions without redundancy. No unnecessary bloat or missing essential operation.
The surface covers the main analysis workflow: trust verdict, integrity score with components, undeclared sources, phantom edges, incident reports, and verdict semantics. Minor gaps remain (e.g., retrieving raw declared/observed edges for manual comparison), but agents can work around them via existing tools.