Skip to main content
Glama
SVerITG

Metis

by SVerITG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Metis — Audit Background Provenance

audit_background_provenance

Identify and record DOI provenance for indexed documents across knowledge layers, checking the local reference library first and optionally querying Crossref for unresolved titles.

Instructions

Where did the documents in the knowledge layers actually come from?

Sweeps `pdf_index_state` and records a DOI for every indexed document it can
identify, so a layer can state its own provenance. Matches against the local
reference library first — that is free and covers most of the corpus — and
only calls Crossref when `resolve_online` is set.

This is the "verify at ingest, trust at read" half of the verification layer.
A corpus of known-real documents makes answer-time checking a containment
problem rather than a truth problem, and the cost is paid once per document
instead of once per claim.

Args:
    layer: Restrict to one layer slug (e.g. 'hat-specialist'); omit for all.
    resolve_online: Also query Crossref by title for documents the local
        library cannot identify. Metadata only; costs one request each.
    limit: Maximum documents to process in one pass (default 400).

Returns:
    Per-layer provenance counts and what changed in this pass.

Input Schema

NameRequiredDescriptionDefault
layerNo
limitNo
resolve_onlineNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

TDQS

A3.7/5.0
Behavior4/5

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

With zero annotations the description carries the full burden, and it does meaningful work: it discloses that the tool writes DOIs into `pdf_index_state`, that local matching is free, that Crossref is gated behind `resolve_online` and costs one request per unresolved document, and that metadata only is fetched. It stops short of stating idempotency on re-runs, failure handling for unmatched documents, or any auth/rate-limit ceiling on the Crossref path.

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?

The concrete mechanism sentence is well front-loaded in the second paragraph, but the description opens with a rhetorical question and spends a full paragraph on philosophy ('a containment problem rather than a truth problem') that an agent does not need in order to invoke the tool. The Args/Returns blocks are efficient, but the rationale prose should be trimmed.

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 and the description still summarizes the return shape (per-layer provenance counts and what changed), parameters are fully covered, and external-call costs are disclosed — enough for correct invocation. Missing is any hint about prerequisites (Crossref credentials, enabled layers) or how this relates to adjacent stats/pending-index tools.

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?

Schema coverage is 0%, so the description must compensate and largely does: `layer` gets a concrete example slug plus the omit-for-all semantics, `resolve_online` gets both behavior and cost, and `limit` gets its default of 400. It does not say how invalid layer slugs behave or how limit interacts with multi-pass runs, so it is strong rather than exhaustive.

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 names a concrete mechanism ('Sweeps `pdf_index_state` and records a DOI for every indexed document') rather than restating the name, so the action and resource are unmistakable. It also positions itself relative to answer-time verification ('verify at ingest, trust at read'), which implicitly separates it from verify_claim/verify_text_citations, but it never names a sibling outright.

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?

Usage is implied through the cost rationale ('paid once per document instead of once per claim') and through the local-first/Crossref-later rule, which tells the agent how to run it cheaply. There is no explicit when-to-use trigger, no when-not-to-use, and no named alternative such as verify_doi, mine_references, or index_pending_layers.

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

Deploy Server

Other Tools