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

anki-mcp-server

by MeisamHakimi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Open Anki browser

anki_open_browser
Read-only

Open Anki's Browse window filtered by a search query to view matching cards and act on them directly.

Instructions

Open Anki's Browse window filtered by an Anki search, so the user can look at or act on those cards.

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": "anki_open_browser"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and closed-world behavior. The description adds that this opens a visible GUI window on the user's machine, which is useful beyond the annotations, but it says nothing about prerequisites (Anki running), what happens on an invalid query, or whether the previous browser state is replaced.

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?

A single sentence with the action, the filter, and the user benefit, in that order. No filler or repetition of the title.

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?

An output schema exists, so return values need no explanation, and the tool is simple with one parameter. The remaining gap is the undocumented Anki search syntax, which is the one thing an agent must get right to call this successfully.

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 0%, so the description carries the burden. Saying the filter is 'an Anki search' tells the agent the query uses Anki search syntax rather than free text, which is real added meaning, but no syntax examples or field names are given to compensate for the empty 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 — opening Anki's Browse window — and adds the filtering condition and user-facing effect. This clearly separates it from data-returning siblings like anki_find_notes, though it does not name any sibling explicitly.

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 clause 'so the user can look at or act on those cards' implies the usage context: call this when the user should see the cards in the UI. However, it never contrasts with anki_find_notes, the obvious alternative when the agent just needs note data, so the agent must infer the boundary.

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