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

anki-connect-mcp

by SolarianGG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

cards.search

cards_search
Read-only

Find Anki cards with Anki search syntax, such as deck and due filters, and page through results using a cursor.

Instructions

Search cards using Anki search syntax.

Anki-Connect method cards.search. Scope: collection. Effect: read. Completion: completed. Undo: none.

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

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": {
      "query": "<query>"
    },
    "name": "cards_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
sortNoOptional browser-column sort, e.g. {"column": "noteFld", "direction": "ascending"} (`column` is an Anki browser column key such as noteFld, cardDue). Default: ascending ID order.
limitNoPage size, 1–1000 (default 100).
queryYesAnki search query for cards, e.g. `deck:Japanese is:due`. An empty string matches all cards.
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.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already cover readOnly/non-destructive/openWorld, but the description adds real value beyond them: collection scope, undo: none, completion state, and a concrete error catalog including staleCursor and staleSession, which tells the agent how pagination and session pinning can fail. It does not describe the shape or size of what is returned, which is a remaining gap given there is no output schema.

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?

Two compact blocks: the purpose sentence first, then a tightly packed metadata line covering scope, effect, completion, undo, and errors. No filler, and the most decision-relevant information is front-loaded; the error list is terse to the point of being a bare enumeration.

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?

For a 5-parameter paginated search with a nested sort object and no output schema, the description never says what a result page contains (card IDs vs full cards) or how results relate to nextCursor, leaving the agent to infer the return shape. Parameter and error behavior are otherwise well covered by the schema and metadata line.

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%, and the schema already explains sort, limit, cursor single-use/expiry, and session semantics in detail. The description contributes only "Anki search syntax" and the collection scope, adding little meaning beyond the structured fields, so the baseline of 3 applies.

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 ("Search cards") plus the query dialect ("Anki search syntax"), which lets an agent distinguish it from siblings like notes_search or cards_get. It stops short of naming the nearest alternative (notes_search) explicitly, so the differentiation is implicit rather than spelled out.

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?

Usage is implied by "Scope: collection. Effect: read." and by the sibling naming pattern, but there is no explicit when-to-use guidance, no statement of when to prefer notes_search or cards_getMany, and no prerequisites. Adequate context, no routing advice.

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