Skip to main content
Glama
Sign In
sameerbajaj

AnkiWeb MCP

by sameerbajaj
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Remote

teach_playbook

Records a CLI playbook and free-text notes for a query family so you can reuse repeatable steps and capture gotchas or workarounds.

Instructions

Record a CLI playbook + free-text notes for a query family

Input Schema

NameRequiredDescriptionDefault
csvNoOutput as CSV (table and array responses) (default: false)
yesNoSkip confirmation prompts (explicit confirmation for scripts) (default: false)
jsonNoOutput as JSON (default: false)
agentNoSet agent-friendly output defaults (--json --compact --no-input --no-color) (default: false)
notesNoFree-text notes (gotchas, workarounds) -- mutually exclusive with --notes-file
plainNoOutput as plain tab-separated text (default: false)
queryNoExample query that anchors the family (required)
quietNoBare output, one value per line (default: false)
selectNoComma-separated fields to include in output (e.g. --select id,notetype_id,deck_id)
compactNoReturn only key fields (id, name, status, timestamps) for minimal token usage (default: false)
dry-runNoShow request without sending (default: false)
max-ageNoMaximum acceptable age of local-store data before a stderr hint suggests sync; 0 disables (default: 30m0s)
receiptNoWrite an atomic private run receipt (default: false)
timeoutNoRequest timeout (default: 1m0s)
no-cacheNoBypass response cache (default: false)
no-colorNoDisable colored output (default: false)
no-inputNoDisable all interactive prompts (for CI/agents) (default: false)
no-learnNoDisable the teach/recall learning loop for this invocation (default: false)
idempotentNoTreat already-existing create results as a successful no-op (default: false)
notes-fileNoPath to a markdown file with the notes
rate-limitNoMax requests per second (0 to disable; default auto — pace to server rate-limit headers) (default: auto)
data-sourceNoData source for read commands: auto (live with local fallback), live (API only), local (synced data only) (default: auto)
playbook-fileNoPath to a JSON file with the playbook (steps, entity_slots, expected_tool_calls)
playbook-jsonNoInline playbook JSON (steps, entity_slots, expected_tool_calls) -- mutually exclusive with --playbook-file
client-profileNoSelect the tenant-gated client profile (env: ANKIWEB_CLIENT_PROFILE)
human-friendlyNoEnable colored output and rich formatting (default: false)
allow-partial-failureNoDowngrade response-body partial-failure (e.g. partialFailureError) to a warning instead of a non-zero exit (default: false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=false, so the agent knows this is a non-idempotent local write. The description adds nothing beyond repeating the name: it does not say whether the playbook is persisted, deduplicated, validated, or how it interacts with the teach/recall loop implied by the no-learn parameter. Given zero additional context, this is a thin disclosure.

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?

A single well-formed sentence with zero waste, and the write action is front-loaded. It is efficient, though arguably too sparse given the 27-parameter surface.

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

Completeness2/5

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

For a complex write tool with 27 parameters, no output schema, and non-idempotent/non-destructive annotations, the description omits too much: return behavior, persistence, interaction with the learning loop, and whether re-recording overwrites. The schema covers parameters, but the description leaves key behavioral gaps an agent needs.

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 100%, so every one of the 27 parameters is already documented in the schema (including mutually exclusive notes/notes-file and playbook-file/playbook-json). The description adds no guidance on usage of these parameters, so it is purely at the baseline level relative to the 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 (Record), resources (a CLI playbook + free-text notes), and scope (a query family). An agent can infer the tool writes reusable knowledge rather than reading it. It does not distinguish itself from nearby siblings like teach, teach_pattern, or playbook_amend, so it stops short of a 5.

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

Usage Guidelines2/5

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

There is no indication of when to use this versus teach, teach_lookup, teach_pattern, or playbook_amend, nor any prerequisites. The usage context is only inferred from the name and the single sentence. No exclusions or alternatives are named.

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