Skip to main content
Glama

Flash

by com.flashmemorize
OverviewDiscussionsAdmin

submit_review

Record the user's result on a card and get the next one. Grade STRICTLY against the card's back: facts, numbers, doses, and units must match precisely. An imprecise answer is 1 (Again), never 'close enough'; only phrasing may differ. Part of an answer is a miss, so '60' for '60 to 100 bpm' is 1. 1=Again (wrong, blank, or anything the card asks for left out), 2=Hard (the whole answer, but slowly or unsurely), 3=Good (the whole answer), 4=Easy (the whole answer at once). 2, 3 and 4 all record that the user knew it. State the exact answer on a miss, then immediately ask next_card's front. A null next_card ends the session. Wrap up briefly.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ratingYes1=Again 2=Hard 3=Good 4=Easy
card_idYes
session_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoPresent only when the queue is empty: why, and what to do next.
recordedYes
next_cardNoNext card to ask immediately, or null when the session is finished.
remainingYesCards left in the queue.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • changedOutput schema / $defs / CardFrontOut / description
      Previous value: -"One card front for the assistant to ask."New value: +"Rich question only. Editable source is deliberately absent during study."
    • removedOutput schema / $defs / CardFrontOut / properties / front
      Removed value: -{
-  "description": "The question side; ask it and wait for the user's answer.",
-  "type": "string"
-}
    • addedOutput schema / $defs / CardFrontOut / properties / front_html
      Added value: +{
+  "type": "string"
+}
    • addedOutput schema / $defs / CardFrontOut / properties / media
      Added value: +{
+  "items": {
+    "$ref": "#/$defs/MediaOut"
+  },
+  "type": "array"
+}
    • removedOutput schema / $defs / CardFrontOut / properties / spoken_front
      Removed value: -{
-  "description": "The question as it should be read aloud: a cloze gap is the word\n\"blank\", a picture is described, a formula is named. Speak this\nrather than `front` when talking.",
-  "type": "string"
-}
    • changedOutput schema / $defs / CardFrontOut / required
      Previous value: -[
-  "card_id",
-  "front",
-  "spoken_front"
-]New value: +[
+  "card_id",
+  "front_html",
+  "media"
+]
    • addedOutput schema / $defs / MediaOut
      Added value: +{
+  "properties": {
+    "filename": {
+      "type": "string"
+    },
+    "media_id": {
+      "format": "int64",
+      "type": "integer"
+    },
+    "mime": {
+      "type": "string"
+    },
+    "size": {
+      "format": "uint64",
+      "minimum": 0,
+      "type": "integer"
+    },
+    "url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "media_id",
+    "url",
+    "mime",
+    "filename",
+    "size"
+  ],
+  "type": "object"
+}
  2. Changed2 schema fields changed
    • addedOutput schema / $defs / CardFrontOut / properties / spoken_front
      Added value: +{
+  "description": "The question as it should be read aloud: a cloze gap is the word\n\"blank\", a picture is described, a formula is named. Speak this\nrather than `front` when talking.",
+  "type": "string"
+}
    • changedOutput schema / $defs / CardFrontOut / required
      Previous value: -[
-  "card_id",
-  "front"
-]New value: +[
+  "card_id",
+  "front",
+  "spoken_front"
+]
  3. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations are thin (only title and false hints), so the description carries the behavioral burden and does so thoroughly. Beyond the 'Record' mutation implied by readOnlyHint=false, it discloses the return behavior (next_card, null ends session), the requirement to state the exact answer on a miss, and the semantic quirk that 2, 3, and 4 all count as 'knew it.' No contradiction with annotations.

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 long (~150 words) but every sentence earns its place: the grading rubric is essential for correct invocation and would be dangerous to compress. The core purpose is front-loaded, followed by grading details in logical order. Minor redundancy exists (the 'only phrasing may differ' point is restated via the bpm example) but nothing is wasted.

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?

For a tool with this grading complexity, the description is nearly complete: it specifies all rating semantics, the miss-handling protocol, and session termination. Since an output schema exists, it need not detail the return structure, though mentioning next_card bridges nicely. A small gap is the lack of explicit words on what session_id and card_id refer to, but the names plus narrative cover it.

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

Parameters4/5

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

Schema description coverage is only 33% (rating has a one-line enum-like description; session_id and card_id have none). The description compensates substantially for rating, defining each level with precise criteria ('the whole answer, but slowly or unsurely' for Hard) and giving a concrete partial-answer example. It does not touch session_id/card_id, but their meanings are self-evident from names and workflow context.

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 opens with a specific verb+resource pair: 'Record the user's result on a card and get the next one.' This clearly distinguishes it from siblings like show_answer (which merely displays the answer), start_study_session, and end_session. The exhaustive grading rubric further pins down exactly what the tool does.

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 establishes unambiguous context: it is used during an active study flow when the user has just answered a card, and it elaborates on how to handle each scenario (miss, unsure, easy, null next_card, wrap-up). It does not explicitly name alternatives or state when not to use it, but the placement in the workflow is unmistakable.

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

All Flash toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources