Skip to main content
Glama
Sign In
anki-connect-mcp

anki-connect-mcp

by SolarianGG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

notes.planConversion

notes_planConversion
Read-only

Get native field and template mappings plus a schema token before converting notes from one note type to another, so you can preview changes safely.

Instructions

Get native suggested field/template mappings and a schema token.

Anki-Connect method notes.planConversion. Scope: collection. Effect: read. Completion: completed. Undo: none.

Possible errors: collectionUnavailable, internalError, invalidParams, notFound, staleSession.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "source": "<source>",
      "target": "<target>"
    },
    "name": "notes_planConversion"
  }
}

Input Schema

NameRequiredDescriptionDefault
sourceYesCurrent note type of the notes: exactly one of {"id": "<noteTypeId>"} or {"name": "<note type name, e.g. Basic>"}.
targetYesNote type to convert to: exactly one of {"id": "<noteTypeId>"} or {"name": "<note type name, e.g. Basic>"}.
sessionNoOptional. Collection session ID: the `session` field returned by `collection_get`. Usually omit it — the server then uses the session current at the time of the call. Pass it to make the call fail with `staleSession` instead of acting on a different profile/collection than the one your IDs, cursors and tokens came from.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnly, non-destructive, closed-world behavior; the description adds real context beyond them—collection scope, 'Effect: read', 'Undo: none', and an enumerated error taxonomy (collectionUnavailable, internalError, invalidParams, notFound, staleSession). What is not disclosed is the nature of the returned 'schema token' (lifetime, whether it is bound to the source/target pair, whether it must be passed back to notes_convert).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in one sentence, followed by a compact metadata block and an error list; little waste. The error enumeration is arguably boilerplate across this tool family, but it is short and scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description bears full responsibility for describing the return value, and 'native suggested field/template mappings and a schema token' is too thin for an agent to know what it receives or how to use the token. The mutation-adjacent workflow (plan then convert) that gives this tool its purpose is never spelled out.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already explains the oneOf id/name forms for source and target plus the staleSession semantics of session. The description adds nothing about these three parameters, so it neither compensates nor detracts—baseline applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb plus resource: 'Get native suggested field/template mappings and a schema token,' which is concrete, but the connection to notes_get/notes_validate/notes_convert is left implicit. The tool is visibly the planning counterpart to notes_convert, yet the description never says so, so sibling differentiation depends on the reader inferring it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance at all: nothing says this should be called before notes_convert, nor whether it is a dry-run prerequisite, nor when to skip it. The metadata lines (scope, effect, completion, undo) describe the call's nature but not the decision to make it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools