Skip to main content
Glama

Check before spending

check_permission

Check a proposed purchase against a permission slip (mandate) BEFORE spending.

This is a CHECK only: it never moves money. It tells you whether the purchase fits the permission slip your owner set, before you spend. Present your API key (X-API-Key header). Tenant context is derived from the authenticated key, never from call arguments — never pass a tenant id.

Outcomes:

  • allow: proceed with the purchase, then submit completion evidence over REST with the returned decision_token (single- use, bound to this exact action). There is deliberately no completion tool in MCP.

  • needs_human_approval: STOP. Do not buy yet and do not retry in a loop. The owner approves or refuses on their own screen; if they approve, a decision token is issued for this spend — claim it over REST with the same key that ran this check, then buy and complete over REST (Step 4 of the setup guide).

  • deny: do not buy. A denial is final unless the OWNER changes the slip — never ask for limits to be raised as part of the purchase flow.

Arguments are validated strictly — no type coercion — and any field outside the documented set is refused by name. Repeating a check with the same idempotency_key returns the original check instead of creating a duplicate. Never pass a tenant id, under any name: passing tenant_id, tenant, or tenantId refuses the call. Leave them unset.

mandate_id, agent_id and currency may be omitted: when your key is tied to one permission slip (or your workspace has exactly one), the server fills them from that slip — send only the purchase (category, amount_minor, and optionally counterparty and description).

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": {
      "category": "<category>",
      "amount_minor": "<amount_minor>"
    },
    "name": "check_permission"
  }
}

Input Schema

NameRequiredDescriptionDefault
tenantNo
agent_idNo
categoryYes
currencyNo
tenantIdNo
tenant_idNo
mandate_idNo
descriptionNo
amount_minorYes
counterpartyNo
idempotency_keyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior3/5

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

Annotations declare readOnlyHint=false and non-destructive, and the description is consistent with that while adding substantial context: API-key authentication, tenant derivation from the key, single-use decision tokens, idempotency behavior, and strict no-coercion validation. The one gap relative to the annotation set is that it does not resolve why readOnlyHint=false when it 'never moves money' — it implicitly creates a check record, but that side effect is never named.

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?

Long but well structured: purpose first, then the check-only guarantee, auth, then outcomes as a labelled list. Minor waste from repeating the tenant-id prohibition twice ('never from call arguments' and 'Never pass a tenant id, under any name').

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 no output schema, the description fully enumerates the three return outcomes and the follow-up action for each, and covers the cross-transport completion path over REST. An agent has everything needed to call this and act on the result.

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

Parameters5/5

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

Despite 0% schema description coverage, the description documents all 11 parameters: category and amount_minor as the real payload, counterparty/description/idempotency_key as optional, mandate_id/agent_id/currency as auto-filled when the key is bound to one slip, and tenant/tenantId/tenant_id as forbidden by name. This is exactly the compensation the 0% coverage requires.

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 — checking a proposed purchase against a permission slip (mandate) — and adds the temporal constraint 'BEFORE spending'. It is unmistakably distinct from the only sibling, get_receipt.

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?

Gives explicit routing for every outcome: allow means proceed and submit completion evidence over REST, needs_human_approval means STOP with no retry loop, deny means do not buy. It also states that there is deliberately no completion tool in MCP, so the agent knows where the workflow continues.

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