Verify incoming Quantum ESPRESSO datasets with fail-closed checks, returning PASS/WARN/FAIL/QUARANTINE/NOT_RUN statuses to gate DFT-to-MLIP ingestion.
Run available fail-closed verification over incoming QE outputs.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_path | No | data/incoming |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.0.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Fail-closed' is a useful hint, but the description doesn't say what is checked, what happens on failure, whether it mutates state, or what output is produced. With an output schema present, some return-value explanation is excused, but the verification behavior itself remains opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence with no filler. It is appropriately sized but too sparse to be useful – concision is achieved partly through omission rather than precision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a dataset verification step in a pipeline with several siblings, yet the description omits fail semantics, expected inputs, prerequisites, and where it sits in the pipeline. The output schema may explain results, but the definition is insufficient for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning for dataset_path beyond the schema's own name. It does not state the expected path semantics, whether it accepts directories or file patterns, or what the default 'data/incoming' represents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the tool name ('verify') with vague qualifiers ('available fail-closed verification', 'incoming QE outputs') that an agent cannot action on. It does not state what is verified, what counts as pass/fail, or how it differs from siblings like validate_reference or inspect_dft_dataset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use, when-not-to-use, or alternative guidance is provided. The sibling tools validate_reference and inspect_dft_dataset are obvious alternatives for similar verification/inspection needs, yet the description gives no routing help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.