Skip to main content
Glama

Flash

by com.flashmemorize
OverviewDiscussionsAdmin

List cards

list_cards
Read-only

Use this when the user wants to see, find or check their cards, and before update_cards or delete_cards. Returns whole cards and editable sources, newest first, by deck or search text, with authenticated media URLs (GET with the connector Bearer token; never speak URLs or markup). Sources show cloze answers, so quiz with start_study_session. Edits to a shared source reach its sibling_card_ids. Page with next_cursor as before_card_id while has_more; trust has_more, not the count.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
deckNoFilter to one deck by name.
limitNoCards per page, 1-500; 50 when omitted.
searchNoSubstring search over fronts and backs.
before_card_idNoFor the next page: the next_cursor the previous page returned.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
cardsYes
has_moreYes
next_cursorNo
total_countYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / before_card_id / description
      Added value: +"For the next page: the next_cursor the previous page returned."
    • addedInput schema / properties / limit / description
      Added value: +"Cards per page, 1-500; 50 when omitted."
  2. Changed19 schema fields changed
    • addedInput schema / properties / before_card_id
      Added value: +{
+  "format": "int64",
+  "type": [
+    "integer",
+    "null"
+  ]
+}
    • removedOutput schema / $defs / CardOut / properties / back
      Removed value: -{
-  "type": "string"
-}
    • addedOutput schema / $defs / CardOut / properties / back_html
      Added value: +{
+  "type": "string"
+}
    • addedOutput schema / $defs / CardOut / properties / cloze_index
      Added value: +{
+  "format": "uint32",
+  "minimum": 0,
+  "type": [
+    "integer",
+    "null"
+  ]
+}
    • addedOutput schema / $defs / CardOut / properties / deck_id
      Added value: +{
+  "format": "int64",
+  "type": "integer"
+}
    • removedOutput schema / $defs / CardOut / properties / front
      Removed value: -{
-  "type": "string"
-}
    • addedOutput schema / $defs / CardOut / properties / front_html
      Added value: +{
+  "type": "string"
+}
    • addedOutput schema / $defs / CardOut / properties / media
      Added value: +{
+  "items": {
+    "$ref": "#/$defs/MediaOut"
+  },
+  "type": "array"
+}
    • addedOutput schema / $defs / CardOut / properties / ord
      Added value: +{
+  "format": "uint32",
+  "minimum": 0,
+  "type": "integer"
+}
    • addedOutput schema / $defs / CardOut / properties / source
      Added value: +{
+  "$ref": "#/$defs/SourceOut"
+}
    • removedOutput schema / $defs / CardOut / properties / tags
      Removed value: -{
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}
    • addedOutput schema / $defs / CardOut / properties / type_answer
      Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • changedOutput schema / $defs / CardOut / required
      Previous value: -[
-  "card_id",
-  "front",
-  "back",
-  "tags"
-]New value: +[
+  "card_id",
+  "deck_id",
+  "ord",
+  "front_html",
+  "back_html",
+  "source",
+  "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"
+}
    • addedOutput schema / $defs / SourceOut
      Added value: +{
+  "properties": {
+    "back_html": {
+      "type": "string"
+    },
+    "front_html": {
+      "type": "string"
+    },
+    "note_id": {
+      "format": "int64",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "note_type": {
+      "type": "string"
+    },
+    "read_only_reason": {
+      "description": "Non-null when a legacy import lacks a lossless editable source.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "sibling_card_ids": {
+      "items": {
+        "format": "int64",
+        "type": "integer"
+      },
+      "type": "array"
+    },
+    "tags": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "note_type",
+    "front_html",
+    "back_html",
+    "tags",
+    "sibling_card_ids"
+  ],
+  "type": "object"
+}
    • addedOutput schema / properties / has_more
      Added value: +{
+  "type": "boolean"
+}
    • addedOutput schema / properties / next_cursor
      Added value: +{
+  "format": "int64",
+  "type": [
+    "integer",
+    "null"
+  ]
+}
    • addedOutput schema / properties / total_count
      Added value: +{
+  "format": "uint32",
+  "minimum": 0,
+  "type": "integer"
+}
    • changedOutput schema / required
      Previous value: -[
-  "cards"
-]New value: +[
+  "cards",
+  "total_count",
+  "has_more"
+]
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the read-only/non-destructive profile, yet the description adds substantial behavior: newest-first ordering, authenticated media URLs requiring a Bearer token GET (never speak URLs or markup), sources exposing cloze answers, shared-source edits propagating to sibling_card_ids, and pagination mechanics. This is well beyond what the structured fields convey.

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?

Dense and front-loaded, with the usage trigger first and pagination/auth/domain caveats after. Every clause carries information, though the single long paragraph is heavier than strictly necessary.

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 the schema and output schema already existing, the description supplies everything an agent needs to call and consume the result correctly: filtering, ordering, media auth, source/cloze semantics, sibling propagation, and pagination termination. Nothing material is left to inference.

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 coverage is 100%, so the baseline is 3. The description adds genuine meaning beyond it: 'by deck or search text' clarifies the two filters combine as selectors, and 'Page with next_cursor as before_card_id while has_more; trust has_more, not the count' explains the cursor's role and the correct loop-termination signal.

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+resource ('see, find or check their cards'), scopes the return ('whole cards and editable sources, newest first, by deck or search text'), and explicitly distinguishes itself from update_cards, delete_cards and start_study_session. An agent can route to it 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 explicit when-to-use ('when the user wants to see, find or check their cards') and a prerequisite ordering ('before update_cards or delete_cards'), plus a routing rule away to start_study_session for quizzing. Alternatives and conditions are named, not implied.

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