get_queueCards due now and due within the next 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | ||
| lang | No | Language tag of the queue: base ISO with an optional region (en, en-us, pt-br). Omit it and the user's own primary learning language is used. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / properties / lang / descriptionAdded value: +"Language tag of the queue: base ISO with an optional region (en, en-us, pt-br). Omit it and the user's own primary learning language is used."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile, and the description adds a useful temporal behavior detail. However, it does not disclose ordering, pagination, how overdue cards are treated, or what the returned objects contain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the core meaning, making it highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only queue lookup, the description captures the essential return criterion and pairs well with the readOnlyHint annotation. However, the absence of an output schema and the unstated meaning of 'max' leave some details to be inferred.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about either parameter. The schema describes 'lang' well but leaves 'max' with only min/max bounds, so the agent must infer that 'max' caps the returned queue size; with 50% schema coverage, the description should have compensated but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's purpose: it returns cards that are due now or within the next 24 hours. This specific time-based scope distinguishes it from siblings like get_known_words or get_active_vocab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The selection criterion is explicit ('due now' and 'due within the next 24 hours'), giving clear context for when an agent should request this queue. It does not explicitly name alternatives or exclusions, but the intended usage is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools cleanly separate single-card lookup, batch lookup, due queue, event log, and SRS adjustments. The main overlap is `get_system_instructions` and `get_user_profile`, which both return CEFR level, languages, due count, and weak words, so an agent could mis-select between them.
Every tool follows a consistent lowercase snake_case verb_noun pattern: capture_*, get_*, mark_*, log_*, check_. The verbs are descriptive and predictable, making the set easy to navigate.
13 tools is well within the ideal scope for a language-learning memory/assistant server. Each tool covers a distinct part of the capture, lookup, review, and spaced-repetition workflow without feeling padded.
The core lifecycle is well covered: grammar and vocabulary capture, batch deck checks, card detail, due queue, recent activity, and SRS boosts/penalties. Minor gaps exist: captured grammar mistakes have no retrieval endpoint, and there is no delete/dismiss path for unwanted cards, but agents can work around these.