Skip to main content
Glama
ScienceLiveHub

forrt-research-mcp

by ScienceLiveHub
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

validate_chain_draft

Validates nanopubs/chain-draft.json for wizard readiness, returning readyForWizard true only when no errors exist. Run after build-chain-draft to catch template, prefill, citation, and required-field issues.

Instructions

Check nanopubs/chain-draft.json before handing it to the chain wizard.

Run this at the end of Phase 5b, after pixi run build-chain-draft and BEFORE pushing the file and opening the wizard URL. readyForWizard is true only when nothing came back as an error.

This file — not the markdown drafts — is what the wizard pre-fills each step from, and therefore what a human reviews and signs. validate_draft checks the authoring input; this checks the artifact.

What it catches that reading the file cannot:

  • a superseded template_uri, which is invisible in the JSON but makes the wizard pre-fill the old form. Re-run build-chain-draft to fix;

  • a prefill key that is neither a template field nor a known platform form-field — the wizard silently drops it;

  • a complex field in the wrong shape: 06_citation.st02 must be [{cites, cited}] with at least one entry, and 04_study.disciplineSelection is a single object, NOT an array;

  • a required field that is neither prefilled nor carried forward;

  • values violating the template's own regex (the Quote's 500-character cap lives there), an invalid vocabulary term, a malformed date, an unresolved {{TOKEN}}, or a DOI that does not resolve;

  • a carry_forward edge that runs backwards through the chain.

Fields the wizard fills itself are exempt, not reported missing: 02_aida has no project, 03_claim no aida, 04_study no claim, because each is carried forward from the step published before it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
liveNo
pathYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A4.2/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 of explaining behavior. It thoroughly discloses what the validator catches, including superseded template URIs, dropped prefill keys, shape violations, regex violations, unresolved tokens, and invalid DOIs. It does not explicitly state whether the operation is read-only or makes network calls, but the 'Check' framing and detailed error semantics provide strong behavioral transparency.

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 front-loaded with a clear purpose sentence and then uses bullets for detailed validation rules. It is longer than average, but the length is justified by the complexity of the validation checks. Slight tightening around repeated 'what it catches' phrasing would improve it, but it remains well structured.

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?

The description provides rich contextual guidance: when to run, what the validator checks, what it does not check, and which fields are exempt. It does not fully describe the return shape beyond the `readyForWizard` flag and 'nothing came back as an error', and it omits parameter semantics. Given the tool's complexity and lack of output schema, this is a minor but real gap.

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%, and the description does not explain the `path` or `live` parameters. It references the default file `nanopubs/chain-draft.json`, which implies what `path` might point to, but `live` is completely undocumented. The description does not compensate for the schema's lack of parameter descriptions.

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?

The description states a specific verb and resource: 'Check `nanopubs/chain-draft.json`'. It also explicitly distinguishes this tool from the sibling validate_draft: 'validate_draft checks the authoring input; this checks the artifact.' This makes the tool's role unambiguous.

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

Usage Guidelines5/5

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

The description gives precise timing: run at the end of Phase 5b, after `pixi run build-chain-draft`, and before pushing the file or opening the wizard URL. It also clarifies when results indicate readiness and explicitly contrasts it with validate_draft, giving an agent clear selection criteria.

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