Skip to main content
Glama

ExpenseBot

by io.github.TotesMagotes
OverviewDiscussionsAdmin

get_client_advance_balances

Read-only

Read the same per-client advance balances shown in ExpenseBot's Client advances section. Use for questions like 'how much of Acme's advance remains?', 'which client floats are still open?', or 'do I owe a client a refund?'. A negative ledger balance means money remains to refund; a positive balance means the client owes the user. Returns the existing app handoff for Refund leftover or Bill Client. Read-only: never records a refund, creates an invoice, or recomputes the ledger in model prose.

Input Schema

NameRequiredDescriptionDefault
clientNameNoOptional client name or canonical Client tag. Omit to list every open balance backed by a recorded client advance.
clientEmailNoAccepted client's account email (accountants only).

Output Schema

NameRequiredDescriptionDefault
dataNo
messageNo
successYes
balancesNo
homeCurrencyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / clientEmail / description
      Previous value: -"Client account email. Accountants may use this only for an accepted ExpenseBot client."New value: +"Accepted client's account email (accountants only)."
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "balances": {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "data": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "homeCurrency": {
+      "type": "string"
+    },
+    "message": {
+      "type": "string"
+    },
+    "success": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "success"
+  ],
+  "type": "object"
+}
  3. Changed1 schema field changed
    • 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
  4. Changed2 schema fields changed
    • changedInput schema / properties / clientName / description
      Previous value: -"Optional client name or canonical Client tag. Omit to list all open balances."New value: +"Optional client name or canonical Client tag. Omit to list every open balance backed by a recorded client advance."
    • removedInput schema / properties / days
      Removed value: -{
-  "description": "Lookback window in days (default 365).",
-  "maximum": 3650,
-  "minimum": 30,
-  "type": "integer"
-}
  5. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description goes well beyond them: it defines the sign convention (negative = money remains to refund, positive = client owes the user) and explicitly states it never records a refund, creates an invoice, or recomputes the ledger in prose. That is exactly the kind of domain behavior an agent cannot infer from annotations or 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?

Front-loaded with the verb+resource, then usage examples, then the crucial sign-convention and read-only caveats — logical ordering with little waste. The middle list of three example questions is slightly verbose but serves as genuine usage scaffolding.

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?

With an output schema present, the description needn't explain return shapes; it covers the semantic interpretation of the returned balances (sign convention) and the handoff behavior (Refund leftover / Bill Client), which are the pieces a schema cannot convey. Nothing an agent needs to call this correctly 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 clientName and clientEmail are already documented in the schema. The description reinforces the 'omit to list all open balances' default but adds no syntax or format detail beyond what the schema provides, so the baseline of 3 applies.

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 ('Read') and resource ('per-client advance balances'), plus ties it to the visible Client advances section of the app so an agent knows exactly which data surface it touches. The example questions ('how much of Acme's advance remains?', 'which client floats are still open?') further pin the domain apart from siblings like get_credits_refunds.

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 example questions give clear usage context, and the closing sentence explicitly excludes writing behavior. It does not explicitly compare against the nearest sibling (get_credits_refunds) or say when a different tool should be chosen, so it stops short of full when/when-not routing.

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

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