How do I use PADC Evidence Lab?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@PADC Evidence Lab run a claim-bound review of DOC_001 for claim 'X' and propose status" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

PADC Evidence Lab

by HenricTBoehm

Overview Schema Source Related Servers Discussions Admin

Python

Local

PADC Evidence Lab v0.1.1.1

Source-Completeness and Provenance-Binding Hardened Prototype

Author: Henric T. Böhm — ORCID: 0009-0005-0349-6341

Prototype implementation of an audit-oriented evidence contract for agentic research workflows.

The core separation is:

Proposal != Evidence != Admissibility != Adjudication

The MCP agent may propose an epistemic status, but it cannot directly create source facts, page locators, extraction-completeness facts, provenance records, missingness records, or guard outcomes.

Research question and patch status

v0.1.0 asked whether the separation could be implemented. v0.1.1 asks a narrower adversarial question:

Does the implemented separation survive provenance counterexamples involving source completeness, historical artifact binding, and derived-state authority?

v0.1.1.1 is a narrowly scoped identity/immutability patch. It preserves the v0.1.1 architecture and adds the invariant that a stable server-derived artifact ID denotes immutable artifact content. Repeated creation of the same Missingness situation returns the already registered record. New claims are representation-normalized (Unicode NFC plus whitespace collapse) before claim hashing and new artifact storage; this normalizes representation, not meaning.

The target status is HARDENED REFERENCE PROTOTYPE — FREEZE CANDIDATE, not a validated PADC implementation, semantic evidence engine, or production audit system.

Related MCP server: aafp-commons

Epistemic statuses

S — Supported
P — Partially Supported
NS — Not Supported
C — Contradicted
NE — Non-Evaluable

S, P, and C require current server-generated EvidenceObject IDs. P additionally requires explicit conditions.

NS requires a current, claim-specific, protocol-complete DocumentReview over an explicitly declared complete PAGE_INDEXED_TEXT surface. The assessment binds to the exact review_id. A later review cannot retroactively revalidate an older NS assessment.

NE requires a server-generated MissingnessRecord. The assessment binds to the exact missingness_id. A later MissingnessRecord cannot retroactively revalidate an older NE assessment.

Passing a guard means only:

STRUCTURALLY ADMISSIBLE PROPOSAL FOR <status>

It does not mean that the status has been semantically adjudicated.

Declared extraction surface

v0.1.1.1 does not infer document completeness from the set of pages that happened to be ingested. Trusted ingestion must declare the expected PAGE_INDEXED_TEXT surface using either --expected-page-count or --expected-pages.

The resulting ExtractionManifest records, among other fields:

surface_type = PAGE_INDEXED_TEXT
expected and extracted page numbers
missing and unexpected page numbers
extraction_complete
declared_text_surface_complete
excluded modalities
extraction method and version
extraction_manifest_hash

A complete page-indexed text surface does not imply semantic exhaustion of the complete document. By default, the declared text surface explicitly excludes IMAGES, TABLE_STRUCTURE, and EMBEDDED_FILES.

Therefore:

protocol_complete_text != document_semantically_exhausted

Trust boundary

Trusted source ingestion is intentionally not exposed as an MCP tool.

A source is ingested out-of-band through padc-evidence-ingest. The MCP server can search and reference trusted state but no MCP tool exposes trusted ingestion.

This is an MCP capability boundary, not a complete operating-system security boundary. Protection against direct modification of the JSON state file additionally depends on host-level authority separation. If an agent has a separate shell or filesystem capability with write access to that state file, the MCP boundary alone does not prevent such modification.

The persistent audit log is audit-oriented. It is not append-only by cryptographic enforcement, externally attested, or tamper-resistant.

Install

python -m venv .venv
source .venv/bin/activate        # Windows: .venv\Scripts\activate
pip install -c constraints.txt -e ".[dev]"

The reference constraints pin MCP 2.3.0 and the dependency versions used for the v0.1.1/v0.1.1.1 core regression runs. See VALIDATION.md. The trusted page-extraction subprotocol remains version 0.1.1 because v0.1.1.1 does not change extraction semantics; it patches claim representation normalization and Missingness artifact identity.

