MCP-AnkiConnect

by samefarrar

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct functionality: adding notes, moving decks, fetching reviews, inspecting cards, searching, storing media, etc. There is no overlap or ambiguity between tools.
Naming Consistency4/5
Most tools follow a verb_noun pattern in snake_case (e.g., add_note, search_notes). One tool (num_cards_due_today) uses 'num' as a prefix instead of a verb, and list_decks_and_notes uses 'and', but overall the pattern is consistent.
Tool Count5/5
14 tools is well-scoped for an Anki integration, covering adding, editing, searching, reviewing, scheduling, and media management without being excessive or too sparse.
Completeness3/5
The tools cover core workflows (add, edit, review, search, inspect) but lack deletion operations (no delete_note or delete_card) and deck/note type creation. These gaps limit full lifecycle management.
Average 4/5 across 14 of 14 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It claims to exclude patterns but no parameters exist, creating ambiguity. No disclosure about potential large data volumes or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise single sentence, but the phrase 'excluding specified patterns' adds confusion without corresponding parameters. It could be more accurate.
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?
With zero parameters and an output schema present, the description covers the basics. The only gap is the unclear 'excluding specified patterns' which is not supported by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, but description introduces a misleading expectation of pattern exclusion. Schema coverage is trivial, and the description doesn't compensate for the missing parameter behavior.
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?
The description clearly states the tool retrieves all decks and note types with fields. It mentions 'excluding specified patterns' which is confusing given no parameters, but overall the purpose is specific and distinct from siblings like search_notes or fetch_due_cards_for_review.
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?
No guidance on when to use this tool versus alternatives. Sibling tools exist for searching or filtering, but the description doesn't help an AI agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. It discloses partial update behavior and auto-conversion of content, but omits potential side effects, validation, or error handling. Provides useful context but lacks depth.
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?
The description is concise at 5 sentences, with main purpose front-loaded. It efficiently covers partial updates, conversion behavior, and parameter descriptions. Minor redundancy could be removed.
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?
Given the output schema exists, return values aren't needed. The description covers core behavior and parameters but lacks information on error conditions (e.g., invalid note_id) or field validation. Adequate but not exhaustive.
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 description must compensate. It provides basic explanations for both parameters (note_id and fields), including that note_id is not a card ID and fields is a mapping. This adds meaning but is minimal; more detail could be given.
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?
The description clearly states it updates text content of fields on a note, using specific verb and resource. It mentions 'update' and 'fields on an existing note', which distinguishes it from sibling tools like update_note_tags, though it does not explicitly differentiate.
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?
The description notes that MathJax and code blocks are auto-converted similarly to add_note, implying a use case, but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. No guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states the basic purpose but does not disclose whether the operation is read-only, has side effects, or any performance considerations. The return format is not described, although an output schema exists.
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?
The description is a single, concise sentence that front-loads the purpose and includes the key optional filter. No unnecessary words.
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?
Given the tool's simplicity (1 parameter, count output), the description covers the basic purpose and filter option. However, it lacks behavioral context (e.g., if it returns 0 for none) and does not leverage the output schema to explain return values. The presence of an output schema mitigates but does not fully compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'deck' has 0% schema description coverage. The description adds that it is an optional filter, but does not specify whether it expects a deck name or ID, or any format details. More information would be beneficial.
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?
The description clearly states the purpose: 'Get the number of cards due exactly today' with an optional deck filter. It uses a specific verb 'get' and resource 'number of cards due today', and distinguishes from sibling tools like 'fetch_due_cards_for_review' that return full cards.
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 description implies usage with the optional deck filter, but does not explicitly state when to use this tool versus alternatives like 'fetch_due_cards_for_review' or 'inspect_cards'. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states 'submit' implying mutation, but lacks details on side effects (e.g., scheduling updates, error handling) or prerequisites (e.g., card existence). This is insufficient for safe tool invocation.
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?
The description is short and front-loaded with a clear purpose sentence. The args are documented in a structured list. No redundant information, but could be slightly more concise (e.g., inline enum values).
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?
The tool has an output schema which may document return values, but the description does not mention what it returns (e.g., success status, count). Additionally, it lacks context on prerequisites (e.g., Anki must be running, card must exist). Given the complexity, more completeness is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by listing each field and its allowed values (card_id integer, rating enum), explaining the ratings. This adds value beyond the raw schema, though further details like required ratings context could improve.
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?
The description clearly specifies the verb 'submit' and the resource 'multiple card reviews to Anki' with explicit rating values. This distinguishes it from sibling tools like 'fetch_due_cards_for_review' which is about fetching, not submission.
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 description implies usage after fetching due cards, but does not explicitly state when to use this tool over alternatives or provide exclusions. No guidance on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It mentions that card_ids are not note IDs, which is a useful behavioral note. However, it does not disclose side effects like whether suspended cards are hidden from reviews or any idempotency guarantees.
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?
The description is extremely concise: one sentence stating purpose, followed by a structured Args list. No wasted words.
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 simple tool with 2 parameters and an output schema (not needing return value explanation), the description adequately covers purpose and parameter semantics. Minor omission: no mention of idempotency or what happens after suspension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by explaining each parameter's role, including the critical clarification that card_ids refer to card IDs, not note IDs. This helps avoid misuse.
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?
The description clearly states the action (suspend or unsuspend) and the resource (one or more cards). It distinguishes from sibling tools that perform different actions like adding notes or fetching due cards.
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?
The description provides no explicit guidance on when to use this tool vs alternatives, nor any prerequisites or exclusions. It only implies usage through the action description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description compensates by detailing behavior for image attachment (three methods, preferred path), code formatting, and MathJax. It explains the picture parameter structure and important preferences. It does not mention side effects like triggering reviews or potential errors, but the coverage is good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured with examples and sections. It front-loads the purpose and then details usage. Some redundancy exists (e.g., repeating the picture structure), but it is organized. It could be more concise without losing clarity.
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?
Given the complexity of the tool (5 parameters, nested objects, no output schema in view), the description is quite complete. It covers all parameters, image handling, formatting, and use conditions. It lacks details on return values, but since an output schema exists (per context), this may be acceptable. Overall, it enables correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains all parameters: deckName and modelName as strings, fields as a dict, tags as optional list, and picture as a list of dicts with detailed sub-fields (filename, url, path, data, fields, skipHash). This adds significant meaning beyond the sparse input schema, which has 0% description coverage.
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?
The description clearly states 'Add a flashcard to Anki', which directly conveys the tool's purpose. The verb 'add' and resource 'flashcard' are specific. However, it does not explicitly differentiate from sibling tools like 'update_note_fields' or 'search_notes', though the action is distinct.
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?
The description instructs users to look at examples and get approval before adding a flashcard, providing clear usage conditions. It also includes detailed guidelines for code and MathJax formatting. However, it does not mention when not to use the tool or suggest alternatives like 'update_note_fields' for modifying existing notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It explains the today_only behavior and output formatting, but lacks statements on read-only nature, side effects, rate limits, or authentication needs.
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?
Concise, front-loaded with main purpose, then clear argument list. Every sentence adds value; no fluff. Placeholder for MAX_FUTURE_DAYS is efficient.
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?
Good coverage of parameter details and output format. However, lacks context on when to use relative to siblings and missing behavioral traits like idempotency or data source, given no annotations and output schema not shown.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, but the description adds detail beyond schema (e.g., deck filter as 'specific deck name', today_only with MAX_FUTURE_DAYS). Only minimal repetition of existing schema descriptions.
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?
The name and description clearly state the tool fetches cards due for review, formatted for LLM presentation. It distinguishes from sibling tools like submit_reviews or inspect_cards by specifying its purpose.
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?
Description implies usage for getting cards to review but does not explicitly state when to use versus alternatives, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description clearly indicates a read-only operation (getting examples). It does not disclose permissions or side effects, but for a retrieval tool, this is acceptable.
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?
The description is well-organized with a brief intro, a bulleted list of sampling techniques, and an args section. It is efficient but could be slightly more concise by removing redundant wording.
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?
Given the tool's complexity (3 parameters, no annotations, output schema exists), the description adequately covers purpose and parameter details. It does not discuss return format, but the output schema likely handles that.
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?
The description adds significant meaning beyond the schema: it explains the purpose of each parameter (deck as exact name, limit as maximum, sample with detailed technique definitions). Schema coverage is only 33%, so the description fully compensates.
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?
The description clearly states 'Get example notes from Anki to guide your flashcard making', specifying the action and resource. It distinguishes from sibling tools like search_notes by focusing on high-quality examples.
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 description explains parameters and sampling techniques but does not explicitly state when to use this tool versus alternatives like search_notes. Usage context is implied but lacks explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the basic behavior (add/remove tags) and constraints, but lacks details on what happens if a tag already exists or doesn't exist, error handling, or idempotency. Without annotations, the description should cover more behavioral aspects.
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?
The description is concise with two short paragraphs, front-loaded with the purpose. The arguments section is clear and every sentence serves a purpose without redundancy.
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 simple tool with 3 parameters and an output schema, the description covers constraints and parameter semantics well. Minor gaps include error scenarios and idempotency, but overall it's adequate for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to each parameter: 'note_ids' are IDs to modify, 'add' tags must not contain spaces, and 'remove' tags to remove. Since schema coverage is 0%, this compensates well, though it could mention expected formats.
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?
The description clearly states the tool adds and/or removes tags on one or more notes. It specifies the exact action (update tags) and resource (notes), distinguishing it from sibling tools like update_note_fields which handle other fields.
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?
The description provides clear constraints: tags must not appear in both 'add' and 'remove', and at least one list must be non-empty. It does not explicitly mention when not to use this tool or alternatives, but the context of siblings implies this is the go-to for tag modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains the tool reads from disk, downloads from URL, or decodes base64. It specifies exactly one of url/data/path must be provided. It doesn't detail error handling but covers core behavior well.
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?
The description is well-structured with bullet points and clear sections, though slightly verbose. It front-loads purpose and usage, then dives into parameter details. Every sentence adds value.
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?
Given 4 parameters (1 required) and an output schema, the description covers usage scenarios and parameter selection adequately. Return value is not explained but output schema exists. The description is complete for typical use cases.
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 description coverage is 0%, so the description adds crucial meaning: explains each parameter's role, preferred use cases (path for user files, data for small images), and the constraint of providing exactly one. This fully compensates for the schema's lack of descriptions.
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?
The description clearly states the tool stores an image or media file in Anki's media folder for use in flashcards via HTML img tags. It distinguishes itself from sibling tools like add_note or update_note_fields by focusing on media storage.
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?
The description provides when to use the tool (before creating a note, adding to existing cards) and detailed guidance on which parameter to use (path preferred for user-shared files, data for small images). It does not explicitly state when not to use it but gives clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the effects of each mode (e.g., forget resets to new queue, relearn moves to relearning queue) but does not mention potential side effects or permissions.
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?
The description is concise and well-structured, front-loading the purpose and using clear formatting for modes and args without any unnecessary information.
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?
The description covers all parameters and modes effectively. Given the existence of an output schema, return values need not be explained. However, it could provide more context on when to choose each mode.
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?
Despite 0% schema description coverage, the description explains all three parameters in detail, especially the due format spec, which adds significant meaning beyond the schema's type definitions.
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?
The description clearly states the tool manipulates scheduling state of cards, with specific modes (set_due, forget, relearn) that distinguish it from sibling tools like add_note or change_deck.
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?
The description provides detailed guidance on modes and the due format, but does not explicitly compare to sibling tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are present, the description discloses a key behavioral trait: the tool is card-scoped and does not silently expand notes into cards. It references the underlying AnkiConnect function. However, it lacks details on side effects like scheduling changes or permissions, which would be needed for full transparency.
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?
The description is concise, with a clear purpose sentence followed by a necessary caveat and structured argument list. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with an output schema presumably handling return values, the description completely covers what the tool does, its scope, and how to prepare inputs. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by clearly defining both parameters: card_ids as card IDs to move, and deck with an example hierarchical name. It adds context about card vs note IDs, aiding correct usage.
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?
The description explicitly states it moves cards into a different deck, specifies it operates on card IDs, and contrasts with note-level operations. This clearly distinguishes it from siblings like add_note and inspect_cards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance: use card IDs, and if only note IDs are available, first call inspect_cards. It explains the rationale (cards from a note can be in different decks) and implicitly warns against misuse. This is excellent usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details extra API calls for history and fields, soft-deprecated alias behavior, and note collapse for Image Occlusion. It implicitly indicates read-only nature. No contradictions.
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?
The description is well-structured with a purpose statement, constraints, and a bulleted list of property categories. It is slightly lengthy but each part serves a purpose. Front-loaded with key constraint. Good balance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with 0% schema coverage, 13 sibling tools, and an output schema, the description covers all necessary aspects: parameter constraints, defaults, property explanations, behavior for note_ids, and deprecated alias. It does not need to explain return values due to output schema. Complete.
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 description must compensate. It explains each parameter: exclusive usage of card_ids/note_ids, expansion with note_ids, property categories with explicit list and meanings, and include_history as alias. This adds significant value beyond the bare schema.
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?
The description clearly states the tool's purpose: 'Inspect per-card state with sparse fieldset selection.' The verb 'inspect' and resource 'per-card state' are specific. The sibling tools include mutations like add_note and search_notes, making this read-only inspection distinct.
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?
The description provides clear usage guidelines: 'Provide EXACTLY ONE of card_ids or note_ids' and explains how note_ids resolves to cards. It defaults properties and notes a deprecated alias. However, it lacks explicit exclusion of alternatives (e.g., when to use search_notes instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that results include note IDs for follow-up actions, describes the difference between return_card_content=false (preview) and true (full fields), and references inspect_cards for state details. However, it does not mention any potential limitations on query complexity or rate limits, though as a search tool, destructive behavior is not expected.
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?
The description is thorough but well-structured with clear sections: an overview, tiered access guidance, and a comprehensive search pattern reference. It is front-loaded with key usage instructions. The length is justified by the complexity of the query syntax, but some redundancy could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description fully covers input parameters (with examples), output format (referenced to output schema), and usage scenarios. It provides a complete guide for the agent to use the tool effectively, including boundaries for when to switch to sibling tools.
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 100% (all parameters documented in schema). The description adds significant meaning: it explains the query parameter with dozens of search pattern examples, clarifies the limit default and range, and elaborates on the return_card_content parameter's effect on output.
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?
The description clearly states it's for searching notes in Anki using a built-in search syntax. It specifies the verb 'search' and the resource 'notes', and distinguishes itself from sibling tools like inspect_cards by explaining when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on tiered access: using the tool with default parameters for cheap preview, then drilling into specific IDs, and when to call inspect_cards for scheduling details. Also includes extensive search pattern examples, making it clear when to use different query constructs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-ankiconnect MCP server](https://glama.ai/mcp/servers/samefarrar/mcp-ankiconnect/badges/card.svg)](https://glama.ai/mcp/servers/samefarrar/mcp-ankiconnect)

Score Badge

Copy to your README.md:

[![mcp-ankiconnect MCP server](https://glama.ai/mcp/servers/samefarrar/mcp-ankiconnect/badges/score.svg)](https://glama.ai/mcp/servers/samefarrar/mcp-ankiconnect)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/samefarrar/mcp-ankiconnect'

If you have feedback or need assistance with the MCP directory API, please join our Discord server