Skip to main content
Glama

expense_reimburse

Marks an approved expense as paid out — restricted to the tenant owner because it moves real money, and only an 'approved' expense qualifies (CONFLICT otherwise). Stamps reimbursed_at, after which the row's content freezes unconditionally since the amount approved is the amount recorded as paid. Records the payout only — no funds move automatically.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "expense_reimburse"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesThe expense id (expense_list shows them).
notesNo
statusNo
vendorNo
currencyNo
ocr_jsonNo
tax_typeNo
tags_jsonNo
approved_atNo
approved_byNo
category_idNo
receipt_keyNo
rejected_atNo
amount_centsNo
expense_dateNo
submitted_atNo
tax_rate_bpsNo
recurrence_idNo
reimbursed_atNo
subtotal_centsNo
rejection_reasonNo
tax_amount_centsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Goes well beyond the annotations by disclosing the owner-only authorization requirement, the state precondition and its CONFLICT failure mode, the reimbursed_at stamp, the permanent row freeze, and the crucial clarification that no funds actually move. The one unstated case is what a repeat invocation looks like beyond the implied CONFLICT, which matters given idempotentHint=false.

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?

Three tight sentences, front-loaded with the operation and immediately followed by the authorization and state constraints. Dense but every clause carries information; the em-dash construction is effective rather than padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Behavioral and authorization context is strong, but for a 22-parameter mutation tool with no output schema and near-zero schema documentation, the description leaves a significant gap around why so many optional fields exist and whether they have any effect. Return-value details are rightly omitted since no output schema is declared.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 5% across 22 parameters, so the description carries the burden — yet it never mentions the id parameter or any of the other 21 fields. The phrase "the row's content freezes" and "the amount approved is the amount recorded as paid" only obliquely hint that supplied fields are ignored, leaving an agent to guess why the schema accepts them.

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 — "Marks an approved expense as paid out" — which is unmistakably distinct from sibling expense_approve, expense_reject, and expense_update. An agent can identify the operation without opening the schema.

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?

Usage conditions are explicit: caller must be the tenant owner, and the target expense must already be in 'approved' state or the call returns CONFLICT. It doesn't explicitly name expense_approve as the prerequisite step or any sibling alternative, but the state precondition implies the ordering.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources