一个模型上下文协议 (MCP) 服务器，通过 AnkiConnect 使 LLM 能够与 Anki 抽认卡软件交互。
list_decks - 列出所有可用的 Anki 牌组
create_deck - 创建一个新的 Anki 牌组
create_note - 创建一个新的笔记（基础或填空题）
batch_create_notes - 一次性创建多个笔记
search_notes - 使用 Anki 查询语法搜索笔记
get_note_info - 获取笔记的详细信息
update_note - 更新现有笔记
delete_note - 删除笔记
list_note_types - 列出所有可用的笔记类型
create_note_type - 创建一个新的笔记类型
get_note_type_info - 获取笔记类型的详细结构
anki://decks/all - 所有可用牌组的完整列表
anki://note-types/all - 所有可用笔记类型的列表
anki://note-types/all-with-schemas - 所有笔记类型的详细结构信息
anki://note-types/{modelName} - 特定笔记类型的详细结构信息
Related MCP server: Anki MCP Server
系统中已安装 Anki
Anki 中已安装 AnkiConnect 插件
本仓库支持 Anthropic 桌面扩展 (MCPB)。在 Claude Desktop 中使用此服务器最简单的方法是安装打包好的 .mcpb 捆绑包。
使用提供的脚本在本地生成 .mcpb 文件：
npm run pack打开 Claude Desktop 设置 → 扩展，拖入生成的 .mcpb 文件，然后点击安装。
这将验证 manifest.json 并输出一个可按上述方式安装的 .mcpb 归档文件。了解更多关于桌面扩展的信息，请参阅 Anthropic 的公告：桌面扩展：为 Claude Desktop 提供一键式 MCP 服务器安装。
将服务器添加到你的 claude_desktop_config.json 中：
{
"mcpServers": {
"anki": {
"command": "npx",
"args": ["--yes", "anki-mcp-server"]
}
}
}如果你的 AnkiConnect 运行在不同的端口上，可以使用 --port 参数指定它：
{
"mcpServers": {
"anki": {
"command": "npx",
"args": ["--yes", "anki-mcp-server", "--port", "8080"]
}
}
}将服务器添加到 VSCode 设置文件 cline_mcp_settings.json 中的 Cline MCP 设置里：
{
"mcpServers": {
"anki": {
"command": "npx",
"args": ["--yes", "anki-mcp-server"]
}
}
}对于 Cline，你也可以指定自定义端口：
{
"mcpServers": {
"anki": {
"command": "npx",
"args": ["--yes", "anki-mcp-server", "--port", "8080"]
}
}
}安装 Anki 技能，让 Claude Code 具备所有 Anki 工具和工作流的内置知识：
npx skills add nailuoGG/anki-mcp-server@anki安装完成后，当你要求 Claude Code 创建抽认卡、管理牌组或批量导入笔记时，它会自动使用该技能。
注意： 不要将
.mcpb打包版本用作 MCP 服务器 — 它会将 Electron 元数据输出到标准输出 (stdout)，这会破坏 MCP stdio 协议。请改用npx -y anki-mcp-server。
为 Claude Desktop 创建可分发的桌面扩展捆绑包：
npm run pack这将构建项目并从当前仓库生成一个 .mcpb 归档文件，同时验证 manifest.json。通过将其拖入 Claude Desktop 的扩展设置中进行测试。参考：桌面扩展：为 Claude Desktop 提供一键式 MCP 服务器安装。
当发布新版本时，此服务器会自动发布到 MCP 注册表。发布过程包括：
自动化 CI/CD：GitHub Actions 在成功发布时会自动发布到 NPM 和 MCP 注册表
模式验证：server.json 文件在发布前会根据 MCP 模式进行验证
版本同步：package.json、manifest.json 和 server.json 之间的版本保持同步
全面测试：在发布前进行多版本 Node.js 测试、代码检查和验证
Beta 支持：用于测试新功能的自动化 Beta 版本发布
你可以在本地验证 MCP 服务器配置：
npm run validate-mcp这将下载最新的 MCP 模式并验证你的 server.json 文件。
如果你需要手动发布，可以使用 MCP 发布者 CLI：
# Install MCP Publisher
curl -L "https://github.com/modelcontextprotocol/registry/releases/download/v1.1.0/mcp-publisher_1.1.0_$(uname -s | tr '[:upper:]' '[:lower:]')_$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/').tar.gz" | tar xz mcp-publisher
chmod +x mcp-publisher
sudo mv mcp-publisher /usr/local/bin/
# Login to MCP Registry
mcp-publisher login github-oidc
# Publish to MCP Registry
mcp-publisher publish安装依赖：
npm install构建服务器：
npm run build用于自动重建的开发模式：
npm run watch运行测试套件：
npm test这将执行以下测试：
服务器初始化
AnkiConnect 通信
笔记操作（创建/读取/更新/删除）
牌组管理
错误处理
由于 MCP 服务器通过 stdio 进行通信，我们建议使用 MCP Inspector：
npm run inspector它提供了一个基于浏览器的界面，用于：
监控 MCP 消息
测试工具调用
查看服务器日志
调试通信问题
创建一个新牌组：
Create a new Anki deck called "Programming"添加一张基础卡片：
Create an Anki card in the "Programming" deck with:
Front: What is a closure in JavaScript?
Back: A closure is the combination of a function and the lexical environment within which that function was declared.添加一张填空题卡片：
Create a cloze card in the "Programming" deck with:
Text: In JavaScript, {{c1::const}} declares a block-scoped variable that cannot be {{c2::reassigned}}.Fork 本仓库
创建你的功能分支
运行测试：npm test
提交 Pull Request
图标由 macOS Icons 提供
MIT 许可证 - 详情请参阅 LICENSE 文件
Use when the user wants to add one or more tags to existing notes for organization. Do not use when the user wants to remove tags (use anki_remove_note_tags) or update note content (use anki_update_note). Safety: confirm before adding tags to a large number of notes.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | Yes | Tags to add. Use Anki tag names without whitespace. | |
| noteId | No | Single note ID to update. | |
| noteIds | No | Multiple note IDs to update. |
| Name | Required | Description |
|---|---|---|
| tags | Yes | |
| noteIds | Yes | |
| success | Yes | |
| operation | Yes | |
| updatedCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and not read-only/not destructive. Description adds safety confirmation guidance, which is useful behavioral context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences are efficient: first states purpose, second gives exclusions, third provides safety tip. Front-loaded with key information, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, presence of annotations, and existence of an output schema, the description covers all essential aspects: when to use, alternatives, safety, and parameter usage is handled by schema. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description does not add any additional semantics beyond what the schema already provides for parameters (tags, noteId, noteIds).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool adds tags to notes, with explicit verb 'add' and resource 'tags to existing notes'. It also distinguishes from siblings by specifying when NOT to use and naming alternatives (anki_remove_note_tags, anki_update_note).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use ('when the user wants to add one or more tags') and when-not-to-use ('Do not use when...'), with named alternative tools. Also includes safety guidance for large batches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user wants to create multiple study cards at once (2–50 notes). Prefer this over repeated anki_create_note calls. Returns per-note success and error details. Safety: ask the user to confirm before creating a large batch of notes.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | Yes | Notes to create. | |
| stopOnError | No | Stop after the first failed note. | |
| allowDuplicate | No | Allow duplicate notes in their target decks. |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| failed | Yes | |
| results | Yes | |
| successful | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it states that per-note success and error details are returned, and that a confirmation prompt is needed for large batches. Annotations indicate the tool is not read-only, so the description confirms mutation without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose and followed by return details and safety. Every sentence adds value with no redundancy, achieving conciseness without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description does not need to explain return values in detail. It covers the use case, preference over sibling, return type, and safety. It could be slightly more explicit about the confirmation prompt's format, but overall it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed parameter descriptions (e.g., field maps like {Front: 'question', Back: 'answer'}). The description does not add significant semantics beyond what the schema already provides, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates multiple study cards at once (2–50 notes) and explicitly differentiates from the sibling tool anki_create_note by preferring this tool over repeated calls. The verb 'batch create' is specific and matches the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (batch of 2-50 notes) and when not (prefer over repeated anki_create_note calls). It also includes a safety instruction to ask the user before creating a large batch, covering key context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether AnkiConnect is reachable and return the API version.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| version | Yes | |
| connected | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds minimal extra behavioral context (returning API version). No contradictions. Adequately complements annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with action and outcome, no wasted words. Perfectly concise for a no-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema, the description fully covers what the tool does. No missing information for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description adds no parameter info because none are needed. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and the resource 'AnkiConnect' and specifies the outcome 'return the API version'. It distinguishes from siblings like anki_list_decks or anki_sync by focusing on connectivity rather than data manipulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, but the purpose is self-evident as a readiness check before other operations. Implied usage is adequate for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an Anki deck by name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Deck name to create. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| deckId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds no extra behavioral context beyond these hints, but it does not contradict them either. For a simple creation tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with one sentence. It is front-loaded with the verb and resource, containing no unnecessary words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description sufficiently covers the core functionality. However, it could mention deck naming conventions (e.g., nesting with '::') or uniqueness constraints, though these are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter with a description). The description says 'by name', which adds little beyond the schema's 'Deck name to create.' Baseline score of 3 is appropriate as the schema already provides the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 resource 'Anki deck', distinguishing it from other tools like anki_list_decks or anki_create_note. However, it is minimal and does not elaborate on what creation entails (e.g., empty deck).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus siblings like anki_list_decks or anki_create_note, nor does it mention prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user wants to create a single new study card (note) in an existing deck. Creates user study content — not a schema change. Do not use when the user only wants to inspect existing notes, decks, tags, or note types. To define a new note structure, use anki_create_note_type instead. Call anki_get_note_type_info first for custom fields. For multiple notes, use anki_batch_create_notes. Safety: confirm with the user before creating notes if intent is unclear.
| Name | Required | Description | Default |
|---|---|---|---|
| deck | Yes | Target deck name. The deck is created if it does not exist. | |
| tags | No | Optional tags for organization. Use strings without spaces for best Anki compatibility. | |
| type | Yes | Note type/model name. Common: Basic, Cloze. | |
| fields | Yes | Note fields keyed by exact model field names. For Basic: {Front: 'question', Back: 'answer'}. | |
| allowDuplicate | No | Allow duplicate notes in the target deck. |
| Name | Required | Description |
|---|---|---|
| deck | Yes | |
| noteId | Yes | |
| modelName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). Description adds that it creates user study content (not a schema change) and includes a safety confirmation requirement. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient, with three front-loaded sentences that cover purpose, usage guidance, and safety. No redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, nested objects, output schema exists), the description adequately covers usage context, safety, and sibling differentiation. It is sufficiently complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed descriptions for each parameter, including examples. The description does not add additional meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is for creating a single study card (note) in an existing deck, using specific verbs and resources. It distinguishes itself from inspecting notes (anki_get_note_info), defining new note structures (anki_create_note_type), and batch creation (anki_batch_create_notes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (user wants to create a single note), when not to use (inspection, schema changes), and alternatives including anki_get_note_type_info, anki_batch_create_notes, and anki_create_note_type. Also advises confirming with user if intent is unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user wants to define a new note schema/model with custom fields and card templates. Modifies the Anki collection structure — not for creating study content. Do not use when the user wants to create notes (use anki_create_note) or inspect an existing note type (use anki_get_note_type_info). Safety: confirm with the user before creating a new note type, as this changes the collection schema.
| Name | Required | Description | Default |
|---|---|---|---|
| css | No | Optional model CSS. | |
| name | Yes | New note type name. | |
| fields | Yes | Field names in order. | |
| templates | Yes | Card templates. |
| Name | Required | Description |
|---|---|---|
| fields | Yes | |
| success | Yes | |
| modelName | Yes | |
| templates | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false and destructiveHint=false, but description adds behavioral context: 'Modifies the Anki collection structure' and 'changes the collection schema.' This goes beyond annotations. Safety note adds transparency. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a safety note. Front-loaded with main purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is moderately complex (4 params, 3 required) and has output schema (not shown but indicated). Description covers purpose, behavior, and alternative tools. Missing error handling (e.g., duplicate name) but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description mentions 'custom fields and card templates' which maps to parameters, but adds no detail beyond the schema. No extra semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and resource 'note type' (note schema/model). It distinguishes from sibling tools: not for creating notes (anki_create_note) or inspecting existing note types (anki_get_note_type_info).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use when the user wants to define a new note schema/model with custom fields and card templates.' Provides when-not: 'Do not use when the user wants to create notes' or inspect existing note types, with specific alternative tool names. Also includes a safety note to confirm with user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user explicitly asks to permanently delete one or more notes. Do not use when the user only wants to inspect, search, or update notes. Safety: always confirm with the user before deleting any note — this action is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| noteId | No | Single note ID to delete. | |
| noteIds | No | Multiple note IDs to delete. |
| Name | Required | Description |
|---|---|---|
| noteIds | Yes | |
| success | Yes | |
| deletedCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds value beyond them by stating the action is irreversible and mandating an explicit user confirmation step. It does not mention the idempotent behavior declared in annotations, but it does not contradict it either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: purpose, exclusion, and safety. The most important scoping constraint is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need no explanation, annotations cover the safety profile, and the description supplies the irreversibility warning and confirmation requirement. Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — both noteId and noteIds are documented, and the oneOf branching is expressed structurally. The description adds no format or constraint detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('permanently delete one or more notes') and immediately distinguishes the tool from siblings that inspect, search, or update notes. An agent can tell it apart from anki_update_note or anki_search_notes without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives the when ('user explicitly asks to permanently delete') and the when-not ('only wants to inspect, search, or update'). It also names the safety precondition of confirming before the call, which is actionable routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information for one note ID.
| Name | Required | Description | Default |
|---|---|---|---|
| noteId | Yes | Positive Anki note ID. |
| Name | Required | Description |
|---|---|---|
| tags | Yes | |
| fields | Yes | |
| noteId | Yes | |
| modelName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and description does not add behavioral traits beyond stating it gets information. No mention of exceptions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words, perfectly front-loaded and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and simple read-only nature, the description is adequate. Could mention what fields are returned, but not necessary for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for noteId, and the description merely repeats 'one note ID'. No additional semantic value added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get detailed information for one note ID' with a specific verb and resource, distinguishing it from sibling tools like anki_search_notes that handle multiple notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for a single note ID, but no explicit guidance on when to use or when to avoid, nor reference to alternative tools for searching or updating.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when inspecting a note type before creating or updating notes, especially for non-standard models. Returns fields and card templates. Call this before anki_create_note when using a custom note type. Do not use when the user wants to create notes or modify a note type.
| Name | Required | Description | Default |
|---|---|---|---|
| modelName | Yes | Note type/model name. | |
| includeCss | No | Include CSS styling when true. |
| Name | Required | Description |
|---|---|---|
| css | No | |
| fields | Yes | |
| modelName | Yes | |
| templates | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. Description adds that it returns fields and templates, giving useful context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words, front-loaded with purpose. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage context, return value, and works with output schema. Adequate for a read-only tool with good annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. Description does not add additional parameter details beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool inspects a note type, returning fields and card templates. It specifies the verb 'inspecting' and the resource 'note type', and distinguishes from sibling tools like anki_create_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: before creating or updating notes, especially for non-standard models. Also gives a do-not-use case: when user wants to create or modify a note type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Anki decks, optionally with deck IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| includeIds | No | Include a deckIds object keyed by deck name when true. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| decks | Yes | |
| deckIds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description's mention of 'List' is consistent but adds no further behavioral insight (e.g., sorting, performance, or behavior when no decks exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence front-loading the action; no unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional boolean parameter and an output schema (indicated), the description fully covers the tool's purpose and option.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter; the description reiterates the option ('optionally with deck IDs') but adds no new meaning beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List all available Anki decks' with a clear verb and resource, and mentions the optional inclusion of deck IDs, distinguishing it from sibling tools like anki_create_deck or anki_delete_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as anki_search_notes or anki_get_note_info; lacks context on prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Anki note types/models.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| noteTypes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=false, so the description's claim of listing 'all available' note types is consistent and adds no new behavioral context beyond what annotations provide. No additional traits like performance or side effects are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. Every word serves the purpose, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 no parameters and an output schema, the description is appropriately minimal. The output schema handles return value details, so the description adequately covers the necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%. With no parameters to explain, the description need not add parametric information, earning a baseline score of 4 per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all available Anki note types/models, using a specific verb and resource. It distinguishes itself from sibling tools like anki_list_decks or anki_list_tags, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, such as anki_get_note_type_info for a specific note type. It does not mention prerequisites or typical use cases, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tags currently used in the Anki collection.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| tags | Yes | |
| count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states it lists 'all tags currently used,' which is transparent about scope. Annotations already declare readOnlyHint=true, so the read-only nature is covered. No contradictions. It adds minor context beyond annotations (scope of current usage) but is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Front-loaded with the action and resource. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite simplicity, the description is complete for the tool's purpose. An output schema exists, so return values are documented elsewhere. No additional context is needed for this straightforward list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description does not need to add parameter info. Baseline score of 3 is appropriate as the schema already fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists all tags in the Anki collection. It uses a specific verb ('list') and resource ('tags'). However, it does not differentiate from sibling tools that list other entities like decks or note types, which could cause ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an agent needs to see all tags, but it provides no explicit guidance on when to use this tool versus alternatives like anki_add_note_tags or anki_search_notes. For a simple tool, the lack of exclusions is acceptable but not exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user wants to remove specific tags from one or more existing notes. Do not use when the user wants to add tags (use anki_add_note_tags) or clear all tags (use anki_update_note with an empty tags array). Safety: confirm with the user before removing tags, as this modifies note metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | Yes | Tags to remove. Use Anki tag names without whitespace. | |
| noteId | No | Single note ID to update. | |
| noteIds | No | Multiple note IDs to update. |
| Name | Required | Description |
|---|---|---|
| tags | Yes | |
| noteIds | Yes | |
| success | Yes | |
| operation | Yes | |
| updatedCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false; the description adds the crucial safety warning to confirm with the user before modifying metadata, providing actionable behavioral guidance 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences: first defines use, second excludes alternatives, third adds safety. No waste, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and the description covers usage, exclusions, and safety, it is fully complete for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add extra parameter-level meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool removes specific tags from notes, uses a specific verb+resource, and distinguishes from siblings by explicitly excluding add and clear-all operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (remove specific tags) and when not to use (add tags, clear all tags), with direct references to alternative tools (anki_add_note_tags, anki_update_note). Also includes a safety instruction to confirm with the user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search notes with Anki query syntax and return paginated note details.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum note details to return. | |
| query | Yes | Anki search query. | |
| offset | No | Zero-based note result offset. |
| Name | Required | Description |
|---|---|---|
| limit | Yes | |
| notes | Yes | |
| query | Yes | |
| total | Yes | |
| offset | Yes | |
| hasMore | Yes | |
| nextOffset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's mention of 'Search' and 'paginated' adds some context about pagination behavior but does not delve into other traits like rate limits or return format. The description does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the main action and resource. It is concise with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with a full schema and output schema, the description covers the core concepts: query syntax, pagination, and note details. However, it could briefly mention the query syntax format or that results are paginated note objects to be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description mentions 'paginated' which hints at limit/offset, but adds no additional meaning beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search', the resource 'notes', and specifies 'Anki query syntax' and 'paginated note details'. It effectively distinguishes from siblings like anki_get_note_info which retrieves a single note by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via 'Search notes with Anki query syntax' but does not explicitly state when to use this tool over siblings (e.g., for filtering vs. fetching a known note). No when-not or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request AnkiWeb sync. Requires {"confirm": true}: without it the call is refused, because a full sync can merge or overwrite local and remote collections. Success means Anki accepted the request, not that AnkiWeb completed it.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Must be true to perform the sync. Omitted or false returns a refusal without contacting AnkiWeb. |
| Name | Required | Description |
|---|---|---|
| message | Yes | |
| success | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing the refusal gate, the real risk that a full sync can merge or overwrite local and remote collections, and the crucial caveat that success means Anki accepted the request, not that AnkiWeb finished. None of that is derivable from readOnlyHint/destructiveHint/idempotentHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with no filler, and the precondition ('Requires {"confirm": true}') is front-loaded before the risk and result semantics. Every sentence carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not describe return values, yet it still clarifies the meaning of a successful response (accepted, not completed) and the destructive potential of a full sync. Nothing an agent needs before calling is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter's description already spells out the confirm-true requirement and refusal behavior, so the schema does the heavy lifting. The description restates the same gate without adding format or edge-case detail beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Request AnkiWeb sync') that is unmistakably distinct from the note/deck/tag CRUD siblings. An agent can tell at a glance this is the collection-sync operation, not a content mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives the operative condition for invoking the tool (must pass confirm:true) and what happens otherwise (refusal without contacting AnkiWeb). No alternative tool is named, but no sibling overlaps this operation, so routing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user wants to edit the fields or replace the tags of an existing note. Do not use when the user only wants to inspect note content (use anki_get_note_info) or delete it (use anki_delete_note). Safety: confirm with the user before overwriting note content.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Replacement tag list. Pass an empty array to clear tags. | |
| fields | No | Note fields keyed by exact model field names. For Basic: {Front: 'question', Back: 'answer'}. | |
| noteId | Yes | Positive Anki note ID. |
| Name | Required | Description |
|---|---|---|
| noteId | Yes | |
| success | Yes | |
| updatedTags | Yes | |
| updatedFields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is largely covered. The description adds actionable behavioral guidance beyond them: confirm with the user before overwriting note content. It does not say whether omitted parameters leave existing values untouched, which is the one behavioral question an agent still has.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the when-to-use condition, then exclusions, then the safety caveat. Every sentence carries a distinct decision-relevant fact and none is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need no explanation, and annotations cover the destructive/idempotent profile. The description plus schema cover intent routing, tag replacement, field keying, and the confirmation requirement; the only residual gap is partial-update behavior when only one of fields/tags is supplied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already spells out the important semantics (empty array clears tags, fields keyed by exact model field names, positive note ID). The description's 'replace the tags' merely restates what the schema documents, so baseline 3 is right.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource pair (edit fields / replace tags of an existing note) that an agent can match to a user intent without opening the schema. It also names the sibling tools it is not (anki_get_note_info, anki_delete_note), so it is distinguishable from the other note-level tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit positive conditions ('user wants to edit the fields or replace the tags') and explicit negative conditions with the correct alternative for each ('only wants to inspect' -> anki_get_note_info, 'delete it' -> anki_delete_note). Routing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0anki_delete_note1 field changedInput schema / oneOfAdded value: +[
+ {
+ "required": [
+ "noteId"
+ ]
+ },
+ {
+ "required": [
+ "noteIds"
+ ]
+ }
+]anki_sync1 field changedInput schema / properties / confirmAdded value: +{
+ "description": "Must be true to perform the sync. Omitted or false returns a refusal without contacting AnkiWeb.",
+ "type": "boolean"
+}anki_update_note3 fields changedInput schema / properties / idRemoved value: -{
- "description": "Positive Anki note ID.",
- "minimum": 1,
- "type": "number"
-}Input schema / properties / noteIdAdded value: +{
+ "description": "Positive Anki note ID.",
+ "minimum": 1,
+ "type": "number"
+}Input schema / requiredPrevious value: -[
- "id"
-]New value: +[
+ "noteId"
+]v0.1.8anki_add_note_tagsanki_batch_create_notesanki_check_connectionanki_create_deckanki_create_noteanki_create_note_typeanki_delete_noteanki_get_note_infoanki_get_note_type_infoanki_list_decksanki_list_note_typesanki_list_tagsanki_remove_note_tagsanki_search_notesanki_syncanki_update_noteScored across 16 tools
Each tool targets a distinct resource+action, and descriptions explicitly say when NOT to use a tool (e.g. update vs inspect vs delete notes), which strongly aids selection. Minor potential confusion exists between anki_create_note/anki_batch_create_notes and anki_list_note_types/anki_get_note_type_info, but the descriptions disambiguate these well.
All 16 tools consistently follow anki_<verb>_<noun> snake_case (get_note_info, list_decks, create_note, add_note_tags, remove_note_tags). The pattern is predictable throughout with no stylistic deviations.
16 tools is at the upper end of the comfortable range but each earns its place across notes, decks, tags, and note types. Slightly heavy, but not excessive for a full collection-management surface.
Strong coverage: notes have create/batch-create/get/update/delete/search, plus deck and tag management, note-type inspection/creation, sync, and connection check. Minor gaps remain (no deck delete/rename, no note-type update/delete, no single-note get by search shortcut), but core workflows are covered.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
A Model Context Protocol server for Wix AI tools
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
