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

anki-workflow-mcp

by Gugart43
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Pipeline Phase Advance

pipeline_phase_advance

Advance an Anki deck batch through the pipeline state machine by verifying the required gate-check PASS receipt and permitted transition.

Instructions

Advance a batch through the pipeline state machine. deck_dir: absolute path to the deck folder. batch_id: e.g. 'B07'. Leaving a phase requires the receipt recorded by a PASS of pipeline_gate_check(phase=). receipt_hash is optional; if given it must equal that recorded receipt. Allowed transitions: started→drafted→curated→enriched→illustrated→validated→exported.

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": {
      "deck_dir": "<deck_dir>",
      "batch_id": "<batch_id>"
    },
    "name": "pipeline_phase_advance"
  }
}

Input Schema

NameRequiredDescriptionDefault
batch_idYes
deck_dirYes
receipt_hashNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses the state-machine constraint, the prerequisite gate receipt, and that a supplied receipt_hash must match the recorded receipt. It omits failure behavior for disallowed transitions and whether the advance is reversible, leaving some behavioral gaps.

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?

Front-loads the action, then gives parameter semantics, then the transition chain — each fragment earns its place with no redundant prose. The telegraphic 'name: meaning' format is easy to scan.

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 state-machine mutation tool, it covers prerequisites, legal transitions, and all parameters; the existing output schema removes the need to describe return values. What's missing is error/rollback behavior when the receipt is absent or mismatched.

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%, so the description must compensate, and it does: deck_dir is specified as an absolute path to the deck folder, batch_id gets a concrete example ('B07'), and receipt_hash is explained as optional with a matching constraint. All three parameters gain meaning not present in the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Advance a batch through the pipeline state machine') and implicitly separates itself from pipeline_gate_check by describing that tool as the gate that must PASS first. It stops short of explicitly contrasting itself with other batch-mutating siblings, but the purpose is unambiguous.

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 a clear precondition for use: leaving a phase requires the receipt recorded by a PASS of pipeline_gate_check(phase=<current state>). The allowed transition chain further tells the agent when the call is legal. No explicit alternates or 'do not use when' guidance is offered.

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