Skip to main content
Glama
ScienceLiveHub

forrt-research-mcp

by ScienceLiveHub
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

verify_chain

Check a published FORRT chain for completeness and consistency: confirm every required step has a resolving URI, cited DOIs resolve, and the CiTO relation matches the outcome verdict.

Instructions

Verify a published FORRT chain. Run this before announcing it anywhere.

Point it at a nanopubs/PUBLISHED.md ledger (or the directory holding one). Read-only: it never edits, retracts or supersedes — a failing row is for a human to act on. green is true only when nothing failed.

What it checks:

  • every required step (01-06) has a URI in the ledger;

  • every URI is really published — present in the constellation, or, for the upstream anchors the walk does not reach, served as RDF by the w3id.org/np/ resolver;

  • the Outcome's repository resolves (a Zenodo version DOI is the expected value — it pins the archived state, where a GitHub URL would be a moving target);

  • every DOI the chain cites resolves;

  • the CiTO relation agrees with the Outcome's verdict — Validated implies confirms, PartiallySupported implies qualifies, Contradicted implies disputes. A mismatch means the Outcome and the Citation disagree about what the replication found, which is the failure most worth catching before anyone reads the chain.

A step reported as "not enumerated by the walk but its TriG resolves" is fine, not a warning: the constellation legitimately stops short of Quote, AIDA and Claim.

mode — auto (default), replication, reproduction or new_research. It changes only what is REQUIRED. Research that starts from scratch has no existing work to cite, so no CiTO step and no cited DOI are expected, and auto infers that from the absence of a published step 06. Everything else is checked identically in all three. Reproduction and replication verify the same way; pass one explicitly only to make the wording match your study.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoauto
repo_urlNo
published_pathYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and delivers: 'Read-only: it never edits, retracts or supersedes — a failing row is for a human to act on.' It also explains the green flag, the CiTO agreement check, and which 'not enumerated' results are warnings vs fine, going well beyond minimal.

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?

Every sentence earns its place, from the front-loaded purpose to the mode caveat at the end. The bulleted check list and bolded key terms make the long content scannable without wasting words.

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?

For a high-complexity tool with no annotations and no output schema, the description is nearly complete: it covers what is checked, what counts as a failure, and mode semantics. It falls just short by not describing the report/return format beyond the green flag and not addressing repo_url.

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. It richly explains published_path (ledger vs directory) and mode (all values, defaults, and effect on required checks), but never mentions the repo_url parameter at all — leaving one of three parameters undocumented.

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?

Opens with 'Verify a published FORRT chain. Run this before announcing it anywhere,' a specific verb and resource that also separates it from draft-oriented siblings like validate_chain_draft. The detailed checks further nail down exactly what 'verify' means in this context.

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?

Gives clear when-to-use: before announcing a chain, pointing at PUBLISHED.md. It explains mode behavior but never explicitly says when not to use it (e.g., drafts should go to validate_chain_draft), so it stops at clear context without exclusions.

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