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

anki-connect-mcp

by SolarianGG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

reviews.list

reviews_list
Read-only

Read Anki review history by ascending review ID, filtered by card IDs or deck, with cursor and after-ID pagination for audits or incremental syncs.

Instructions

Read review history ordered by ascending review ID.

cardIds and deck are mutually exclusive. No selector means all history. afterId is exclusive. Current/home membership is explicit for filtered cards.

Anki-Connect method reviews.list. Scope: collection. Effect: read. Completion: completed. Undo: none.

Possible errors: collectionUnavailable, internalError, invalidParams, notFound, staleCursor, staleSession.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "reviews_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
deckNoOnly reviews of cards in this deck: exactly one of {"id": "<deckId>"} or {"name": "<full deck name, e.g. Japanese::Verbs>"}. Mutually exclusive with `cardIds`.
limitNoPage size, 1–1000 (default 100).
cursorNoContinuation token: `nextCursor` from the previous page of the same call. Omit for the first page. Repeat the same query, sort and limit; each cursor is single-use and expires after 10 minutes. `nextCursor: null` means there are no more pages.
afterIdNoOnly reviews with an ID greater than this one (exclusive), e.g. the latest ID you already have.
cardIdsNoOnly reviews of these cards (decimal string, e.g. "1700000000001"). Mutually exclusive with `deck`; with neither, all history.
sessionNoOptional. Collection session ID: the `session` field returned by `collection_get`. Usually omit it — the server then uses the session current at the time of the call. Pass it to make the call fail with `staleSession` instead of acting on a different profile/collection than the one your IDs, cursors and tokens came from.
membershipNoHow `deck` is matched for cards in filtered decks: `current` = the deck the card is in now, `home` = its original (home) deck. Default `current`.current
includeManualNoInclude manual entries (rescheduling, resets), not only answers. Default true.
includeChildrenNoInclude subdecks of `deck`. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, and the description still adds real behavior: cursor is single-use with a 10-minute expiry, staleSession lets the caller force a failure instead of reading a different collection, and an explicit error enumeration. The "Scope/Effect/Undo" lines partly restate the annotations, which keeps this below a 5.

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 operation, then scoping rules, then the pagination and error contract; sentences are short and purposeful. The template-style metadata block ("Scope: collection. Effect: read. Completion: completed. Undo: none.") is low-information filler against the annotations.

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

Completeness3/5

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

Pagination, session safety and error modes are well covered for a 9-parameter read tool. However, there is no output schema, and the description never says what a review record contains (fields, shape of the returned page, nextCursor placement), so an agent cannot anticipate the result payload.

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 coverage is 100%, so all nine parameters are already documented in detail, including mutual exclusivity and cursor semantics. The description adds only the useful default case ("No selector means all history") and reinforces afterId exclusivity, most of which the schema already carries.

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 plus ordering semantics: "Read review history ordered by ascending review ID." That is enough to separate it from reviews_getLatestId and statistics_* siblings without opening any schema.

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 concrete selection rules: cardIds and deck are mutually exclusive, and "No selector means all history"; includeManual/includeChildren and membership are described in the schema. It never names a competing sibling tool or says when to prefer reviews_getLatestId or statistics endpoints, so the routing guidance is clear but not complete.

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