asset-aware-mcp

Overview Schema Source Related Servers Discussions Admin

evidence

Retrieve and verify citation evidence from PDF assets, render APA/Chicago/Vancouver citations, and capture source references for review.

Instructions

Evidence operations; contract describes citation formats, bundle applies them.

citation_contract accepts a preset selector or named-field inline/reference templates; citation_metadata supplies bibliographic fields, never locators. csl_contract returns the complete hash-paged CSL document schema. render_citations accepts citation_document for document-context APA/Chicago/ Vancouver processing; read every text page at one text_sha256. Optional wiki_root exports an immutable citation snapshot with exact native sources. CSL text_limit is 1..8000 characters; stop paging when next_text_offset is null. inspect_etl_source takes ref={doc_id,source_type,source_id} and returns a full current AssetRef via hash paging. capture_etl_source verifies/captures it in ref. read_etl_source reads the resulting immutable ref; view_etl_source returns its actual original PDF page image. Use the captured ref in CSL sources; source extraction accuracy and semantic support still require Agent review.

Input Schema

TableJSON Schema

Name	Required	Default
`op`	Yes
`ref`	No
`limit`	No
`query`	No
`doc_id`	No
`span_id`	No
`overwrite`	No
`wiki_root`	No
`index_path`	No
`span_kinds`	No
`text_limit`	No
`block_types`	No
`output_path`	No
`render_size`	No
`text_offset`	No
`citation_key`	No
`update_index`	No
`output_format`	No	markdown
`citation_contract`	No
`citation_document`	No
`citation_metadata`	No
`expected_text_sha256`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv1.4.0Sep 20, 2026

addedInput schema / properties / citation_contract

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Citation Contract"
+}

addedInput schema / properties / citation_document

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Citation Document"
+}

addedInput schema / properties / citation_metadata

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Citation Metadata"
+}

addedInput schema / properties / expected_text_sha256

Added value: +{
+  "anyOf": [
+    {
+      "pattern": "^[0-9a-f]{64}$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Expected Text Sha256"
+}

addedInput schema / properties / render_size

Added value: +{
+  "default": 1024,
+  "maximum": 2048,
+  "minimum": 64,
+  "title": "Render Size",
+  "type": "integer"
+}

addedInput schema / properties / text_limit

Added value: +{
+  "default": 4000,
+  "maximum": 8000,
+  "minimum": 1,
+  "title": "Text Limit",
+  "type": "integer"
+}

addedInput schema / properties / text_offset

Added value: +{
+  "default": 0,
+  "minimum": 0,
+  "title": "Text Offset",
+  "type": "integer"
+}

First observedv0.7.0Jun 7, 2026

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 transparency burden and mostly succeeds: it discloses hash-paging, a paging stop condition, the 1..8000 character text limit, immutability of snapshots/refs, and the need for Agent review. It does not fully cover side effects for capture/overwrite or error behavior, which prevents a 5.

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

Conciseness2/5

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

The description is a dense, jargon-heavy block with no bullets, headings, or separation between the different operations, making it difficult to scan. It is information-rich but poorly structured and does not front-load a clear operation list.

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?

For a high-complexity dispatcher with 22 parameters, no annotations, and no output schema, it covers central citation and ETL-source workflows plus useful paging and immutability details. It is still incomplete as an invocation guide because it lacks a formal op enumeration, full parameter mapping, and explicit differentiation from the many sibling tools.

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 coverage is 0%, so the description must compensate, and it does add meaning to ref, text_limit, citation_contract, citation_metadata, citation_document, and wiki_root. But many parameters in the 22-param schema, such as query, span_id, block_types, output_path, render_size, and update_index, remain unexplained in both the schema and the description.

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 identifies a multi-operation evidence tool and enumerates specific suboperations with concrete objects and verbs: citation_contract, csl_contract, render_citations, and the ETL source operations. It is not a tautology, though it never explicitly lists the valid op values or crisply separates itself from the large sibling set.

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

Usage Guidelines3/5

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

It provides workflow guidance, such as stopping paging when next_text_offset is null, capturing before reading/viewing an ETL source, and using the captured ref in CSL sources. However, it does not give explicit when-to-use versus alternatives like find_evidence_spans or verify_citation_ref, and the line 'contract describes citation formats, bundle applies them' is oblique.

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

evidence

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools