ExpenseBot

get_scan_status

Read-only

Check the authoritative status of the user's Gmail receipt scans. Returns the active scan lock, the same live phase and item progress shown by ExpenseBot's in-app status pill, queued or attention-needed years, completed calendar years, current merchant/category exclusions, and recent outcomes. Call when the user asks whether a scan is running, finished, stuck, or what it is doing. When complete, show the returned spreadsheetUrl or reviewExpensesUrl; when setup or reconnection is needed, show gmailScanUrl. Read-only.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`data`	No
`lock`	No	Scan-lock state (active, startedAt, ageSeconds, dispatchComplete, pendingProcessingCount).
`status`	No	Scan lifecycle state.
`message`	No
`success`	Yes
`latestScan`	No	Most recent scan outcome (success, emailsFound, emailsTagged, timestamp).
`gmailScanUrl`	No
`scanInProgress`	No
`spreadsheetUrl`	No
`reviewExpensesUrl`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 9, 2026

changedOutput schema / properties / gmailScanUrl / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

changedOutput schema / properties / latestScan / type

Previous value: -"object"New value: +[
+  "object",
+  "null"
+]

changedOutput schema / properties / reviewExpensesUrl / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

changedOutput schema / properties / spreadsheetUrl / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

changedOutput schema / properties / status / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

Changed1 schema field changedSep 9, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Authoritative live scan state. Fields may sit at the top level or under data depending on the branch; nothing beyond success is guaranteed, so treat each as optional.",
+  "properties": {
+    "data": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "gmailScanUrl": {
+      "type": "string"
+    },
+    "latestScan": {
+      "additionalProperties": true,
+      "description": "Most recent scan outcome (success, emailsFound, emailsTagged, timestamp).",
+      "type": "object"
+    },
+    "lock": {
+      "additionalProperties": true,
+      "description": "Scan-lock state (active, startedAt, ageSeconds, dispatchComplete, pendingProcessingCount).",
+      "type": "object"
+    },
+    "message": {
+      "type": "string"
+    },
+    "reviewExpensesUrl": {
+      "type": "string"
+    },
+    "scanInProgress": {
+      "type": "boolean"
+    },
+    "spreadsheetUrl": {
+      "type": "string"
+    },
+    "status": {
+      "description": "Scan lifecycle state.",
+      "type": "string"
+    },
+    "success": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "success"
+  ],
+  "type": "object"
+}

Changed1 schema field changedAug 25, 2026

changedOutput schema / (root)

Previous value: -{
-  "additionalProperties": true,
-  "description": "Standard ExpenseBot tool result envelope. `message` is the human-readable summary the AI cites; `data` is the structured payload (totals, breakdowns, ids, etc.). On failure, `success` is false and `error` carries a code/message/hint triple.",
-  "properties": {
-    "data": {
-      "additionalProperties": true,
-      "description": "Structured payload. Shape varies per tool — common keys: total, breakdown, comparison, sampleMeta, ids, expenseId, reportId, signupUrl, results.",
-      "type": "object"
-    },
-    "error": {
-      "additionalProperties": true,
-      "description": "Present only when success === false.",
-      "properties": {
-        "code": {
-          "type": "string"
-        },
-        "hint": {
-          "type": "string"
-        },
-        "message": {
-          "type": "string"
-        }
-      },
-      "type": "object"
-    },
-    "message": {
-      "description": "Human-readable result text. Always present on success; prefer rendering this verbatim before any further reasoning.",
-      "type": "string"
-    },
-    "sampleMeta": {
-      "additionalProperties": true,
-      "description": "Set when the underlying dataset was truncated. isTruncated=true means the agent saw a sample of `sampleCount` of `totalCount` rows; aggregate totals are still accurate.",
-      "properties": {
-        "isTruncated": {
-          "type": "boolean"
-        },
-        "sampleCount": {
-          "type": "integer"
-        },
-        "totalCount": {
-          "type": "integer"
-        }
-      },
-      "type": "object"
-    },
-    "success": {
-      "description": "False on tool errors; check before reading `data`.",
-      "type": "boolean"
-    }
-  },
-  "type": "object"
-}New value: +null

First observedAug 10, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only.' It goes beyond the annotations by detailing the fields returned (spreadsheetUrl, reviewExpensesUrl, gmailScanUrl) and instructing which to display under which condition, plus noting the data mirrors the in-app status pill. No contradictions 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: it opens with the core purpose, then lists returned data, then gives usage triggers and follow-up actions, and closes with 'Read-only.' Every sentence adds value; it is compact without being terse, and the most critical info (purpose and when to call) is front-loaded.

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 read-only status tool with no parameters and an output schema (which presumably documents the return structure), the description covers the essential agent needs: what it returns, when to call, and how to act on the results. It could mention edge cases (e.g., no active scan) but these are likely implied by the output schema, so it is sufficiently complete.

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 tool has zero parameters, so the description carries no parameter burden. The baseline for 0 parameters is 4, and the description adds no unnecessary parameter info. Schema coverage is trivially 100% (empty schema), so this score is appropriate.

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 and resource: 'Check the authoritative status of the user's Gmail receipt scans.' It enumerates the exact returned data (scan lock, live phase, item progress, years, exclusions, outcomes) and explicitly ties it to a status-pill context, which clearly differentiates it from siblings like scan_gmail (which initiates scans) and get_last_receipt_result (which returns a single result).

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 gives an explicit trigger: 'Call when the user asks whether a scan is running, finished, stuck, or what it is doing.' It also provides follow-up actions (show spreadsheetUrl/reviewExpensesUrl when complete, gmailScanUrl when setup needed). However, it does not explicitly state when NOT to use it or name alternative tools, so it lacks exclusions.

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

All ExpenseBot 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.