anki-mcp

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action, from connection checking to note updates. The only near-overlap is add_note vs add_notes, but their batch semantics are clear from names and descriptions. All other tools are unambiguously separated.
Naming Consistency5/5
All tools share the 'anki_' prefix and use snake_case with a verb_noun structure (e.g., list_decks, add_note, get_notes_info). The sole deviation is anki_sync, which is a single verb but still follows the same prefix and case convention.
Tool Count5/5
11 tools is a well-scoped set for an Anki MCP server, covering connection health, sync, deck and model introspection, note creation (single and batch), search, retrieval, and field updates. Each tool earns its place without redundancy.
Completeness4/5
The set covers the core note lifecycle well: create, read, search, and update fields. Minor gaps exist—no delete for notes or decks, and no model creation—but these can be worked around via Anki's GUI, making the surface largely complete for typical flashcard workflows.
Average 4.4/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate it is not read-only and not destructive. The description adds the idempotent behavior—'if it does not already exist'—which is a valuable behavioral trait beyond what annotations provide. This explains the no-op case, enhancing 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 a single, concise sentence that is front-loaded with the action. Every word earns its place, with no 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 tool is simple, and the schema plus annotations already provide comprehensive details on parameters and safety. The description covers the core function and idempotency, making it complete enough for its complexity. No major gaps exist.
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?
The schema description coverage is 100%, so both parameters (deck and response_format) are fully documented in the schema. The description adds no additional parameter semantics, so a baseline score of 3 is appropriate.
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 creates a deck, with a crucial qualifier 'if it does not already exist.' This distinguishes it from sibling tools like anki_list_decks (list) and anki_add_note (add note), making the purpose unambiguous.
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 for deck creation but does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions or context about when not to use it. The usage context is clear but not explicitly differentiated from sibling tools.
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 annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate that the operation is safe. It adds meaningful behavioral context by explaining how nested decks are returned (using `::` separator) and providing an example, which is valuable beyond the annotations.
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 two sentences: a clear statement of purpose followed by a concrete example of nested deck formatting. It is front-loaded with the main verb and resource, and every word contributes to understanding. No redundancy or fluff.
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 simplicity of the tool (1 optional parameter, existing output schema, read-only annotations), the description adequately covers the core behavior and the important detail of nested deck separation. It does not explain return values, but the output schema handles that. The description is complete enough for an agent to use the tool correctly.
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% for the single parameter 'response_format', which includes an enum and explanation. The tool description does not add any extra meaning for this parameter, so the baseline of 3 is appropriate—the schema already carries the full semantic load.
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 'List every deck in the collection' with a specific verb and resource, clearly distinguishing it from sibling tools like anki_create_deck or anki_list_models. The additional detail about nested decks using `::` reinforces the exact scope of the operation.
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 clearly indicates when to use this tool: whenever you need to list all decks. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous and the note about nested deck naming helps the user understand the output format. This aligns with 'clear context, no exclusions.'
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?
Annotations only indicate read/write and non-destructive hints, so the description carries the burden of behavioral disclosure. It adds critical context that field values are HTML sent verbatim without escaping, that cloze syntax is inert on 'Basic' notes, and that by default Anki refuses duplicate first fields. This goes well beyond the annotations and discloses non-obvious traits.
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 moderately long but every sentence contributes meaningful guidance. The bold warning about HTML escaping is front-loaded, and the code example effectively illustrates usage, though a shorter example could reduce length. It is well-structured and not redundant.
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 output schema covers return values, the description focuses on the action, prerequisites, and edge cases. It explains the primary functionality, HTML behavior, cloze constraints, and duplicate handling. It does not discuss errors or the response_format parameter, but those are covered by the schema and output schema, making it sufficiently complete.
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 input schema covers all parameters with detailed descriptions, so the baseline is 3. The description adds value by clarifying the verbatim HTML rule and demonstrating proper field formatting with an example, which is not fully captured in the schema's brief 'HTML content' description. It does not repeat the schema's parameter explanations.
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 opens with 'Add a single note to a deck', which is a specific verb and resource. It distinguishes from the sibling 'anki_add_notes' through the word 'single', and provides additional context about HTML verbatim and cloze deletions, making the tool's purpose unmistakable.
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 gives clear prerequisites: the deck must be created first with `anki_create_deck`, field names must match the model checked via `anki_get_model_fields`, and cloze syntax requires a cloze-type model. It does not explicitly mention using `anki_add_notes` for multiple notes, but the singular 'single note' implies the distinction, and the prerequisites serve as strong guidance.
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?
Annotations declare readOnlyHint and openWorldHint, so safety is covered. The description adds valuable behavioral context beyond annotations: field names are case-sensitive and space-sensitive (with a concrete example), and ordering follows template order. This helps the agent use the output correctly.
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 two sentences: the first states the primary purpose and scope, the second adds crucial formatting details. No unnecessary words or repetition.
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?
The tool is simple, has a full output schema, and annotations covering its read-only, open-world nature. The description covers the core purpose and the most important behavioral nuance (key format) for downstream use. Nothing essential is missing.
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% with both parameters described in detail, including an enum for response_format. The description does not add parameter-specific meaning beyond the schema; the baseline of 3 is appropriate.
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 uses the specific verb 'List' with the resource 'a note type's field names' and adds the scope qualifier 'in template order'. This clearly distinguishes it from siblings like anki_list_models (which lists note types themselves).
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 says these are the exact keys anki_add_note expects, giving a concrete use case and context. It does not explicitly name alternatives or exclusion criteria, but the purpose is clear enough to guide selection among siblings.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds value by clarifying the scope ('every note type') and providing concrete built-in examples, which helps set expectations about the return values. No contradictions with annotations.
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 exactly three sentences, with the core purpose front-loaded in the first sentence. Every sentence earns its place: the second gives examples, the third provides a next-step pointer. No wasted words.
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 read-only listing tool with an output schema and clear annotations, the description is complete. It not only states what the tool does but also situates it in a workflow by recommending anki_get_model_fields next, giving the agent enough context to chain tools correctly.
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% for the single parameter (response_format), and the schema fully documents its enum values and default. The description adds no parameter-specific details, so the baseline of 3 applies; the schema does the heavy lifting.
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 'List every note type (model) in the collection' with a specific verb and resource scope, and provides examples of typical built-ins. It distinguishes itself from sibling tools like anki_list_decks by explicitly focusing on models/note types rather than decks.
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 gives explicit guidance on when to use this tool: before adding a note, recommending to follow up with anki_get_model_fields to learn field names. It implies the use case (listing available models) without explicit alternatives or exclusions, but the workflow context is clear.
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?
Annotations already indicate a write operation (readOnlyHint=false) and non-destructive behavior (destructiveHint=false). The description adds critical behavioral guidance: field values are HTML and must be sent verbatim without escaping, and all notes share a single deck/type. This provides meaningful context beyond the annotations.
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: the first sentence states the core purpose, and the second paragraph delivers a crucial HTML warning plus a reference to conventions. Every sentence serves a purpose with no filler.
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 full schema coverage, an output schema, and annotations, the description sufficiently covers batch behavior, shared deck/type constraints, and the HTML verbatim rule. It lacks explicit discussion of partial failure or error handling, but this is not critical for effective selection and invocation.
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 100% for all 6 parameters, so baseline is 3. The description enhances understanding by warning that field values are HTML and sent verbatim, which is not in the schema, and by pointing to anki_add_note for per-item conventions. This adds practical meaning to the parameters.
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 function: 'Add several notes at once, sharing one deck and note type.' It uses a specific verb and resource, and the emphasis on 'several notes at once' differentiates it from the sibling anki_add_note.
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?
It implies batch usage ('several notes at once') and directs the agent to anki_add_note for field/cloze conventions, which serves as a useful reference. However, it does not explicitly state when to prefer this tool over the single-note sibling or provide exclusion criteria.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds value beyond annotations by explicitly stating the output shape ('Returns ids only') and providing search syntax examples, which clarify expected behavior without contradicting the annotations.
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 efficiently structured: a one-sentence summary followed by a well-formatted code block of examples. Every line is informative and contributes to understanding the query syntax. There is no redundant or vague wording, making it appropriately sized for the complexity.
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 tool has an output schema, so return values are already documented. The description covers the tool's purpose, query syntax, and the relationship to `anki_get_notes_info`. It lacks only minor details like error handling or result ordering, but these are not essential given the output schema and annotations.
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 input schema has 100% coverage with descriptions for both parameters, so the baseline is 3. The description enriches the `query` parameter by providing numerous examples of Anki search syntax (deck:, tag:, note:, wildcard, etc.), which go beyond the schema's single-line definition. No additional info on `response_format` is needed since the schema already explains it.
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 opens with 'Find note ids matching an Anki search query', which is a specific verb+resource+query structure. It clearly distinguishes itself from sibling tools by stating 'Returns ids only — pass them to `anki_get_notes_info` to see the actual content', which differentiates it from the note-fetching sibling.
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 context on when to use the tool ('Uses Anki's own search syntax, the same one as the browser's search bar') and gives a direct pointer to a sibling tool for the next step ('pass them to `anki_get_notes_info`'). It does not explicitly list when not to use the tool, but the search syntax and workflow make it evident.
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?
Even with readOnlyHint=true and openWorldHint=true, the description adds meaningful behavior: unknown IDs return empty entries rather than errors, field values are raw HTML, and markdown output truncates values unless response_format='json'. These are concrete details not present in the annotations.
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?
Three sentences, each with a distinct job: the first states the purpose, the second covers return values and the unknown-ID edge case, and the third explains output truncation. No filler or redundant phrasing.
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 output schema exists and annotations are present, the description fully covers the tool's behavior: it states inputs, outputs, edge cases, and formatting options. There are no significant gaps for an agent to be misled.
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 the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides — it only references response_format in a context that the schema already covers. No extra meaning is added.
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 opens with 'Fetch full details for the given note ids' — a specific verb and resource — then enumerates exactly what details are returned (model, tags, field contents as HTML, card IDs). This sets it apart from sibling tools like anki_find_notes (which finds IDs) and anki_get_model_fields (which gets a model's 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 makes it clear this is used when you already have note IDs and want their full details, especially given the schema note that IDs 'typically come from anki_find_notes.' However, it does not explicitly name alternative tools or state when NOT to use this tool, so it stops short of a full 5.
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?
Annotations already declare readOnlyHint=true, so the safe-read nature is known. The description adds the exact return value (API version 6) and the behavioral distinction between two failure modes. This goes beyond annotations with useful context.
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?
Three short sentences, each with a specific purpose: state the check, give usage guidance, and state the return value. No filler or 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 diagnostic tool, this is complete. Annotations cover safety, output schema likely covers return structure, and the description covers when to use and expected success/error distinction. No gaps.
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?
The single parameter (response_format) is fully documented in the schema, so description need not repeat it. The description adds no param-specific context, but with 100% schema coverage, the baseline of 3 applies.
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 uses a specific verb ('Check') and resource ('Anki is running and AnkiConnect is reachable'). It clearly distinguishes this diagnostic connection-check tool from sibling Anki tools, which perform actions like syncing, listing, or creating decks.
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?
Directly states when to use: 'Call this first when any other Anki tool fails.' It explains the diagnostic value: distinguishing 'Anki is closed' from 'the request itself was wrong', which is a clear recommendation versus alternatives.
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?
The description discloses several important behavioral traits beyond annotations: it cannot log in for the user, returns nothing on success, and on sync conflict it opens a modal dialog in Anki that blocks until resolved, causing the call to time out. This adds substantial context about side effects and failure modes.
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 three sentences, each providing necessary information: purpose, prerequisite, and critical delay/edge-case behavior. There is no filler or redundancy, and the structure is logical and easy to parse.
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 tool with external side effects and potential blocking behavior, the description covers the essential context: prerequisites, success return (nothing), conflict behavior, and timeout implication. Since an output schema exists, return value details need not be explained further.
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 only parameter is response_format, a generic rendering option with full schema coverage. The description adds no parameter-specific information, but that is appropriate since the parameter is not tool-specific and is fully described in the schema. The description's lack of parameter detail is not a gap.
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 function with a specific verb 'Sync' and resource 'local collection with AnkiWeb'. It distinguishes the tool from siblings like anki_create_deck or anki_add_note, which handle different operations.
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 implies when to use the tool: to sync the local collection with AnkiWeb. It also provides a critical prerequisite (credentials must already be configured) and highlights a key behavioral consequence (conflict blocking). It does not explicitly name alternatives or exclusions, but the context is clear.
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?
Annotations already mark this as mutating/destructive, but the description adds valuable context: fields are sent verbatim as HTML, replacement is wholesale not merged, and the silent failure when the note is open in Anki's Browse window. The warning about Anki falsely reporting success is especially important and beyond annotation data.
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?
Well-structured with bold warnings and short, information-dense paragraphs. Every sentence earns its place: purpose, HTML semantics, partial-edit guidance, and the silent-failure warning. No redundancy or fluff.
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?
Combined with the output schema (present) and annotations, the description fully covers the tool's usage: destructive nature, field replacement semantics, prerequisite fetch step, and a critical failure mode. Sibling tools are referenced where relevant, making this complete for an agent.
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 already documents all three parameters; the description adds meaningful semantics for `fields` (verbatim HTML, wholesale replacement, omitted fields preserved), which is not evident from the schema alone. It does not further elaborate on `note_id` or `response_format`, but the existing schema coverage is sufficient.
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?
Opens with 'Overwrite fields of an existing note' – a specific verb and resource, clearly distinguishing it from sibling tools like add_note, find_notes, and get_notes_info. The scope is precise: updating, not creating or reading.
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?
Provides explicit guidance to fetch current values with anki_get_notes_info before partial edits, and outlines a recovery path for silent failures. However, it does not explicitly say when to avoid this tool (e.g., use add_note for new notes) or name a non-update alternative.
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:

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

Score Badge

Copy to your README.md:

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

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/chadlis/anki-mcp'

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