Skip to main content
Glama

ExpenseBot

by io.github.TotesMagotes

get_spreadsheet_url

Read-only

Return the user's master ExpenseBot Google Sheet plus authenticated ExpenseBot workspace links, each with a label and a description of when to use it. Use this when the user asks to open, view, check, or edit their spreadsheet; review expenses or income; manually scan Gmail; reconcile; connect or manage a bank/credit card; open Automation Hub or General Settings; create or open reports; or asks where a submitted receipt went. Choose and show the one or two links relevant to the request instead of listing the entire catalog. After a receipt submission, prefer Review expenses plus the Google Sheet. After an income write, prefer Review income plus the Sheet. For a Gmail scan or connection request, use the Scan Gmail link, which opens the existing Gmail scanning interface. Bank/card requests use the Reconcile link; configuration requests use the returned Automation Hub or General Settings link. Category, G/L, and account-code requests use Category management; client, project, and trip groups use Group management; questions about what counts as Personal use Personal rules. For client billing setup, use the returned clientBillingHandoffs instead of giving a generic dashboard tour: manageClients creates or manages the client list, tagReadyExpenses opens Review Expenses filtered to blank or default-Business rows, and createClientReport opens report creation by group after expenses have been assigned. Choose the one next step that matches the user's current state. If the user names a client and an exact expense scope and asks the assistant to do the work, use search_expenses and group_expenses instead; show its grounded preview and require explicit confirmation before changing any rows. When the user asks to choose receipt images from Google Photos, use the returned Google Photos link; it opens the existing authenticated picker and handles any required Google consent in ExpenseBot. When they ask where ExpenseBot stores receipt files, return the Drive folder link only when it is available; never invent or request a folder ID. For a complete, unambiguous cash expense or mileage trip, use the direct write tool. Use the returned Manual expense link for multiple entries, credits/refunds, detailed tax/tip entry, per diem, incomplete details, or visual review. Use the Mileage and travel link for route calculation, mileage settings, repeated trips, calendar/rideshare imports, per diem, or visual review. These links open the existing reviewed app forms. When the user wants to import income from a screenshot, PDF, or CSV but no attachment is available in chat (or the review is visually complex), use the returned Import income links — they open the existing Add Income importer, which parses the file and shows every row for review before anything is saved. Team setup requests use the returned role-aware Team setup handoff: eligible solo business owners open Add teammates, while existing team owners and co-admins open License Manager. If the handoff says owner access is required, explain that instead of presenting a broken link. Complex or visually reviewed report requests use the returned Create report link. Read-only; this tool does not create or modify spreadsheet rows.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYes
messageYes
successYes
reportsUrlYes
dashboardUrlYes
gmailScanUrlYes
spreadsheetIdYes
spreadsheetUrlYes
reviewIncomeUrlYes
reviewExpensesUrlYes
gmailActionNeededUrlYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed16 schema fields changed
    • removedOutput schema / description
      Removed 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."
    • addedOutput schema / properties / dashboardUrl
      Added value: +{
+  "type": "string"
+}
    • 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 / gmailActionNeededUrl
      Added value: +{
+  "type": "string"
+}
    • addedOutput schema / properties / gmailScanUrl
      Added value: +{
+  "type": "string"
+}
    • 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 / reportsUrl
      Added value: +{
+  "type": "string"
+}
    • addedOutput schema / properties / reviewExpensesUrl
      Added value: +{
+  "type": "string"
+}
    • addedOutput schema / properties / reviewIncomeUrl
      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 / spreadsheetId
      Added value: +{
+  "minLength": 1,
+  "type": "string"
+}
    • addedOutput schema / properties / spreadsheetUrl
      Added value: +{
+  "type": "string"
+}
    • 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 / required
      Added value: +[
+  "success",
+  "spreadsheetId",
+  "spreadsheetUrl",
+  "reviewExpensesUrl",
+  "reviewIncomeUrl",
+  "gmailScanUrl",
+  "gmailActionNeededUrl",
+  "reportsUrl",
+  "dashboardUrl",
+  "data",
+  "message"
+]
  2. First observed

TDQS

A4.8/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, and the description reinforces this with 'Read-only; this tool does not create or modify spreadsheet rows.' Beyond that, it discloses non-obvious behavioral traits: only the one or two relevant links should be shown rather than the whole catalog, the Drive folder link must not be invented ('never invent or request a folder ID'), and if a handoff requires owner access, explain instead of presenting a broken link. With annotations lowering the bar, this level of added context is excellent.

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 long (a single dense paragraph) and could be improved with bullets or paragraph breaks, which would make it easier for an agent to consult. However, it is front-loaded with the core purpose and general when-to-use trigger, and nearly every sentence carries unique routing information for a handoff that touches many workflows. Acceptably sized at the upper bound, but not a model of concise prose.

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?

For a zero-parameter tool with a large routing surface, the description covers an extraordinary number of cases: spreadsheet access, Gmail scans, bank reconciliation, configuration, category/group management, Google Photos, Drive-storage questions, client billing handoffs, team setup, imports, and reports. It also anticipates failure modes (using owner-access handoffs, never inventing folder IDs) and points to alternative sibling tools when a different action is required. Alongside the provided output schema, the agent has everything it needs to call and interpret this tool correctly.

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 takes zero parameters, so there is nothing for the description to disambiguate and the schema trivially covers 100% of parameters. Per the rubric, a zero-parameter tool starts at baseline 4, and the description adds no param-related meaning because no params exist. The routing context it provides is rich, but it belongs to usage guidance rather than parameter semantics.

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 first sentence states a specific verb ('Return') and resource ('master ExpenseBot Google Sheet plus authenticated ExpenseBot workspace links'), and clarifies that each link carries a label and a use-case description. This clearly frames the tool as a link-dispatch/router and distinguishes it from siblings like scan_gmail or submit_receipt, which actually perform those operations rather than returning links to them. The only minor friction is that the tool name (get_spreadsheet_url) undersells its broader role, but the description itself removes that ambiguity.

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 is effectively a decision tree: it states explicit triggers ('Use this when the user asks to open, view, check, or edit their spreadsheet'), gives per-scenario link preferences ('After a receipt submission, prefer Review expenses plus the Google Sheet'), and names when-not-to-use alternatives ('If the user names a client and an exact expense scope..., use search_expenses and group_expenses instead'). It even distinguishes selection rules for Gmail, bank/card, category, group, and billing requests. This is the strongest possible usage guidance.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0
Disambiguation3/5

Most tools are explicitly scoped, but several analytics/retrieval tools overlap in purpose, such as get_spending_summary vs get_deep_analytics vs get_monthly_books_review, and generic search vs search_expenses vs search_knowledge. The detailed descriptions help, but an agent still has to carefully choose between near-equivalent options like correct_expenses vs update_expense and the three add_income variants.

Naming Consistency5/5

Tool names consistently use lower_snake_case with a recognizable verb prefix: get_*, list_*, add_*, create_*, check_*, scan_*, search_*, and whatif_*. Minor exceptions like fetch and search are still terse retrieval verbs rather than a different naming style, so the overall pattern is predictable.

Tool Count1/5

With 59 tools, this exceeds the 50+ threshold for an extreme tool count and creates a heavy selection surface for an agent. Even though ExpenseBot covers many subdomains, many get_/list_/add_ variants could be consolidated into fewer parameterized tools. The count undermines the otherwise clear naming structure.

Completeness3/5

The surface is strong for creating, reading, and updating expenses, reports, invoices, and Gmail scans, but there are notable lifecycle gaps: no delete/void tools for expenses, income, reports, or invoices, and no update tool for income. Several descriptions explicitly redirect unsupported edits to the web app, confirming that the assistant cannot complete those workflows directly.

Resources