ExpenseBot

get_last_receipt_result

Read-only

Check the authoritative final outcome of a receipt image/PDF batch submitted with submit_receipt. After submit_receipt returns submissionId, call this tool with that exact ID using the polling interval and time allowance in the submit_receipt response. A small batch allows at least 5 minutes; larger batches allow longer. A pending result is normal and must not trigger a duplicate resubmission. Returns added, duplicate, skipped, held_for_review, or errored verdicts with exact counts and up to 10 processed receipt summaries. A held_for_review file (withheld for missing details or a possible duplicate) was not added; relay the next step in the message. found:false is pending and has no terminal verdict; found:true is terminal. On completion, report the authoritative per-file outcomes. Show spreadsheetUrl and reviewExpensesUrl for rows actually added, not as the destination for held files. For a held file relay only its message's next step (such as Files to review on Add Expenses); do not invent a missing card or direct held uploads to Gmail Action Needed. Unknown outcomes stay unknown; do not blindly resubmit. This is for uploaded receipts; use get_scan_status for Gmail scans. Read-only.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`submissionId`	No	Exact submissionId returned by submit_receipt. Strongly preferred because it binds the result to this upload instead of an earlier receipt.
`withinSeconds`	No	Fallback lookback window when submissionId is unavailable (30-3600 seconds; default 600).

Output Schema

TableJSON Schema

Name	Required	Description
`data`	No
`found`	Yes
`state`	No	Present on pending polls for a specific submission.
`counts`	No
`message`	Yes
`success`	Yes
`verdict`	No	Terminal branch only. held_for_review: every file was held for review, so none was added. mixed also covers any batch that includes held files.
`receipts`	No	Processed receipt summaries. Held files are not listed here; see data.outcomes.
`timestamp`	No
`submissionId`	No
`spreadsheetUrl`	No
`reviewExpensesUrl`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 2, 2026

addedOutput schema / properties / counts / properties / heldForReview

Added value: +{
+  "description": "Files held for review and not added. Present only when at least one.",
+  "minimum": 0,
+  "type": "integer"
+}

addedOutput schema / properties / receipts / description

Added value: +"Processed receipt summaries. Held files are not listed here; see data.outcomes."

changedOutput schema / properties / verdict / description

Previous value: -"Terminal branch only."New value: +"Terminal branch only. held_for_review: every file was held for review, so none was added. mixed also covers any batch that includes held files."

changedOutput schema / properties / verdict / enum

Previous value: -[
-  "added",
-  "duplicate",
-  "skipped",
-  "errored",
-  "mixed",
-  "unknown"
-]New value: +[
+  "added",
+  "duplicate",
+  "skipped",
+  "errored",
+  "mixed",
+  "unknown",
+  "held_for_review"
+]

Changed18 schema fields changedAug 25, 2026

addedOutput schema / allOf

Added value: +[
+  {
+    "if": {
+      "properties": {
+        "found": {
+          "const": true
+        }
+      },
+      "required": [
+        "found"
+      ]
+    },
+    "then": {
+      "required": [
+        "verdict",
+        "counts",
+        "receipts",
+        "submissionId",
+        "spreadsheetUrl",
+        "reviewExpensesUrl",
+        "data",
+        "timestamp"
+      ]
+    }
+  }
+]

changedOutput schema / description

Previous value: -"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."New value: +"found:false means processing is still pending; found:true is a terminal result."

addedOutput schema / properties / counts

Added value: +{
+  "additionalProperties": true,
+  "properties": {
+    "added": {
+      "minimum": 0,
+      "type": "integer"
+    },
+    "duplicates": {
+      "minimum": 0,
+      "type": "integer"
+    },
+    "errors": {
+      "minimum": 0,
+      "type": "integer"
+    },
+    "skipped": {
+      "minimum": 0,
+      "type": "integer"
+    },
+    "submitted": {
+      "minimum": 0,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "submitted",
+    "added",
+    "duplicates",
+    "skipped",
+    "errors"
+  ],
+  "type": "object"
+}

removedOutput schema / properties / data / description

Removed value: -"Structured payload. Shape varies per tool — common keys: total, breakdown, comparison, sampleMeta, ids, expenseId, reportId, signupUrl, results."

removedOutput schema / properties / error

Removed value: -{
-  "additionalProperties": true,
-  "description": "Present only when success === false.",
-  "properties": {
-    "code": {
-      "type": "string"
-    },
-    "hint": {
-      "type": "string"
-    },
-    "message": {
-      "type": "string"
-    }
-  },
-  "type": "object"
-}

addedOutput schema / properties / found
```
Added value: +{
+  "type": "boolean"
+}
```

removedOutput schema / properties / message / description

Removed value: -"Human-readable result text. Always present on success; prefer rendering this verbatim before any further reasoning."

addedOutput schema / properties / receipts

Added value: +{
+  "items": {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / reviewExpensesUrl
```
Added value: +{
+  "type": "string"
+}
```

removedOutput schema / properties / sampleMeta

Removed value: -{
-  "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"
-}

addedOutput schema / properties / spreadsheetUrl

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / state

Added value: +{
+  "const": "processing",
+  "description": "Present on pending polls for a specific submission.",
+  "type": "string"
+}

addedOutput schema / properties / submissionId

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / success / const
```
Added value: +true
```

removedOutput schema / properties / success / description

Removed value: -"False on tool errors; check before reading `data`."

addedOutput schema / properties / timestamp

Added value: +{
+  "format": "date-time",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / verdict

Added value: +{
+  "description": "Terminal branch only.",
+  "enum": [
+    "added",
+    "duplicate",
+    "skipped",
+    "errored",
+    "mixed",
+    "unknown"
+  ],
+  "type": "string"
+}

addedOutput schema / required

Added value: +[
+  "success",
+  "found",
+  "message"
+]

First observedAug 10, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only declare readOnlyHint/openWorldHint/destructiveHint, but the description adds substantial behavior: pending is normal and found:false is non-terminal, held_for_review files were not added, unknown outcomes stay unknown, and spreadsheets must not be shown as the destination for held files. This is genuine operational context beyond the safety annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The purpose and trigger are front-loaded, but the description runs long and includes a cluster of guardrail sentences ('do not invent a missing card', 'do not blindly resubmit') that partly repeat the same intent. It is dense and useful but not tightly sized relative to a 2-parameter read-only tool.

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?

An output schema exists, yet the description still supplies the terminal/pending semantics and verdict vocabulary an agent needs to interpret results. For a polling tool with cross-tool dependencies, nothing essential is missing.

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 both submissionId and withinSeconds are already documented, including the 'strongly preferred' rationale and the 30-3600 fallback range. The description reinforces using the exact ID from the submit_receipt response but adds little syntactic or format meaning beyond the schema, matching the baseline 3.

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 ('Check the authoritative final outcome of a receipt image/PDF batch') and ties it to submit_receipt explicitly. It also differentiates from the sibling get_scan_status ('This is for uploaded receipts; use get_scan_status for Gmail scans'), so an agent can pick between them without opening a 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 (call after submit_receipt returns a submissionId, using that exact ID and the polling interval/time allowance from the response) and names the alternative tool plus its condition (Gmail scans -> get_scan_status). It also warns that a pending result must not trigger a duplicate resubmission, which is a clear when-not-to-act rule.

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.