AnkiConnectを介してLLMがAnkiフラッシュカードソフトウェアと対話できるようにするModel Context Protocol (MCP) サーバーです。
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 Desktop Extensions (MCPB) をサポートしています。Claude Desktopでこのサーバーを使用する最も簡単な方法は、パッケージ化された .mcpb バンドルをインストールすることです。
提供されたスクリプトを使用して、ローカルで .mcpb ファイルを生成します：
npm run packClaude Desktopの「設定」→「拡張機能」を開き、生成された .mcpb ファイルをドラッグ＆ドロップして「インストール」をクリックします。
これにより manifest.json が検証され、上記のようにインストール可能な .mcpb アーカイブが出力されます。デスクトップ拡張機能の詳細については、Anthropicの発表を参照してください：Desktop Extensions: One-click MCP server installation for Claude Desktop
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の拡張機能設定にドラッグ＆ドロップしてテストしてください。参照：Desktop Extensions: One-click MCP server installation for Claude Desktop
このサーバーは、新しいバージョンがリリースされると自動的にMCPレジストリに公開されます。公開プロセスには以下が含まれます：
自動CI/CD: GitHub Actionsがリリース成功時にNPMとMCPレジストリの両方に自動公開
スキーマ検証: server.json ファイルが公開前にMCPスキーマに対して検証される
バージョン同期: package.json、manifest.json、server.json 間でバージョンが同期される
包括的なテスト: 公開前のマルチバージョンNode.jsテスト、リンティング、検証
ベータサポート: 新機能テストのための自動ベータリリース
MCPサーバーの設定をローカルで検証できます：
npm run validate-mcpこれにより最新のMCPスキーマがダウンロードされ、server.json ファイルが検証されます。
手動で公開する必要がある場合は、MCP Publisher 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}}.リポジトリをフォーク
フィーチャーブランチを作成
テストを実行: npm test
プルリクエストを送信
アイコン提供: 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.
