Skip to main content
Glama
Hemosoo

learning-tool-mcp

by Hemosoo

get_due_items

Retrieve study items due for review, sorted by most overdue first with SM-2 spaced repetition. Includes never-reviewed items so you can pick what to study next.

Instructions

Return the study items due for review now, most overdue first, scheduled with the SM-2 spaced-repetition algorithm. Never-reviewed items are included after the overdue ones. Use this to pick what to study next. In hosts that support MCP Apps, calling this renders the interactive study widget.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
document_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses the ordering behavior, inclusion of never-reviewed items, and the side effect of rendering an interactive study widget in supporting hosts. It does not mention whether calling this modifies state (e.g., resets due dates), but the described behavior is otherwise transparent.

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

Conciseness5/5

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

Three sentences, each earning its place: the first defines the core behavior and ordering, the second gives the usage directive, and the third discloses the widget side effect. Information is front-loaded and there is no filler.

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?

The tool has a single required parameter, an output schema, and a clear behavioral description. The only missing context is the meaning of document_id and whether the call has side effects on scheduling state, but for a simple retrieval-style tool this is nearly complete.

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 does not explain what document_id means or how it filters the due items, leaving the agent to infer that it identifies the document whose items are due. This is a gap, but the single parameter is self-descriptive enough to be minimally adequate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Return'), a specific resource ('study items due for review now'), and a precise ordering rule ('most overdue first'), which clearly distinguishes it from siblings like get_study_items. It also explains the inclusion of never-reviewed items, adding scope precision.

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

Usage Guidelines4/5

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

The description explicitly says 'Use this to pick what to study next,' giving a clear usage context. It does not explicitly name alternatives or when-not-to-use, but the sibling list and the specific due-item scope make the intended use unambiguous.

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