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

anki-connect-mcp

by SolarianGG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

notes.update

notes_update

Apply field edits and replace the tag set of one Anki note in a single native update, preserving fields not included.

Instructions

Apply fields and tags together in one native note update.

Anki-Connect method notes.update. Scope: collection. Effect: write. Completion: completed. Undo: single.

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

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": {
      "id": "<id>",
      "patch": "<patch>"
    },
    "name": "notes_update"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesNote ID (decimal string, e.g. "1700000000001").
patchYesChanges to apply: {fields?, tags?}. `fields` merges by field name (other fields are kept); `tags` replaces the whole tag set. Must not be empty.
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

A3.7/5.0
Behavior4/5

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

Goes beyond the annotations with mutation semantics that matter: scope (collection), effect (write), completion state (completed) and 'Undo: single', which tells the agent the change is reversible as one unit. The enumerated error surface (editorConflict, staleSession, notFound, etc.) adds real operational context that readOnlyHint/destructiveHint cannot convey.

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?

Front-loaded with the one-line purpose, then compact labeled metadata lines followed by an error list. No filler sentences; only slight redundancy with the title and annotations ('Effect: write').

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

Completeness4/5

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

For a nested-patch mutation tool with a fully documented schema and no output schema, the description supplies the missing behavioral layer: undo behavior and the possible failure modes. Only the lack of guidance on pre-validation (notes_validate) or conflict handling leaves a small gap.

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 coverage is 100% and the patch object already documents the merge-vs-replace semantics and the session parameter in detail, so the description adds no parameter-level meaning. Baseline 3 is appropriate.

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?

States a specific verb and resource ('Apply fields and tags ... in one native note update') and hints at the combined fields+tags capability that separates it from tags_replace. It does not explicitly contrast with editors_updateDraft or notes_validate, so an agent still has to infer sibling boundaries.

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

Usage Guidelines3/5

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

Usage is only implied: the phrase 'apply fields and tags together' suggests using this instead of separate tag/field updates, but there is no explicit when-to-use, when-not-to-use, or named alternative among the many sibling write tools (tags_replace, editors_updateDraft, notes_validate).

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