Flash

Start study session

start_study_session

Use this when the user wants to study, review, practice, be quizzed on or drill their flashcards, including cards made moments ago. Starts a spaced-repetition session over the cards due now: all of them, one deck (with its subdecks), or the cards carrying every given tag (list_tags has the names). Progress counts only for cards asked here and graded with submit_review, so ask each card from this session, never from the conversation. To make new cards use create_cards. Returns the first card's front (ask it and wait for the user's answer), how many cards are due, and grading_mode. Render front_html for display or interpret it for speech; present cloze gaps without revealing answers, and never read raw markup or URLs aloud. Fetch media URLs with the connector Bearer token if needed. Follow grading_mode for the whole session. Internal fields (ids, counts) are never read aloud.

Input Schema

TableJSON Schema

Name	Required	Description
`tag`	No	One tag to study, e.g. "exam-2": the same as a `tags` of one.
`deck`	No	Deck name to study (omit to study everything due). A deck includes its subdecks; name Parent::Child to study one subdeck.
`tags`	No	Tags the cards must all carry, e.g. ["exam-2", "cardio"], at most ten. With a deck they narrow that deck. Names come from list_tags.

Output Schema

TableJSON Schema

Name	Required	Description
`note`	No	Present only when the queue is empty: why, and what to do next.
`next_due`	No	Present only when the queue is empty and more cards are coming: when the next ones are due.
`cards_due`	Yes	Cards in this session's queue right now.
`first_card`	No	First card to ask, or null when nothing is due.
`session_id`	Yes
`grading_mode`	Yes	How to report grades for the whole session; follow it exactly.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 29, 2026

addedOutput schema / $defs / NextDueOut

Added value: +{
+  "description": "When the next cards come, for a session with nothing left to study.",
+  "properties": {
+    "at_ms": {
+      "description": "When the first of them is due, in ms since the epoch.",
+      "format": "int64",
+      "type": "integer"
+    },
+    "cards": {
+      "description": "How many come that day.",
+      "format": "uint32",
+      "minimum": 0,
+      "type": "integer"
+    },
+    "in_days": {
+      "description": "Study days away: 1 is tomorrow, 0 later today.",
+      "format": "uint32",
+      "minimum": 0,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "at_ms",
+    "in_days",
+    "cards"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / next_due

Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/$defs/NextDueOut"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Present only when the queue is empty and more cards are coming:\nwhen the next ones are due."
+}

Changed1 schema field changedSep 27, 2026

removedOutput schema / properties / study_panel

Removed value: -{
-  "description": "Present when this host shows Flash's study panel: how to run the\nsession alongside it.",
-  "type": [
-    "string",
-    "null"
-  ]
-}

Changed1 schema field changedSep 27, 2026

addedOutput schema / properties / study_panel

Added value: +{
+  "description": "Present when this host shows Flash's study panel: how to run the\nsession alongside it.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

Changed2 schema fields changedSep 21, 2026

changedInput schema / properties / tag / description

Previous value: -"Tag to study, e.g. \"exam-2\" (ignored when deck is set)."New value: +"One tag to study, e.g. \"exam-2\": the same as a `tags` of one."

addedInput schema / properties / tags

Added value: +{
+  "default": null,
+  "description": "Tags the cards must all carry, e.g. [\"exam-2\", \"cardio\"], at most\nten. With a deck they narrow that deck. Names come from list_tags.",
+  "items": {
+    "type": "string"
+  },
+  "type": [
+    "array",
+    "null"
+  ]
+}

Changed1 schema field changedSep 19, 2026

changedInput schema / properties / deck / description

Previous value: -"Deck name to study (omit to study everything due)."New value: +"Deck name to study (omit to study everything due). A deck includes\nits subdecks; name Parent::Child to study one subdeck."

Changed7 schema fields changedSep 19, 2026

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"
+}

Changed2 schema fields changedSep 17, 2026

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"
+]

First observedSep 9, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations cover safety (readOnlyHint=false, destructiveHint=false, openWorldHint=false); the description adds substantial context beyond them: progress is attributed only to cards asked in this session and graded via submit_review, grading_mode governs the whole session, and media URLs require the connector Bearer token. It omits session lifecycle (how/when it terminates, cf. end_session), which keeps it just short of the top score.

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?

Front-loaded with the usage trigger, then mechanics, then rendering rules — a sensible ordering. It is dense with long compound sentences, and the rendering/grading rules could be tightened, but nearly every clause carries actionable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite an output schema existing, the description usefully supplements it with what matters for correct behavior: ask the returned first card and wait, honor grading_mode, render front_html for display versus speech, present cloze gaps without revealing answers, and never read raw markup, URLs, or internal fields aloud. Complete for the agent's task regardless of the rich structured metadata.

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%, so the schema already documents tag, deck, and tags (including Parent::Child syntax and the ten-tag cap). The description restates the scope semantics without adding new format or edge-case detail, so the baseline 3 applies.

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?

States a specific verb and resource ('Starts a spaced-repetition session over the cards due now') with explicit scope options (all, one deck plus subdecks, or cards carrying every given tag). It actively distinguishes itself from siblings by naming create_cards for card creation and list_tags for tag names, so an agent can route correctly without opening the schema.

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

Usage Guidelines5/5

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

Gives an explicit trigger ('when the user wants to study, review, practice, be quizzed on or drill their flashcards, including cards made moments ago') and routes related intents elsewhere: create_cards for new cards, list_tags for tag names, submit_review for grading. The when-not-to-use boundary is effectively stated.

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

All Flash tools Inspect

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.