Skip to main content
Glama

expense_approve

Approves a submitted expense claim — requires the admin or owner role, and only a 'pending' expense qualifies (CONFLICT otherwise). Stamps approved_by and approved_at with the caller and the current time; once approved, the row's content freezes for everyone except the approver themselves. NEXT: expense_reimburse (owner only) to pay it out.

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_approve"
  }
}

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

A4.4/5.0
Behavior5/5

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

Annotations already mark this as mutating and non-idempotent, and the description adds critical context: role requirements, pending-only eligibility, conflict behavior, system-stamped fields, and post-approval freeze semantics. This is well beyond what the annotations provide and does not contradict them.

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?

Front-loads the core action and eligibility, then adds side effects and the next step compactly. Every clause contributes operational meaning, with no filler.

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

Completeness4/5

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

Given the mutation, role precondition, and post-approval freeze behavior, the description is materially complete for invoking approval correctly. The main remaining gap is the confusing 22-parameter schema, whose optional fields are not addressed.

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%, and while the required id parameter is documented in the schema, the other 21 optional fields are left unexplained. The description clarifies that approved_by and approved_at are system-stamped, but it does not resolve whether the remaining optional fields can or should be supplied, leaving significant ambiguity.

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 ("Approves") and resource ("a submitted expense claim"), plus scope (only pending). It distinguishes itself from siblings by naming the next step, expense_reimburse, and by its approval-specific precondition.

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?

Explicitly names the required role (admin or owner), the qualifying state (pending), and the failure condition (CONFLICT otherwise). It also routes the agent to expense_reimburse for the next step, so when-to-use versus alternatives is clear.

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