Anki MCP Server

by amidvidy

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: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, such as create_deck_with_note_type for deck creation and generate_audio for audio generation, but there is some overlap between generate_audio and generate_and_save_audio, which could cause confusion as both handle audio generation with similar names. The descriptions help clarify that generate_audio returns base64 data while generate_and_save_audio saves to media, but the naming similarity might lead to misselection.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern throughout, such as create_deck_with_note_type, list_decks, update_note, and get_deck_notes, with no deviations in style or convention. This predictability makes it easy for agents to understand and use the tools without confusion from mixed naming schemes.
Tool Count5/5
With 14 tools, the server is well-scoped for managing Anki decks and notes, covering operations like creation, retrieval, updating, and audio handling. Each tool serves a clear purpose, such as bulk operations for efficiency and specific functions like audio generation, making the count appropriate without being excessive or insufficient.
Completeness4/5
The tool surface provides comprehensive coverage for Anki management, including CRUD operations for decks and notes, bulk handling, and audio integration. Minor gaps exist, such as no direct tools for deleting decks or notes, but agents can work around this by using update or other methods, and core workflows are well-supported.
Average 3.3/5 across 14 of 14 tools scored.
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
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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 are provided, so the description carries the full burden. It mentions that card templates are optional and basic ones will be created if omitted, which adds some behavioral context. However, it doesn't disclose critical traits like whether this is a mutating operation (implied by 'create'), potential side effects (e.g., overwriting existing decks), authentication needs, error handling, or rate limits. For a creation tool with zero annotation coverage, this is insufficient.
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, well-structured sentence that efficiently conveys the core functionality and optional aspects. It is front-loaded with the main action and includes no redundant information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of creating both a deck and note type (a mutating operation), no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., idempotency, error cases), output format, or how this integrates with other tools (e.g., using the created deck/note type with 'create_note'). For a tool with 4 parameters and significant functionality, more context is needed.
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 schema already documents all parameters (deck_name, model_name, fields, card_templates) with clear descriptions. The description adds minimal value beyond the schema by noting that card templates are optional and basic ones will be created if not provided, but it doesn't explain parameter interactions (e.g., how fields relate to card templates) or provide examples beyond what's in the schema. Baseline 3 is appropriate when the schema does most of the work.
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 verb 'create' and the resources 'new deck' and 'optionally a new note type', which is specific and actionable. It distinguishes from siblings like 'create_note' (which adds notes to existing decks) by focusing on deck and note type creation. However, it doesn't explicitly mention how it differs from 'list_decks' or 'list_note_types' (which are read-only).
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the deck or note type must not already exist), nor does it compare to siblings like 'create_note' (for adding notes) or 'update_note' (for modifying). The optional nature of card templates is noted, but overall usage context is lacking.
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 carries the full burden of behavioral disclosure. It states the tool creates a note but doesn't cover critical aspects: whether this is a write operation (implied but not confirmed), error handling (e.g., if deck doesn't exist), permissions needed, or what happens on success (e.g., returns note ID). For a creation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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, efficient sentence that front-loads the core action ('Create a new note') and includes essential details without waste. Every word earns its place, making it easy to parse quickly. No unnecessary elaboration or redundancy is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (creation operation with 4 parameters, no output schema, and no annotations), the description is incomplete. It lacks information on behavioral traits (e.g., side effects, error conditions), usage context compared to siblings, and output details. For a tool that creates data without structured output documentation, more guidance is needed to ensure proper agent use.
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 schema already documents all parameters thoroughly (e.g., deck_name, model_name, fields mapping, optional tags). The description adds minimal value beyond the schema by mentioning 'fields and tags' but doesn't provide additional context like format examples beyond what's in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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 action ('Create a new note') and specifies the target resource ('in the specified deck') along with key attributes ('with the given fields and tags'). It distinguishes itself from siblings like 'create_notes_bulk' (single vs. bulk) and 'update_note' (create vs. update), though it doesn't explicitly mention these distinctions. The purpose is specific and actionable.
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., deck or model must exist), compare to 'create_notes_bulk' for multiple notes, or indicate when 'update_note' might be more appropriate. Usage is implied by the action but lacks explicit context or exclusions.
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 provided, the description carries the full burden of behavioral disclosure. It mentions the API used and output format, but lacks critical details such as rate limits, authentication requirements, error handling, or whether this is a read-only or mutating operation. For a tool that likely involves external API calls, this is a significant gap.
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, efficient sentence that front-loads the core functionality ('generate audio file from text') and includes essential details (API and output format) without unnecessary elaboration. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a TTS tool with external API integration, no annotations, and no output schema, the description is insufficient. It doesn't cover behavioral aspects like performance, limitations, or error cases, and the lack of output schema means the return value format (base64) is mentioned but not fully specified (e.g., encoding details).
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 schema already documents all three parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema (e.g., it doesn't explain default value implications or provide examples beyond the schema's descriptions). Baseline 3 is appropriate when the schema does the heavy lifting.
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 verb ('generate') and resource ('audio file from text'), specifying the technology used ('Google Cloud Chirp TTS API') and the output format ('base64 encoded audio data'). However, it doesn't explicitly differentiate from sibling tools like 'generate_and_save_audio', which appears to be a related but distinct operation.
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 guidance on when to use this tool versus alternatives. It doesn't mention the sibling tool 'generate_and_save_audio', which seems to serve a similar purpose but with different behavior (saving vs. returning base64 data). No context or exclusions are 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 provided, the description carries the full burden of behavioral disclosure but offers minimal insight. It implies a read-only operation ('Get') but doesn't specify aspects like whether it returns all notes at once (potential pagination issues), error handling for non-existent decks, or data format (e.g., structured vs. raw). This leaves significant gaps for a tool that likely interacts with user 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?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for effective tool use. It doesn't address key contextual aspects like return format (e.g., list of notes, error responses), performance considerations (e.g., large deck handling), or how it differs from siblings, leaving the agent under-informed for a data retrieval operation.
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 description adds no parameter-specific details beyond what the input schema already provides (100% coverage). It mentions 'a specific deck' which aligns with the 'deck_name' parameter but doesn't clarify semantics like case sensitivity, deck naming conventions, or validation rules. With high schema coverage, a baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
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 action ('Get') and target resource ('all notes/cards from a specific deck'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from similar siblings like 'get_deck_sample' or 'find_similar_notes', which might also retrieve notes with different scopes or filters.
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., deck existence), exclusions, or comparisons to siblings like 'get_deck_sample' (which might retrieve a subset) or 'find_similar_notes' (which likely filters content), leaving the agent to infer usage from tool names alone.
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 provided, the description carries the full burden of behavioral disclosure. It describes the core action (saving media) but lacks critical behavioral details such as whether this operation requires specific permissions, what happens if a file with the same name exists (overwrite? error?), rate limits, or the expected response format. For a write operation with zero annotation coverage, this is a significant gap.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every element contributing to understanding the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a write operation with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like error handling, idempotency, or integration with other tools (e.g., how the saved file references relate to note creation). For a tool that modifies system state, more context is needed.
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%, with all parameters well-documented in the input schema (filename, base64_data, media_type with default). The description adds no additional parameter semantics beyond what's already in the schema, such as format constraints or examples. Baseline 3 is appropriate when the schema does the heavy lifting.
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 action ('Save base64 encoded media data as a file') and the target resource ('in Anki's media collection for use in cards'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from sibling tools like 'generate_and_save_audio' or 'generate_audio', which might have overlapping media-related functionality.
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 minimal usage guidance, stating only that the saved file is 'for use in cards' without specifying when to use this tool versus alternatives like 'generate_and_save_audio' or how it integrates with other tools (e.g., whether it should be called before creating notes). No explicit when/when-not scenarios or prerequisites are mentioned.
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 provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe how it behaves—such as whether it returns all decks at once, if there's pagination, what format the output is in, or any performance considerations. This is inadequate for a tool with zero annotation coverage.
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, direct sentence with no wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'list' entails—such as the structure of returned data, any limitations, or error handling. For a tool with no structured behavioral hints, this leaves significant gaps in understanding.
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 tool has 0 parameters, and the schema description coverage is 100%, so there's no need for parameter details in the description. The description doesn't add parameter semantics, but this is acceptable given the lack of parameters, warranting a baseline score above minimum.
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 verb ('List') and resource ('all available Anki decks'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_deck_notes' or 'get_deck_note_types' which also retrieve deck-related information, so it doesn't reach the highest score.
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or compare it to siblings like 'get_deck_notes' or 'list_note_types', leaving the agent to infer usage scenarios.
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 provided, the description carries full burden but only states it updates fields without disclosing behavioral traits like permissions needed, whether updates are reversible, rate limits, or error handling. It mentions adding audio as an example but doesn't explain broader implications or constraints.
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 with two sentences that are front-loaded with the core purpose. The second sentence adds context without redundancy, though it could be slightly more structured (e.g., separating usage examples).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a mutation tool with 3 parameters. It lacks details on behavioral aspects, error cases, and what the tool returns, leaving gaps for an AI agent to understand full usage.
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 schema already documents all parameters. The description adds minimal value by hinting at usage ('adding audio') and implying 'fields' is a dictionary, but doesn't provide additional semantics beyond what the schema specifies (e.g., format details for audio).
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 action ('Update specific fields') and resource ('an existing note'), distinguishing it from creation tools like 'create_note' and bulk operations like 'update_notes_bulk'. However, it doesn't explicitly differentiate from all siblings (e.g., 'generate_and_save_audio' might also modify notes).
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 provides implied context with 'Perfect for adding audio or other content to existing cards', suggesting use cases, but lacks explicit guidance on when to choose this over alternatives like 'update_notes_bulk' for multiple notes or 'create_note' for new notes. No exclusions or prerequisites are mentioned.
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 provided, the description carries full burden but only states what the tool does without behavioral details. It doesn't disclose whether this is a read-only operation, what permissions are needed, how it handles non-existent decks, or the format/structure of the returned data. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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, well-structured sentence that efficiently conveys the tool's purpose without unnecessary words. It's front-loaded with the core functionality and appropriately sized for its complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that retrieves structured data. It doesn't explain what 'note types (models) and their field definitions' means in practice, what the return format looks like, or any error conditions. For a data retrieval tool with rich output expected, this leaves too much unspecified.
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 parameter 'deck_name' is fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides (e.g., no examples, format constraints, or relationship to output). The baseline score of 3 reflects adequate coverage through the schema alone.
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 action ('Get') and the resource ('note types (models) and their field definitions') with specific scope ('used in a specific deck'). It distinguishes from siblings like 'list_note_types' by specifying deck-specific retrieval, but doesn't explicitly contrast with 'get_deck_notes' which retrieves notes rather than note types.
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 when needing note types for a particular deck, but provides no explicit guidance on when to use this versus alternatives like 'list_note_types' (which might list all note types regardless of deck) or 'get_deck_notes' (which retrieves actual notes). No exclusions or prerequisites are mentioned.
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 carries the full burden of behavioral disclosure. It mentions random sampling and the goal of understanding note structure, but lacks details on permissions, rate limits, error handling, or what the output looks like (e.g., format of returned notes). This is a significant gap for a tool with no annotation coverage.
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, efficient sentence that front-loads the core purpose without unnecessary words. It directly communicates the tool's function and intent, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It does not explain what the returned sample includes (e.g., note fields, IDs), how randomness is implemented, or any behavioral traits like side effects. For a tool with 2 parameters and no structured output documentation, this leaves gaps in understanding how to use it effectively.
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%, with clear descriptions for both parameters ('deck_name' and 'sample_size') in the input schema. The description adds minimal value beyond the schema by implying the purpose of sampling for note structure understanding, but does not provide additional syntax or format details. Baseline 3 is appropriate when the schema does the heavy lifting.
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's purpose: 'Get a random sample of notes from a specific deck to understand typical note structure.' It specifies the verb ('Get'), resource ('notes'), and scope ('from a specific deck'), but does not explicitly differentiate it from sibling tools like 'get_deck_notes' or 'find_similar_notes', which prevents a score of 5.
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 understanding note structure through random sampling, but does not provide explicit guidance on when to use this tool versus alternatives like 'get_deck_notes' (which might retrieve all notes) or 'find_similar_notes' (which might search based on criteria). No exclusions or prerequisites are mentioned.
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 carries the full burden of behavioral disclosure. It states this is an update operation (implying mutation) and mentions efficiency, but fails to disclose critical traits such as required permissions, whether changes are reversible, error handling for partial failures in batch updates, rate limits, or what the response looks like. For a mutation tool with zero annotation coverage, this is a significant gap in 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 highly concise and well-structured in two sentences: the first states the purpose and benefit, and the second specifies parameter requirements. Every sentence adds value without redundancy, making it easy for an agent to parse quickly. It is appropriately sized for a tool with a single parameter and clear functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a batch mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., error handling, permissions), does not explain return values or side effects, and relies heavily on the schema for parameter documentation. For a tool that modifies multiple resources, more contextual information is needed to ensure safe and effective use by an agent.
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 description adds minimal semantics beyond the input schema: it specifies that each update should contain 'note_id and fields to update,' which aligns with the schema's description of 'update dictionaries.' However, with 100% schema description coverage, the schema already documents the parameter thoroughly (e.g., 'List of update dictionaries, each containing 'note_id', 'fields' dict, and optionally 'tags' list'). The description does not provide additional context like field constraints or examples, so it meets the baseline for high schema 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 the tool's purpose: 'Update multiple notes in a single batch operation for efficiency.' It specifies the verb ('update'), resource ('notes'), and scope ('multiple...batch'), distinguishing it from the sibling tool 'update_note' which likely handles single notes. However, it doesn't explicitly contrast with 'update_note' or other bulk operations like 'create_notes_bulk', leaving some sibling differentiation implicit.
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 context by mentioning 'efficiency' for batch operations, suggesting this tool is preferred over individual updates when handling multiple notes. However, it lacks explicit guidance on when to use this versus alternatives like 'update_note' or 'create_notes_bulk', and does not mention prerequisites, exclusions, or performance trade-offs, leaving the agent to infer optimal scenarios.
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 carries the full burden of behavioral disclosure. It mentions 'simple and reliable text matching' but lacks details on permissions, rate limits, error handling, or what happens if no matches are found. For a search tool with zero annotation coverage, this is a significant gap in 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 appropriately sized with two concise sentences that are front-loaded with the core purpose ('Find notes that contain the search text as a substring in any field') followed by a qualifier ('Simple and reliable text matching'). Every sentence earns its place without waste.
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 moderate complexity (search function with 4 parameters), no annotations, and no output schema, the description is incomplete. It covers the basic operation but lacks details on return values, error cases, or behavioral traits, leaving gaps for an AI agent to fully understand the tool's context.
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 schema already documents all parameters thoroughly. The description adds minimal value by reinforcing 'search text as a substring in any field', which aligns with the schema but doesn't provide additional syntax or format details beyond what's in the structured data.
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 with specific verbs ('Find notes') and resource ('notes'), and distinguishes it from siblings by specifying 'simple and reliable text matching' as a substring search across any field, unlike other tools that create, update, or list decks/notes without searching.
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 text-based substring searches in notes, but does not explicitly state when to use this tool versus alternatives like 'get_deck_notes' (which might list notes without searching) or other search-related tools not present in siblings. No exclusions or clear alternatives are 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 provided, the description carries full burden. It mentions the tool generates audio, saves it, and returns a filename, but doesn't disclose behavioral traits like whether this requires specific permissions, what happens if the filename already exists, whether there are rate limits, or what format the audio is in. For a tool that creates and saves files with no annotation coverage, this is a significant gap.
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, well-structured sentence that efficiently conveys the core functionality: generation, saving location, and return value. Every word earns its place with no redundancy or unnecessary elaboration.
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 tool with 4 parameters, 100% schema coverage, but no annotations and no output schema, the description is minimally adequate. It covers the purpose and basic usage but lacks behavioral details (e.g., file overwrite behavior, error conditions) and doesn't explain the return value format beyond 'filename'. Given the complexity of file generation and saving operations, more context would be helpful.
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 schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It implies the parameters are used for generation and saving but provides no additional syntax, format, or usage details. Baseline 3 is appropriate when 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 the specific action: 'Generate audio from text and save it to Anki's media collection', which includes both generation and saving. It distinguishes from sibling 'generate_audio' by explicitly mentioning saving to Anki's media collection, and from 'save_media_file' by specifying audio generation from text.
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: 'returning filename for use in cards' indicates this is for Anki card creation. However, it doesn't explicitly state when to use this vs. 'generate_audio' (which likely doesn't save) or 'save_media_file' (which likely saves existing files). The guidance is implied but not explicit about alternatives.
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 carries the full burden and does well by disclosing key behavioral traits: it's a write operation (implied by 'Create'), handles duplicates gracefully with reporting, and includes important implementation details about the auto_audio parameter structure. It doesn't cover permissions, rate limits, or error handling, but provides substantial operational context.
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 appropriately sized but not optimally structured: the first paragraph is well-focused, but the auto_audio instructions dominate with repetitive warnings and an example that could be more concise. Some information (like the dictionary/object requirement) is repeated, reducing efficiency.
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 3-parameter write tool with no annotations and no output schema, the description is moderately complete: it covers the main operation, duplicate behavior, and critical parameter details. However, it lacks information about return values, error conditions, or what happens with invalid inputs, leaving gaps in operational understanding.
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 67% schema description coverage, the description compensates well by adding crucial semantics: it explains the auto_parameter must be a dictionary/object (not JSON string), provides a complete example structure, and clarifies how to disable it. This adds significant value beyond the schema, though it doesn't detail notes_list structure beyond what's in the 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 specific action ('Create multiple notes in a single batch operation') and resource ('notes'), distinguishing it from sibling tools like 'create_note' (singular) and 'update_notes_bulk' (updates rather than creates). It also mentions the efficiency benefit and duplicate handling, which adds valuable context.
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 for when to use this tool ('for efficiency' in batch operations) and implies an alternative by mentioning duplicate handling, which suggests it's suitable for bulk imports. However, it doesn't explicitly state when not to use it or name specific sibling alternatives like 'create_note' for single 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?
With no annotations provided, the description carries full burden. It discloses the tool lists all available note types with fields and templates, implying a read-only, non-destructive operation. However, it doesn't mention behavioral traits like pagination, rate limits, authentication needs, or error conditions, leaving gaps for a tool with no annotation coverage.
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, efficient sentence that front-loads the core purpose ('List all available note types') and adds necessary detail ('with their fields and card templates') without any wasted words. Every part earns its place.
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 no annotations, no output schema, and 0 parameters, the description is minimally complete for a simple list tool. It explains what the tool returns (note types with fields and templates), but lacks details on output format, error handling, or system constraints, which could be helpful despite the low complexity.
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 tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add param info beyond the schema, but this is appropriate given the lack of parameters, meeting the baseline for 0 params.
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 specific action ('List all available note types') and specifies the resources returned ('with their fields and card templates'). It distinguishes from siblings like 'get_deck_note_types' by not being deck-specific and from 'create_deck_with_note_type' by being read-only.
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 usage context (when you need to know available note types with their structure), but doesn't explicitly state when to use this vs. alternatives like 'get_deck_note_types' for deck-specific types or 'create_deck_with_note_type' for creation. No exclusions or prerequisites are mentioned.
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/amidvidy/anki-mcp/badges/card.svg)](https://glama.ai/mcp/servers/amidvidy/anki-mcp)

Score Badge

Copy to your README.md:

[![anki-mcp MCP server](https://glama.ai/mcp/servers/amidvidy/anki-mcp/badges/score.svg)](https://glama.ai/mcp/servers/amidvidy/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/amidvidy/anki-mcp'

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