Trusted ingestion

Prepare page-indexed text:

{
  "1": "First page text...",
  "2": "Second page text..."
}

The bundled example intentionally uses the page labels 1 and 12. If those are the trusted expected page labels for the declared text surface, ingest it as:

padc-evidence-ingest \
  --state ./data/evidence_state.json \
  --item-id DOC_001 \
  --title "Example Paper" \
  --pages-json ./examples/doc_001_pages.json \
  --collection COLL_MAIN \
  --expected-pages 1,12

For an ordinary contiguous twelve-page document, use --expected-page-count 12. If only pages 1 and 12 were then ingested, pages 2--11 would be recorded as missing and the declared text surface would remain incomplete.

If neither expected-page option is supplied, the ingested pages remain searchable, but declared_text_surface_complete is false and a complete NS review cannot be established.

Optionally add --artifact path/to/original.pdf to record the SHA-256 of the original artifact. Re-ingesting the same item_id creates a new immutable source revision. Historical assessment identity remains unchanged; current provenance may become invalid.

MCP tools

The MCP tool surface remains deliberately small:

list_sources()
find_evidence(item_id, query, limit=5)
run_document_review(item_id, claim, search_terms=[], semantic_queries=[])
validate_evidence_assessment(proposal)
build_evidence_matrix(collection_id)

There is deliberately no MCP tool for registering source text, assigning source revisions, creating MissingnessRecords directly, or declaring a review complete.

Semantic queries

The current review API retains semantic_queries as a declaration field for forward-compatible experiments, but no semantic-search adapter is executed in v0.1.1.1. Reviews record this as:

declared_semantic_queries_not_executed = [...]
semantic_search_executed = false
semantic_search_adapter = null

Two hashes separate contract from execution:

review_contract_hash        = hash(declared review contract)
executed_review_trace_hash  = hash(actually executed review trace)

Unexecuted semantic queries may affect the contract hash; they never masquerade as executed search in the execution trace.

Artifact identity and Missingness idempotence

For new server-derived Missingness artifacts, identity is content-stable:

MIS_1 = MIS_2  =>  dump(MIS_1) = dump(MIS_2)

After the deterministic missingness_id is computed, an existing record under that ID is returned unchanged rather than overwritten with a new created_at. New claim identity uses Unicode NFC normalization and collapses whitespace runs before hashing/storage. This prevents representational variants such as repeated spaces or canonically equivalent Unicode forms from creating or overwriting semantically intended duplicate Missingness artifacts. No semantic equivalence beyond this representation normalization is inferred.

Audit semantics

structurally_admissible is historical: it records whether the proposal passed the guards at submission time.

provenance_valid is revision-relative: it is re-computed against the current trusted source state using the exact supporting artifact IDs originally bound to the assessment.

Thus:

Assessment identity is historical.
Provenance validity is revision-relative.

and a valid matrix state may be:

structurally_admissible = true
provenance_valid        = false

A later DocumentReview cannot replace the review_id bound to an older NS assessment. A later MissingnessRecord cannot replace the missingness_id bound to an older NE assessment.

Collection membership is derived from the current SourceRecord rather than treated as an independent authority. Revisions therefore remove stale membership.

All assessment attempts, including rejected ones, are persisted. The log is not claimed to be a tamper-resistant ledger.

Tests

pytest

The regression suite covers, among other cases:

fabricated/unknown evidence IDs are rejected
page locators are server-derived
stale evidence is rejected after source revision
P requires and preserves explicit conditions
partial extraction cannot establish a complete text-surface review
expected document surface is not inferred from ingested dictionary keys
NS binds to the exact historical review_id
a new review cannot revalidate an old NS assessment
NE binds to an exact server-generated MissingnessRecord
a new MissingnessRecord cannot revalidate an old NE assessment
repeated creation of the same Missingness situation is idempotent and does not mutate created_at
Unicode/whitespace representation variants resolve to the same canonical Missingness identity
closing a later evidence gap changes current provenance, not historical admissibility
collection revision removes stale membership
declared semantic queries remain visibly unexecuted
model-reported confidence has no effect on guards
rejected attempts remain visible in the audit log

