Skip to main content
Glama
Sign In
anki-workflow-mcp

anki-workflow-mcp

by Gugart43
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Validate Batch

validate_batch

Run every export-validator check over a QA CSV and Cloze CSV pair to return a PASS, INCOMPLETE, or FAIL verdict, catching structural, image, taxonomy, and cross-reference errors before notes are compiled.

Instructions

Full batch validation: runs every export-validator check over a complete QA CSV + Cloze CSV pair. Returns a ValidationReport with a verdict: PASS (content_hash = receipt), INCOMPLETE (some check could not run; see skipped; no receipt) or FAIL, plus read-only information_profiles (3-layer profile per row with note_type and row; excluded from receipt hash; length-only signals are advisory WARN). taxonomy_tags: space-separated registered tags. active_ids / current_batch_ids: comma-separated. catalog_filenames: comma-separated namespaced image filenames (needed to verify sources; without it, image-bearing rows are reported as skipped).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "batch_id": "<batch_id>",
      "qa_csv": "<qa_csv>",
      "cloze_csv": "<cloze_csv>"
    },
    "name": "validate_batch"
  }
}

Input Schema

NameRequiredDescriptionDefault
qa_csvYes
batch_idYes
cloze_csvYes
active_idsNo
taxonomy_tagsNo
max_notes_lengthNo
catalog_filenamesNo
current_batch_idsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A3.9/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 and does so well: it defines the three verdict outcomes (PASS/INCOMPLETE/FAIL), explains what INCOMPLETE means (a skipped check, no receipt), and notes that information_profiles are excluded from the receipt hash and that length-only signals are advisory WARN. It does not explicitly state that the operation is read-only/non-mutating, which is the main remaining gap.

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 core action and the return contract, and every clause about verdicts and receipts earns its place. It is dense and semicolon-chained, though, mixing return semantics and parameter formatting into one paragraph, which slightly hurts scanability.

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 complex multi-check validator with an output schema present, the description supplies the outcome semantics an agent needs to interpret results without re-reading the schema. The notable omission is max_notes_length, whose effect on validation is never described.

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

Parameters3/5

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

Schema description coverage is 0% across 8 parameters, so the description must compensate; it explains taxonomy_tags (space-separated registered tags), active_ids/current_batch_ids (comma-separated) and catalog_filenames (comma-separated namespaced image filenames, with the consequence of omitting it). qa_csv, cloze_csv, batch_id and especially max_notes_length remain unexplained, leaving half the surface 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: 'runs every export-validator check over a complete QA CSV + Cloze CSV pair'. That scope clearly distinguishes it from the narrower siblings such as validate_qa, validate_cloze and validate_crossrefs, and it names the returned artifact (ValidationReport).

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?

The word 'Full' and the phrase 'every export-validator check' imply this is the aggregate validator to run instead of the individual check tools, and one conditional (catalog_filenames needed for <img> verification) is given. However, no sibling is named and there is no explicit when-not-to-use guidance, so the routing must be inferred.

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