Skip to main content
Glama

ExpenseBot

by io.github.TotesMagotes
OverviewDiscussionsAdmin

request_accounting_integration

Request support for an accounting package only after checking ExpenseBot's reviewed direct and import-file destinations and finding no matching package. Do not use this for a listed or Beta destination, a general compatibility question, or without the exact package name. This is a confirmation-gated write: after the user approves, it creates one deduplicated request bound to the authenticated ExpenseBot account and emails ExpenseBot's internal team. It does not create an integration or make the requested package immediately available. On accepted or previously recorded requests, tell the user ExpenseBot will email them within one week with an update.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
packageNameYesExact accounting package requested by the user.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageYes
successYes
duplicateYes
packageNameYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "duplicate": {
+      "type": "boolean"
+    },
+    "message": {
+      "type": "string"
+    },
+    "packageName": {
+      "type": "string"
+    },
+    "success": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "success",
+    "duplicate",
+    "packageName",
+    "message"
+  ],
+  "type": "object"
+}
  2. 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
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description details the behavior: it is a confirmation-gated write that creates a deduplicated request bound to the account, emails the internal team, does not create an integration, and includes post-acceptance user communication. This fully discloses side effects and limitations.

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 dense but each sentence serves a purpose: usage condition, exclusions, behavior, and outcome. It is front-loaded with the primary condition. Slightly verbose but well-structured and free of redundancy.

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 confirmation-gated write with an output schema, the description covers the workflow, side effects, and expected user communication. It clearly states what it does not do (create integration) and what happens on accepted requests, leaving no critical gaps for an agent to invoke it correctly.

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?

The schema already describes packageName as 'Exact accounting package requested by the user' with 100% coverage. The description reinforces exactness and the requirement for an exact name but does not add significant new meaning beyond the schema's existing description.

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: request support for an accounting package, with explicit conditions for when it applies. It distinguishes itself from siblings by specifying not to use it for listed/Beta destinations or general compatibility questions, making its scope unambiguous.

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 when-to-use and when-not-to-use guidance: only after checking reviewed destinations and finding no match, and explicitly excludes listed/Beta destinations, general compatibility questions, and missing exact package names. It also notes it is confirmation-gated, which is a critical usage constraint.

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