anki-workflow-mcp

Overview Schema Source Related Servers Discussions Admin

Deck Hierarchy Get

deck_hierarchy_get

Retrieve the registered Anki deck hierarchy for 02_MEDICINA_AnkiMBR, optionally filtering by sub-path or depth. Return a list or visual tree to inspect deck structure before generating cards.

Instructions

Get the registered deck hierarchy for 02_MEDICINA_AnkiMBR. filter_prefix: optional sub-path filter (e.g. '02_MEDICINA_AnkiMBR::Ciclo Clínico::Neurologia'). max_depth: max nesting level to include (default 10). format_tree: if true, returns an ASCII/Unicode visual tree instead of list.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "deck_hierarchy_get"
  }
}

Input Schema

Name	Required	Default
`max_depth`	No
`format_tree`	No
`filter_prefix`	No	02_MEDICINA_AnkiMBR

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.1Nov 14, 2026

TDQS

B3.2/5.0

Behavior3/5

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

No annotations are supplied, so the description carries the full burden; it does establish that this is a read operation and that output can be a visual tree or a flat list, plus the default nesting level. It omits what happens when filter_prefix matches nothing, whether results come from a registry/cache or are re-read, and whether default 10 silently truncates deeper decks.

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?

One front-loaded sentence for purpose followed by three tight, labeled parameter clauses; almost no waste. The only inefficiency is repeating the deck-name literal in both the purpose sentence and the example path.

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?

An output schema exists, so return values need not be explained, and the description correctly focuses on parameters and the tree-vs-list choice. The remaining gap is that it treats 02_MEDICINA_AnkiMBR as fixed without saying whether a caller can inspect any other deck tree, which matters given the surrounding multi-deck operations.

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 0%, so the description must compensate: it explains filter_prefix with a concrete example path and states the default max_depth of 10 along with the tree/list toggle. However, it never states the filter_prefix default (02_MEDICINA_AnkiMBR) or what depth truncation does, so the schema and description each hold half the picture.

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 opens with a specific verb and resource ("Get the registered deck hierarchy for 02_MEDICINA_AnkiMBR"), which tells an agent exactly what is returned. It is not tautological, but it does not contrast itself with siblings such as deck_hierarchy_search or deck_hierarchy_add, so differentiation relies on the reader inferring from the verb.

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 statement of when to use this rather than deck_hierarchy_search or deck_hierarchy_sync. The only situational guidance is implicit in the parameter descriptions (e.g. use filter_prefix to narrow to a sub-path), which is thin for a family of five similarly named hierarchy tools.

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

Deploy Server