Skip to main content
Glama
Sign In
ScienceLiveHub

forrt-research-mcp

by ScienceLiveHub
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

validate_rocrate

Verify your RO-Crate for compliance and FAIR readiness before deposition. Check the structure against RO-Crate specifications and ensure all necessary Digital Object requirements are met.

Instructions

Check an RO-Crate before it is released or deposited (e.g. in ROHub).

path is the crate's directory (usually the repository root) or its ro-crate-metadata.json. Run it after pixi run -e rocrate build-rocrate and before deposit-rohub; it is the same check the template's CI runs.

Two layers:

  • passed/issues: rocrate-validator against profile (default ro-crate-1.2) at level (REQUIRED, RECOMMENDED or OPTIONAL). Each issue names the check, its message and the offending entity — relay them verbatim. metadata_only=True skips the checks that the listed files exist (for a crate whose data are not checked out). The first run fetches the RO-Crate JSON-LD context (then cached); offline=True needs that cache.

  • fdo_checks/fdo_ready: what a replication crate needs beyond the specification to work as a FAIR Digital Object — a persistent identifier, a licence, the workflow as mainEntity, a community FAIR Implementation Profile in conformsTo, the FORRT chain in subjectOf, and no ro-crate-metadata.json among its parts (ROHub reserves that name). Advisory: they do not change passed; each failing check says how to fix it.

Never hand-edit ro-crate-metadata.json to make it pass: it is generated by scripts/build_rocrate.py — fix the source (CITATION.cff, the ledger, rocrate.json) and rebuild.

Input Schema

NameRequiredDescriptionDefault
pathYes
levelNoREQUIRED
offlineNo
profileNoro-crate-1.2
metadata_onlyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.0

TDQS

A4.9/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 does so: it explains the two layers, clarifies that `fdo_checks` are advisory and do not affect `passed`, warns that the first run fetches the RO-Crate JSON-LD context (cached thereafter) and `offline=True` needs that cache. It also tells the agent to relay issue messages verbatim, which is real operational guidance.

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?

Front-loaded with the purpose and the path semantics, then structured into two labelled layers plus a closing caution. It is longer than typical but nearly all content is load-bearing; only the nested bullet density slightly slows scanning.

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

Completeness5/5

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

No output schema exists, and the description explains the return values (`passed`/`issues` with check name, message and offending entity; `fdo_checks`/`fdo_ready` with per-check remediation hints). For a five-parameter validation tool this is complete enough to invoke and interpret correctly.

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

Parameters5/5

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

Schema coverage is 0% — bare titles only — so the description must compensate, and it covers every parameter: `path` (directory or the metadata JSON file), `profile` (default ro-crate-1.2), `level` (REQUIRED/RECOMMENDED/OPTIONAL), `metadata_only` (skips file-existence checks), and `offline` (requires the cached context). Nothing is left 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?

States a specific verb and resource ('Check an RO-Crate') plus its purpose ('before it is released or deposited'). This is clearly distinguishable from the generic validate_draft/validate_drafts siblings, which the description implicitly separates by scoping to RO-Crate structure and FDO readiness.

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?

Gives explicit lifecycle placement: run after `pixi run -e rocrate build-rocrate` and before `deposit-rohub`, noting it is the same check the template's CI runs. It also states the escape hatch (`metadata_only=True` for crates without data checked out) and the constraint that generated metadata must not be hand-edited.

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