AnkiConnect를 통해 LLM이 Anki 플래시카드 소프트웨어와 상호작용할 수 있도록 하는 모델 컨텍스트 프로토콜(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 데스크톱 확장 프로그램(MCPB)을 지원합니다. Claude Desktop에서 이 서버를 사용하는 가장 쉬운 방법은 패키징된 .mcpb 번들을 설치하는 것입니다.
제공된 스크립트를 사용하여 로컬에서 .mcpb 파일을 생성합니다:
npm run packClaude Desktop 설정 → 확장 프로그램(Extensions)을 열고 생성된 .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.
