ExpenseBot

send_report_to_accounting

Review and then post an ExpenseBot report to the owner's accounting destination. STEP 1: call with provider, reportId, and optional mode/mappings, without confirm. The server reads the live report and destination, applies Omit/Personal/split/date/currency rules, checks Zoho bank-feed matches, and returns the complete proposal plus proposalId. NOTHING is posted in step 1. Show the complete proposal and ask for approval. STEP 2: call with only provider, proposalId, and confirm:true. The server posts only the frozen, account-bound proposal, revalidates live state, and rejects changed reports or mappings. Never add mapping fields to the confirmation call. Owner accounts only; acting for a client is not supported. Agent-driven posting is currently available only for Zoho Books (zoho_books); QuickBooks Online, Xero, Wave, and FreeAgent are intentionally not accepted by this tool yet because their previews cannot freeze/revalidate the canonical provider plan that shareReport executes. Use those providers' web flows until they satisfy the full push contract.

Input Schema

TableJSON Schema

Name	Required	Description
`mode`	No	Step 1 only (Zoho Books): automatic document treatment, paid expenses, or bills.
`confirm`	No	Step 2 only: true posts the exact staged proposal. No other options may change.
`provider`	Yes	Accounting destination provider. Agent-driven posting is currently available only for Zoho Books.
`reportId`	No	Step 1 only: ExpenseBot report ID owned by the signed-in account.
`proposalId`	No	Step 2 only: proposalId returned by the read-only preview.
`forceRepush`	No	Step 1 only: explicitly include disclosed uncertain prior outcomes in the frozen proposal.
`taxMappings`	No	Step 1 only: observed tax-rate string to live destination tax ID overrides.
`accountMappings`	No	Step 1 only: ExpenseBot category to live destination account ID overrides.
`reportingTagMappings`	No	Step 1 only: ExpenseBot tag to live destination reporting-tag option.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`phase`	Yes
`units`	No
`counts`	No
`created`	No
`success`	Yes
`provider`	Yes
`reportId`	No
`expiresAt`	No
`proposalId`	Yes
`finalAnswer`	No
`organization`	No
`matchedExisting`	No
`omittedExpenses`	No
`idempotentReplay`	No
`responseGuidance`	No
`confirmationContract`	No
`confirmationQuestion`	No
`confirmationRequired`	No
`skippedAlreadyPushed`	No
`reconciliationRequired`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 9, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "allOf": [
+    {
+      "if": {
+        "properties": {
+          "phase": {
+            "const": "preview"
+          }
+        },
+        "required": [
+          "phase"
+        ]
+      },
+      "then": {
+        "required": [
+          "expiresAt",
+          "confirmationRequired",
+          "confirmationQuestion",
+          "confirmationContract"
+        ]
+      }
+    },
+    {
+      "if": {
+        "properties": {
+          "phase": {
+            "const": "completed"
+          }
+        },
+        "required": [
+          "phase"
+        ]
+      },
+      "then": {
+        "required": [
+          "reportId",
+          "finalAnswer",
+          "responseGuidance"
+        ]
+      }
+    }
+  ],
+  "properties": {
+    "confirmationContract": {
+      "type": "string"
+    },
+    "confirmationQuestion": {
+      "type": "string"
+    },
+    "confirmationRequired": {
+      "type": "boolean"
+    },
+    "counts": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "created": {
+      "minimum": 0,
+      "type": "integer"
+    },
+    "expiresAt": {
+      "format": "date-time",
+      "type": "string"
+    },
+    "finalAnswer": {
+      "type": "string"
+    },
+    "idempotentReplay": {
+      "type": "boolean"
+    },
+    "matchedExisting": {
+      "minimum": 0,
+      "type": "integer"
+    },
+    "omittedExpenses": {
+      "minimum": 0,
+      "type": "integer"
+    },
+    "organization": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "phase": {
+      "enum": [
+        "preview",
+        "completed"
+      ],
+      "type": "string"
+    },
+    "proposalId": {
+      "type": "string"
+    },
+    "provider": {
+      "type": "string"
+    },
+    "reconciliationRequired": {
+      "type": "boolean"
+    },
+    "reportId": {
+      "type": "string"
+    },
+    "responseGuidance": {
+      "type": "string"
+    },
+    "skippedAlreadyPushed": {
+      "minimum": 0,
+      "type": "integer"
+    },
+    "success": {
+      "type": "boolean"
+    },
+    "units": {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "success",
+    "phase",
+    "provider",
+    "proposalId"
+  ],
+  "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

Changed2 schema fields changedAug 23, 2026

changedInput schema / properties / mode / description

Previous value: -"Step 1 only: automatic document treatment, paid expenses, or bills."New value: +"Step 1 only (Zoho Books): automatic document treatment, paid expenses, or bills."

changedInput schema / properties / provider / description

Previous value: -"Accounting destination provider."New value: +"Accounting destination provider. Agent-driven posting is currently available only for Zoho Books."

Changed2 schema fields changedAug 22, 2026
- addedInput schema / properties / reportingTagMappings / additionalProperties / properties / optionId / description
```
Added value: +"Live option ID belonging to tagId, returned in the step-1 proposal."
```
- addedInput schema / properties / reportingTagMappings / additionalProperties / properties / tagId / description
```
Added value: +"Live accounting-provider reporting-tag ID returned in the step-1 proposal."
```
AddedAug 13, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds critical behavioral context: step 1 is read-only (nothing posted), step 2 posts only the frozen proposal after revalidation. It also discloses the provider limitation and the fact that client-account posting is unsupported. This goes far beyond what annotations provide, making the tool's behavior fully transparent.

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 lengthy but well-organized, front-loading the purpose and then clearly delineating steps. Every sentence adds essential information—step details, provider limitations, and warnings. There is no fluff; the length is justified by the tool's complexity. The structure with step labels enhances readability.

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 tool's complexity (9 parameters, two-step process, nested objects) and the presence of an output schema, the description covers all necessary aspects: the workflow, step-specific parameters, provider restrictions, and safety checks. It tells the agent exactly what to do and what not to do, making it complete for correct invocation.

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 schema has 100% description coverage, so the baseline is 3. The description adds step-specific associations (e.g., mode is step 1 only, confirm is step 2 only) and explains the purpose of mappings and forceRepush. This goes beyond the schema's basic descriptions, though the schema already covers the parameters well. The added workflow context justifies a 4.

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 tool's purpose: to review and then post an ExpenseBot report to the owner's accounting destination. It specifies the two-step process and distinguishes it from siblings like share_report by emphasizing the posting action. The verb 'post' and resource 'report' are specific, and the mention of 'review' and 'approval' clarifies the workflow.

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?

The description provides explicit step-by-step usage instructions: step 1 without confirm, step 2 with confirm and only proposalId. It explicitly states which providers are supported (Zoho Books only) and directs users to use web flows for others. It also warns against adding mapping fields to the confirmation call, leaving no ambiguity about when and how to use the tool.

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.