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

anki-connect-mcp

by SolarianGG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

scheduling.predict

scheduling_predict
Read-only

Predicts Anki scheduler answers for a card and returns a session-scoped state token for safe subsequent scheduling calls.

Instructions

Predict native answers and issue a session-scoped state token.

Does not represent custom states held by the GUI reviewer. Tokens are invalidated by relevant writes, undo, profile change and scheduler-day rollover.

Anki-Connect method scheduling.predict. Scope: collection. Effect: read. Completion: completed. Undo: none.

Possible errors: collectionUnavailable, internalError, invalidParams, invalidState, 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": {
      "cardId": "<cardId>"
    },
    "name": "scheduling_predict"
  }
}

Input Schema

NameRequiredDescriptionDefault
cardIdYesCard ID (decimal string, e.g. "1700000000001").
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.5/5.0
Behavior4/5

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

Annotations already declare the read-only, non-destructive, closed-world profile, yet the description adds genuinely new behavior: tokens are invalidated by relevant writes, undo, profile change and scheduler-day rollover, and it excludes custom GUI reviewer states. The scope/effect/completion/undo line and the enumerated error set (including staleSession) further help an agent handle failures. Minor deduction because the 'Effect: read. Undo: none.' portion duplicates what the annotations already say.

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

Conciseness3/5

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

The core invalidation semantics are front-loaded in the first two sentences, which is good. The trailing metadata line (method, scope, effect, completion, undo) partly restates the annotations, and the bare error list is useful but terse/undigested. Nothing is egregiously wasteful, but the entry reads like a template block appended to the useful part.

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?

For a read tool with no output schema, the definition never says what a prediction actually returns — per-answer intervals, due dates, a state object — leaving the agent to guess at the response shape it must interpret. Token lifetime and error handling are covered well, so the gap is narrow but real for a two-parameter, output-less tool whose entire value is the returned prediction.

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 both parameters are documented thoroughly in the schema, including the card ID format and the full rationale for the optional `session` field. The description adds nothing about parameters beyond schema content, so the baseline of 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?

The first sentence gives a concrete verb+object ('Predict native answers') plus a secondary output ('issue a session-scoped state token'), which is far more than a restatement of 'scheduling.predict'. It never names a sibling (scheduling_get, scheduling_getQueue, scheduling_answer) to say how it differs, so an agent must infer that this is a preview/simulation step. 'Native answers' is also slightly opaque about what exactly is predicted (per-button intervals vs. next due state).

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 token-staleness sentence hints the result is meant to be consumed by a later write, and the note that it excludes custom GUI states tells you when NOT to rely on it. There is no explicit statement such as 'call before scheduling_answer' or 'use scheduling_get for current scheduling state instead'. The `session` parameter's schema text carries most of the when-to-pass guidance, not the description.

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