Scope

v0.1.1.1 intentionally does not add semantic adjudication, native PDF/Zotero ingestion, empirical PADC/DEA validation, multi-user authorization, a general governance-effectiveness claim, or a cryptographically tamper-resistant audit ledger.

The governing implementation principle remains:

An agent may propose an evidence status, but it may not create the trusted facts that make that status structurally admissible.

License

MIT License. See LICENSE.

Available Tools

5 tools

build_evidence_matrixC

Build a current-collection-scoped audit matrix.

structurally_admissible is historical; provenance_valid is re-computed using the exact historical provenance artifacts bound to each assessment.

ParametersJSON Schema

Name	Required	Description	Default
`collection_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`rows`	Yes
`stage_counts`	Yes
`collection_id`	Yes
`total_assessments`	Yes

TDQS

C2.7/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden, and it does disclose one non-obvious trait: structurally_admissible is carried over historically while provenance_valid is re-computed from bound provenance artifacts. However, it never says whether 'build' persists a new artifact, what permissions are required, or whether the operation is read-only or idempotent.

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

Conciseness3/5

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

It is short and front-loads the purpose line. The second sentence, however, is cryptic field-level jargon that only makes sense to someone already familiar with the domain model, so the brevity comes partly from omitted context rather than efficiency.

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

Completeness3/5

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

An output schema exists, so the return shape needn't be described. Still, for a tool whose verb 'build' implies possible mutation, the description omits side effects and workflow placement, leaving the agent without enough to know when to call it versus its siblings.

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

Parameters2/5

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

Schema coverage is 0% and collection_id is never mentioned in the description. 'current-collection-scoped' hints that a collection is the scope but does not explain what collection_id refers to, what format it takes, or whether 'current' implies a caller-context default.

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

Purpose3/5

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

It gives a specific verb (build) and resource (audit matrix) plus a scope (current-collection), so an agent can tell it produces something rather than reads it. But 'audit matrix' is undefined jargon, and nothing distinguishes it from evidence-focused siblings like validate_evidence_assessment or find_evidence.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The relationship to validate_evidence_assessment or run_document_review is left entirely to inference, which is a real gap given how many overlapping evidence tools are in the sibling list.

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

find_evidenceC

Search trusted page-indexed source text.

Excerpts and page numbers are derived by the server; the agent cannot supply either field.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes
`item_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses a negative constraint — excerpts and page numbers are server-derived and cannot be supplied by the agent — but says nothing about read-only semantics, required permissions, rate limits, or result shape. It adds real value yet leaves key behavioral traits undocumented.

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 tight sentences, front-loaded with the core purpose, and the second sentence earns its place by clarifying a real constraint rather than restating the name. It is lean, though arguably too lean given the undocumented parameters.

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

Completeness2/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 explanation is not required. However, with zero annotation coverage and 0% parameter documentation, the description leaves an agent without the semantics needed to fill in item_id and query confidently; only the server-derived-field note is covered.

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

Parameters2/5

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

Schema description coverage is 0% across three parameters (item_id, query, limit), so the description must compensate and largely does not. It never explains what item_id identifies, how the query is matched, or what limit controls; the only hinted semantics come indirectly from "page-indexed source text."

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 specific verb ("Search") and a clearly bounded resource ("trusted page-indexed source text"), which is enough to distinguish it from siblings like build_evidence_matrix or validate_evidence_assessment. It stops short of naming an alternative sibling explicitly, so it isn't a 5.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisite or exclusion statements, and no routing to alternatives among the four sibling tools. The phrase "trusted page-indexed source text" implies scope, but the agent must infer when to call this versus list_sources or run_document_review.

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

list_sourcesB

List current trusted source revisions and declared text-surface completeness.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It does imply scope ('current' = latest revisions only, 'trusted' = a filtered set) and that output reports completeness status, but it omits whether it is read-only, auth requirements, or result size behavior.

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?

A single front-loaded sentence with no filler; the core action and scope lead, and nothing is padded.

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

