anki-workflow-mcp

Overview Schema Source Related Servers Discussions Admin

Validate Notes

validate_notes

Checks optional Anki QA explanation notes for metadata, duplicate answers, exam-only mentions, length, and style issues, returning a validation profile to guide fixes.

Instructions

Validate the 'Notas Adicionais' optional explanation field (same unit, authorized source; empty/short notes allowed with no minimum volume and variable depth). Checks: NOTE.METADATA (CRITICAL), NOTE.DUP_ANSWER_WARN (normalized HTML/entity/punctuation exact repeat), NOTE.EXAM_ONLY_WARN (exam mention without explanation), NOTE.LENGTH_WARN, NOTE.STYLE_WARN. Returns information_profile (note_type='QA', prompt_available=False limitation noted).

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": {
      "notes": "<notes>"
    },
    "name": "validate_notes"
  }
}

Input Schema

Name	Required	Description	Default
`row`	No
`notes`	Yes
`answer`	No
`max_length`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.1Nov 14, 2026

TDQS

B3/5.0

Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose the validation checks, the allowance for empty or short notes, and a return-profile limitation. However, it does not state whether the tool is read-only, whether it mutates anything, or how validation failures are surfaced.

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 description is front-loaded with the purpose and packs the check list efficiently into a few sentences. Some phrasing such as 'same unit, authorized source' is cryptic, but the overall structure is compact and purposeful.

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?

An output schema exists, so return values need not be fully explained, and the description does cover the checks and the note-type limitation. Still, for a four-parameter validation tool with zero annotation coverage, the missing row and max_length explanations leave the definition incomplete.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate, but it only partially does: it explains that notes is an optional explanation field and implies answer is used by the duplicate-answer check. It never explains the row or max_length parameters, leaving half the inputs undocumented.

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?

The description states a specific verb and resource: 'Validate the Notas Adicionais optional explanation field,' and lists the concrete check codes it runs. It is clearly about validating the notes field, though it does not explicitly contrast itself with sibling validators such as validate_qa or validate_hints.

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 explicit when-to-use or when-not-to-use guidance, and no alternative sibling tool is named. The target field implies the context, but the agent must infer selection among many validate_* tools.

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

Deploy Server