Council of AI GSPC

List signed card index rows

list_cards

Read-onlyIdempotent

The published signed-card index (https://councilof.ai/signed/card_index.json): what the index declares (n_cards) and how many rows it actually carries, reported next to — never reconciled with — the count the card store endpoint (https://councilof.ai/api/cards) reports for itself. Two labelled numbers from two surfaces; if they disagree, this tool shows the disagreement rather than picking one. Optional filters return recent rows: axis, limit.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`axis`	No	Only list rows whose axis matches this name (case-insensitive).
`limit`	No	How many rows to include in the listing (newest first). Default 10. The two counts are always reported in full regardless of this limit.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`rows`	No
`index`	No
`doctrine`	No
`axis_query`	No
`not_a_certification`	No
`card_store_count_endpoint`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 26, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "axis_query": {
+      "properties": {
+        "asked": {
+          "type": "string"
+        },
+        "canonical": {
+          "type": "string"
+        },
+        "index_names_matched": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "spellings": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        }
+      },
+      "type": "object"
+    },
+    "card_store_count_endpoint": {
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "doctrine": {
+      "type": "string"
+    },
+    "index": {
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "not_a_certification": {
+      "type": "boolean"
+    },
+    "rows": {
+      "items": {
+        "properties": {
+          "axis": {
+            "type": "string"
+          },
+          "card": {
+            "type": "string"
+          },
+          "signed": {},
+          "ts": {}
+        },
+        "type": "object"
+      },
+      "type": [
+        "array",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

Changed1 schema field changedSep 26, 2026

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "axis_query": {
-      "properties": {
-        "asked": {
-          "type": "string"
-        },
-        "canonical": {
-          "type": "string"
-        },
-        "index_names_matched": {
-          "items": {
-            "type": "string"
-          },
-          "type": "array"
-        },
-        "spellings": {
-          "items": {
-            "type": "string"
-          },
-          "type": "array"
-        }
-      },
-      "type": "object"
-    },
-    "card_store_count_endpoint": {
-      "type": [
-        "object",
-        "null"
-      ]
-    },
-    "doctrine": {
-      "type": "string"
-    },
-    "index": {
-      "type": [
-        "object",
-        "null"
-      ]
-    },
-    "not_a_certification": {
-      "type": "boolean"
-    },
-    "rows": {
-      "items": {
-        "properties": {
-          "axis": {
-            "type": "string"
-          },
-          "card": {
-            "type": "string"
-          },
-          "signed": {},
-          "ts": {}
-        },
-        "type": "object"
-      },
-      "type": [
-        "array",
-        "null"
-      ]
-    }
-  },
-  "type": "object"
-}New value: +null

Changed1 schema field changedSep 26, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "axis_query": {
+      "properties": {
+        "asked": {
+          "type": "string"
+        },
+        "canonical": {
+          "type": "string"
+        },
+        "index_names_matched": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "spellings": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        }
+      },
+      "type": "object"
+    },
+    "card_store_count_endpoint": {
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "doctrine": {
+      "type": "string"
+    },
+    "index": {
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "not_a_certification": {
+      "type": "boolean"
+    },
+    "rows": {
+      "items": {
+        "properties": {
+          "axis": {
+            "type": "string"
+          },
+          "card": {
+            "type": "string"
+          },
+          "signed": {},
+          "ts": {}
+        },
+        "type": "object"
+      },
+      "type": [
+        "array",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

First observedSep 5, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, so the description's added value is the countable behavioral nuance: it shows disagreement rather than picking one, and the counts are 'reported next to' each other rather than merged. It also discloses that filters only affect rows, not the two full counts, which is useful beyond the schema.

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 resource URL and the core comparison behavior, and every sentence contributes meaning. The first sentence is somewhat dense with nested clauses, but that density is justified by the nuanced behavior it must convey.

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?

With an output schema present and full parameter schema coverage, the description needn't explain return values or parameter syntax. It adequately covers the tool's distinguishing behavior, the never-reconcile boundary, and the filter behavior, leaving no major gap for invocation decisions.

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 coverage is 100%, so the input schema already documents both axis and limit. The description merely restates them as 'Optional filters return recent rows: axis, limit' and adds no new parameter-level detail beyond the schema.

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 names the resource ('published signed-card index'), the verb ('list'), and a highly specific behavior: reporting the declared n_cards, the actual row count, and the card-store endpoint count side by side without reconciling them. This is far more than a restatement of the title and clearly separates it from generic card-listing tools.

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?

It gives a clear context for use by explaining that the tool intentionally reports two counts from two surfaces and 'never reconciles' them, so an agent knows it should not be used when a single reconciled answer is needed. However, it does not explicitly name sibling alternatives or say 'use X when Y', so it stops short of full routing guidance.

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

All Council of AI GSPC 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.

List signed card index rows

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources