Flash

start_study_session

Start a study session. REQUIRED whenever the user asks to study, review, practice, quiz, test, or drill their cards, even cards created moments ago in this chat. Do not quiz from memory: only sessions record progress. Narrow it with deck, with tags (the cards must carry all of them; list_tags has the names), or with both. Returns the first card's front (ask it aloud 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.
`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.

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.8/5.0

Behavior5/5

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

Beyond the annotations, the description discloses important behaviors: it returns the first card front, the due count, and grading_mode; tells the agent to render or interpret front_html, present cloze gaps without revealing answers, and fetch media URLs with the Bearer token. This is rich, actionable behavioral context that the annotations alone do not provide.

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 front-loaded with the key trigger conditions and then moves from parameter guidance to output handling. It is longer than necessary, but nearly every sentence carries operational value, and the structure groups related guidance logically.

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?

Given the presence of an output schema, the description still covers the critical runtime behaviors: how to present the first card, how to count due cards, how to follow grading_mode, how to handle media, and what not to read aloud. An agent has enough context to invoke the tool and handle its result correctly.

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?

The input schema already covers all three parameters at 100% coverage, so the baseline is 3. The description adds value by clarifying that tags must all match, that names come from list_tags, and that tags can narrow a deck, which goes beyond the individual schema descriptions.

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 clearly states the action ('Start a study session') and expands it with a precise list of triggering user intents: study, review, practice, quiz, test, or drill cards. This makes it unambiguous and distinct from sibling tools like end_session or list_cards.

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?

It explicitly says the tool is REQUIRED for a defined set of user requests, and even warns not to quiz from memory because only sessions record progress. It also explains how to narrow the session using deck, tags, or both, giving clear decision guidance.

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.