Completeness3/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 detail need not be repeated. For a zero-param list tool this is nearly sufficient, but the absence of any usage/routing guidance leaves a gap an agent would want filled.

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

Parameters4/5

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

The tool takes zero parameters, so the schema-empty baseline of 4 applies. There are no arguments whose meaning the description needs to clarify.

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 specific verb (List) and resource (trusted source revisions) plus the extra dimension of text-surface completeness. It is distinguishable from read-oriented siblings like find_evidence, though it never explicitly names an alternative.

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

Usage Guidelines2/5

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

The description says what is listed but never when to reach for it versus find_evidence, build_evidence_matrix, or the other siblings. No exclusions, prerequisites, or invocation context are given.

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

run_document_reviewC

Run a server-side PAGE_INDEXED_TEXT review protocol for an exact claim.

protocol_complete is derived from an explicitly declared complete text surface and page coverage. semantic_queries are stored as declared but are not executed in v0.1.1.1; the returned review states this explicitly.

ParametersJSON Schema

Name	Required	Description	Default
`claim`	Yes
`item_id`	Yes
`search_terms`	No
`semantic_queries`	No

TDQS

C2.9/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that protocol_complete is derived from declared text surface and page coverage, and that semantic_queries are stored but not executed in v0.1.1.1, but it does not state side effects, permissions, read/write behavior, or rate limits.

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?

The description is short and front-loads the core action, then adds two sentences of relevant behavioral detail. The backticked terms and line breaks make it slightly technical, but there is little wasted text.

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

Completeness2/5

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

For a four-parameter tool with no annotations, no output schema, and no schema parameter descriptions, the description is incomplete. It omits usage routing, parameter meanings, and side-effect expectations, leaving substantial gaps for an agent trying to invoke it correctly.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate for four undocumented parameters. It explains the behavior of semantic_queries as stored but not executed, but it leaves item_id, claim, and search_terms largely undefined beyond their names.

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?

The description states a specific verb and resource: running a server-side PAGE_INDEXED_TEXT review protocol for an exact claim. It distinguishes the tool from generic evidence gathering by naming a review protocol, but does not explicitly contrast it with sibling tools such as find_evidence or build_evidence_matrix.

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

Usage Guidelines2/5

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

The description gives no explicit when-to-use guidance, no when-not-to-use conditions, and no alternatives among the sibling tools. It only implies usage by saying the tool runs a review protocol for an exact claim.

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

validate_evidence_assessmentB

Validate structural admissibility and persist every attempt.

Passing means STRUCTURALLY ADMISSIBLE PROPOSAL FOR ; it does not semantically adjudicate the claim. NE is bound to a server-derived MissingnessRecord.

ParametersJSON Schema

Name	Required	Description	Default
`proposal`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes
`proposal`	Yes
`created_at`	Yes
`assessment_id`	Yes

TDQS

B3.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does meaningfully disclose behavior: every attempt is persisted regardless of outcome, and passes are only structurally admissible proposals rather than semantic judgments. The NE edge case tied to a server-derived MissingnessRecord is a real behavioral detail. Gaps remain on permissions, idempotency, and failure behavior.

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

Conciseness4/5

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

Three short sentences with the core action front-loaded and no padding. The jargon ('structurally admissible', 'MissingnessRecord') is domain-specific rather than wasteful, though the all-caps emphasis adds little structural value.

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

Completeness3/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 values need not be explained, which the description correctly omits. However, with zero annotations and zero field descriptions, the definition is thin on permission requirements, error semantics, and the meaning of most parameters for a stateful persist operation.

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 0%, so the description must compensate and it only partially does, explaining the special 'NE' status binding. The required fields (item_id, claim, proposed_status) and the optional conditions/evidence_ids/model_reported_confidence carry no explanation in either place, though most names are self-evident.

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?

The description states a specific verb pair (validate, persist) and a scope (structural admissibility), and explicitly bounds itself as NOT a semantic adjudicator. Combined with the tool name, an agent can tell this is a validation-and-record step. It does not, however, name or distinguish itself from any sibling tool.

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

Usage Guidelines2/5

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

