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

anki-connect-mcp

by SolarianGG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

notes.validate

notes_validate
Read-only

Validate note fields and duplicate scope before creating notes without acquiring media; content failures return issues.

Instructions

Validate note content and duplicate scope without acquiring media.

Semantic content failures return valid=false and issues; bad references or parameter types are RPC errors.

Anki-Connect method notes.validate. 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": {
      "note": "<note>"
    },
    "name": "notes_validate"
  }
}

Input Schema

NameRequiredDescriptionDefault
noteYesNote to check, shaped like the `notes_create` arguments: {noteType, deck, fields, tags?, duplicates?}.
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?

Annotations already cover the read-only, non-destructive profile, yet the description adds real behavioral detail: semantic content failures surface as valid=false with issues, while bad references or parameter types become RPC errors. It also enumerates environment scope and possible error codes. It stops short of describing the success payload or the shape of 'issues', but this substantially exceeds 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.

Conciseness4/5

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

The behavioral content is front-loaded in the first two sentences, which is the right structure. The metadata block (Anki-Connect method, scope, effect, completion, undo) and the error list are somewhat boilerplate, but they are compact and clearly separated rather than buried in prose.

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 read-only validation tool with a nested note object and no output schema, the definition covers failure semantics and error codes well enough to call it correctly. The main gap is that the successful return value (beyond the valid=false case) is never described, despite there being no output schema to fall back on.

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%, so both parameters are already documented, including the note shape and the session fallback behavior. The description restates the duplicate-scope concern and the note payload shape but adds no syntax or format guidance beyond the schema, so the baseline 3 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?

States a specific verb+resource ('Validate note content and duplicate scope') and adds a scope nuance about media not being acquired. It is clearly a dry-run check rather than a mutation. However, it never distinguishes itself from the closely named sibling notes_validateMany or from notes_create, leaving the agent to infer the single-vs-batch split.

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 tool checks a note without acquiring media, which hints at a pre-flight check before notes_create. There is no explicit 'use this when...' statement and no named alternative such as notes_validateMany for batches, so the agent must infer routing.

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