There is no explicit when-to-use or when-not-to-use guidance and no named alternative among list_sources, find_evidence, run_document_review, or build_evidence_matrix. The clause 'it does not semantically adjudicate the claim' hints at a boundary but never tells the agent when to call this versus a semantic check.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0Oct 18, 2026
- First observedbuild_evidence_matrix
- First observedfind_evidence
- First observedlist_sources
- First observedrun_document_review
- First observedvalidate_evidence_assessment

Deploy Server

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

TDQS

A3.5/5.0

Scored 2026-10-18 08:30 across 5 tools

Disambiguation5/5

Each tool targets a distinct phase of the evidence workflow: source listing, evidence search, document review, assessment validation, and matrix building. The descriptions clarify non-overlapping boundaries, especially around server-derived fields and structural versus semantic validation.

Naming Consistency5/5

All names use a consistent snake_case verb_noun pattern: list_sources, find_evidence, run_document_review, validate_evidence_assessment, build_evidence_matrix. No mixed conventions or vague verbs appear.

Tool Count5/5

Five tools is well-scoped for a specialized evidence-lab server. Each tool has a clear, non-redundant role in the workflow, and the count avoids both thinness and bloat.

Completeness4/5

The surface covers the core evidence lifecycle from listing sources through search, review, validation, and matrix building. Minor gaps exist around source ingestion/management and semantic query execution, though the latter is explicitly deferred in the version notes.

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

FACTRAIL A
io.github.baronsigma
Evidence infrastructure for agents: source-backed company verification and beta import assessment.
Government Data Open Data
71
market-pulse A
io.github.t3ratech
Evidence-graded agent-work lanes, bid advice, live agent jobs and a hash-chained evidence ledger.
Agent Orchestration Research & Data Search
1
SPM
ai.spmos
Agent memory that refuses to guess: evidence-gated recall, exact-source reads, verifiable deletion.
Knowledge & Memory Autonomous Agents RAG Systems
1
Hlido Agent Reviews A
eu.hlido
Independent AI-agent reviews: trust checks, evidence scorecards, incident registry, recommendations.
AI & Machine Learning Security
192

Related MCP Servers

Recommend Agentic Trust Layerofficial
Autonomous Agents AI & Machine Learning Search
recommend-dev
A
license
Not graded
quality
B
maintenance
Enables agents to verify claims with evidence-based truth scores and confidence levels by running a deterministic pipeline of evidence lanes and adversarial checks.
Updated 2 months ago (2026-08-31 13:01 UTC)
26
MIT
aafp-commons
Knowledge & Memory Security
davidnichols-ops
A
license
B
quality
B
maintenance
Enables software agents to maintain a signed, evidence-aware local ledger of claims, with policy-gated proposals, conflict queries, and constitution-pinned access through an MCP stdio server.
Updated a month ago (2026-09-07 21:41 UTC)
7
3
Apache 2.0
utopia-mcp
Knowledge & Memory Databases RAG Systems
txc-link
F
license
Not graded
quality
B
maintenance
Enables agents to query a single-source ontology of types, entities, statements, evidence, and controlled vocabulary, including bitemporal "as of" and "as recorded" fact lookups. Supports writing by letting agents propose candidate statements while keeping approval, review transitions, and authoritative reasoning restricted to approved facts.
Updated a month ago (2026-09-15 10:26 UTC)
-
FOAAP Engine
Knowledge & Memory AI & Machine Learning RAG Systems
imperiobaal69-web
F
license
Not graded
quality
B
maintenance
Enables AI applications to submit claims, decisions, and evidence so it maintains a typed state model of beliefs, conflicts, changes, and next actions, preserving claim lineage and semantic evidence across versioned persistence.
Updated 19 days ago (2026-09-30 22:11 UTC)
-

PADC Evidence Lab v0.1.1.1

Research question and patch status

Epistemic statuses

Declared extraction surface

Trust boundary

Install

Trusted ingestion

MCP tools

Semantic queries

Artifact identity and Missingness idempotence

Audit semantics

Tests

Scope

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Resources

Related MCP Connectors

Related MCP Servers

Recommend Agentic Trust Layerofficial