Skip to main content
Glama

Server Details

Give your AI agent a spending limit: approval controls and single-use virtual cards.

Ownership verified
Status
Healthy
Uptime
96.4% over 66 days
OAuth
Works in Glama
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
kevinfee3/authoryze-mcp
GitHub Stars
0

TDQS

A4.4/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a distinct role in the purchase lifecycle: request_purchase creates a request, check_status reads status, retrieve_card draws the single-use card, report_purchase_outcome records the checkout result, and get_spending_summary reports limits. The descriptions explicitly delineate boundaries, such as warning not to use retrieve_card for polling, so misselection is unlikely.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: check_status, get_spending_summary, report_purchase_outcome, request_purchase, retrieve_card. There are no mixed conventions or vague standalone verbs.

Tool Count5/5

Five tools map tightly to the agent purchase lifecycle and spending visibility without redundancy or bloat. The set is well-scoped for the domain and every tool earns its place.

Completeness4/5

The core lifecycle—request, check status, retrieve card, report outcome—is fully covered, along with spending limits. Minor gaps include no tool for listing purchase history or cancelling a pending request, and past outcomes can only be inferred from individual status checks, though these may be intentionally dashboard-only.

Available Tools

5 tools
check_statusCheck purchase request status
Read-only
Inspect

Check the current status of a purchase request. Read-only: it never issues, draws, or reveals a card. Returns the status (and the denial reason when denied). When approved, it reports a retrievable boolean: true means the single-use card has not been drawn yet, so call retrieve_card ONCE when you are ready to pay; false means the card was already retrieved and cannot be shown again (start a new purchase if you need another). While pending_review it returns review_url, the page where a human approves or denies — relay that link to the person if they ask where the request is. Safe to poll while a request is pending_review or processing.

ParametersJSON Schema
NameRequiredDescriptionDefault
request_idYesThe request_id returned by request_purchase
get_spending_summaryGet spending summaryA
Read-only
Inspect

Get current spending vs. configured limits. Per-agent fields (daily_spent, weekly_spent, monthly_spent, total_budget_spent) reflect rules set on this agent. The optional user_aggregate object reports the owner's cross-agent caps — these apply across every agent on the account and will deny a purchase even if this agent's per-agent rules are not exceeded. The optional team object appears only when this agent belongs to a team: team.monthly is a ceiling across every agent in that team (so it can already be near its limit even if this agent has spent nothing) and team.auto_approve_threshold, when present, overrides this agent's own threshold for deciding what needs human approval. Only configured limits appear in the response.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.9/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true, so the description carries most of the burden. It goes well beyond that: it explains the semantics of per-agent fields, the cross-agent user_aggregate caps, team-level ceilings, and threshold overrides. It also notes 'Only configured limits appear in the response,' clarifying absence behavior. This is rich behavioral context not derivable from annotations alone.

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?

Front-loaded with the core purpose, then systematically explains the response structure. It's information-dense without obvious filler, though the list of per-agent fields is slightly repetitive. Overall efficient and well-organized.

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?

Given the tool has no input parameters and no output schema, the description must explain what the response contains and what it means. It does so thoroughly: it covers per-agent fields, cross-agent aggregates, team-level limits, threshold overrides, and the condition for their appearance. This is complete for an agent to interpret the output 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?

Zero parameters, so baseline is 4 per the rules. The description details the meaning of response fields and nested objects (user_aggregate, team), which compensates for the lack of an output schema and adds value beyond what the empty input schema provides. No penalty since there are no parameters to document.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: 'Get current spending vs. configured limits.' This clearly distinguishes it from siblings like request_purchase and retrieve_card, though it doesn't explicitly name those alternatives. The core purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage as a read-only informational tool, but no explicit when-to-use guidance or alternatives. An agent can infer it's for checking spending, but the description doesn't say e.g. 'use before request_purchase to verify capacity' or when not to use it.

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

report_purchase_outcomeReport what happened at checkout
Idempotent
Inspect

Report the result of a checkout attempt made with a card from retrieve_card. Call this after EVERY checkout attempt, once you know the result: outcome completed if the merchant took the payment, or not_completed if it was declined or didn't go through, with message saying what happened (for a decline, the merchant's exact decline text). Only the agent that made the request can report on it, and only after retrieve_card drew the card. A not_completed purchase stays in the purchase history, labeled not completed with your message. Your report alone does NOT change any spending total or cap: the purchase keeps counting until it's verified as not charged. For a Privacy.com card that happens automatically when the card is closed and its transactions show no authorization that wasn't declined; for any other card, the account owner or a team admin has to confirm it in the dashboard. Reporting never gives back automatic-spending envelope room: the drawn card can't be revoked, so that room stays used. A Privacy.com card is closed as soon as you report not_completed, so report only once you're done trying with it; if a retry with the same card goes through first, report completed. A purchase reported completed can't be changed to not_completed. Reporting the same outcome again is harmless.

ParametersJSON Schema
NameRequiredDescriptionDefault
messageYesWhat happened, in a sentence. For not_completed, include the decline or error text the merchant showed (e.g. 'Your card was declined (insufficient funds)'). For completed, an order number if there is one.
outcomeYescompleted: the merchant took the payment. not_completed: checkout didn't go through.
request_idYesThe request_id returned by request_purchase
request_purchaseRequest a purchase
Destructive
Inspect

Submit a purchase request. Returns approved, pending_review, denied (with reason), or failed (a recoverable error, safe to retry, though some failures such as a missing Privacy.com key need the account owner to fix a setting first). A request that looks like a duplicate of another recent purchase on the account (same merchant and amount) is NOT auto-approved — it is escalated to pending_review for the account owner to approve, so poll check_status rather than retrying. IMPORTANT for retries: pass a stable idempotency_key that identifies this one distinct purchase intent, and reuse the SAME key if you retry after a timeout or error. Retries with the same key never issue a second card or charge a second fee — they return the original request's result. Use a fresh key only for a genuinely new, separate purchase. After every checkout attempt with a card from retrieve_card, call report_purchase_outcome with the result, whether it went through or not.

ParametersJSON Schema
NameRequiredDescriptionDefault
amountYesPurchase amount in the specified currency
currencyNoISO 4217 currency code, defaults to USD
descriptionYesWhat is being purchased
merchant_urlYesThe merchant's full URL, including https:// (e.g. https://amazon.com, https://aws.amazon.com). Required. A bare domain such as amazon.com is still accepted and treated as https://amazon.com. Its hostname is used for whitelist/blacklist matching with subdomain support, so 'amazon.com' on the whitelist allows https://aws.amazon.com.
category_hintNoMerchant category slug (e.g. cloud_compute, software_saas)
justificationYesWhy this purchase is needed. Required for all requests
merchant_nameNoOptional human-readable merchant name (e.g. 'AWS', 'GitHub')
idempotency_keyNoStable key for this one purchase intent. Reuse the SAME key when retrying so retries don't double-charge or double-issue a card (the server dedups on it atomically). Generate a fresh key only for a genuinely new purchase. Independent of the key, the server also runs a best-effort near-duplicate check on (merchant, amount) across the whole account and escalates suspected duplicates to pending_review for the account owner to decide; passing a stable key is still strongly recommended because it is the only fully atomic protection against concurrent double-submits.
merchant_country_codeYesISO 3166-1 alpha-2 country code of the MERCHANT (the store being purchased from, not the user's country). Required. Examples: 'US', 'GB', 'DE', 'CA', 'AU'.
retrieve_cardRetrieve the single-use card
Destructive
Inspect

Draw and return the single-use virtual card for an APPROVED purchase request. Call this exactly ONCE, only when you are ready to pay. The card details (number, expiry, CVC) are returned inline and shown a SINGLE time — store them immediately and complete the purchase. Drawing is final and happens once (the card can't be drawn again or handed back), so do NOT call this speculatively, to poll status (use check_status for that), or more than once. There is no re-draw: a second call returns already_retrieved. If the request is not yet approved, call check_status and wait until it is. The response also returns cardholder_name and billing_address (line1, line2, city, state, postal_code, country_code). Use them verbatim for the BILLING section of checkout: they are what the card issuer has on file, and the merchant's address check (AVS) compares against them, so substituting anything else will get the purchase declined. Any field the account owner has not filled in is null; if the merchant requires a field that came back null, say so rather than inventing a value. These are NOT a shipping address. If checkout needs somewhere to deliver to, ask the user for a shipping address separately and never reuse the billing address for it unless the user tells you they are the same. After you attempt checkout with this card, ALWAYS call report_purchase_outcome with this request_id: outcome completed if the merchant took the payment, or not_completed with the merchant's message if it was declined or didn't go through.

ParametersJSON Schema
NameRequiredDescriptionDefault
request_idYesThe request_id returned by request_purchase

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updates
    • Changedcheck_status2 fields changed
      • addedInput schema / properties / request_id / format
        Added value: +"uuid"
      • addedInput schema / properties / request_id / pattern
        Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
    • Changedreport_purchase_outcome2 fields changed
      • addedInput schema / properties / request_id / format
        Added value: +"uuid"
      • addedInput schema / properties / request_id / pattern
        Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
    • Changedrequest_purchase6 fields changed
      • addedInput schema / properties / category_hint / maxLength
        Added value: +64
      • addedInput schema / properties / currency / pattern
        Added value: +"^[A-Za-z]{3}$"
      • addedInput schema / properties / description / maxLength
        Added value: +500
      • addedInput schema / properties / justification / maxLength
        Added value: +2000
      • addedInput schema / properties / merchant_name / maxLength
        Added value: +200
      • addedInput schema / properties / merchant_url / maxLength
        Added value: +2048
    • Changedretrieve_card2 fields changed
      • addedInput schema / properties / request_id / format
        Added value: +"uuid"
      • addedInput schema / properties / request_id / pattern
        Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
  2. 1 tool update
    • Changedrequest_purchase1 field changed
      • changedInput schema / properties / merchant_url / description
        Previous value: -"Merchant domain (e.g. amazon.com, aws.amazon.com). Required. Used for whitelist/blacklist matching with subdomain support, so 'amazon.com' on the whitelist allows aws.amazon.com."New value: +"The merchant's full URL, including https:// (e.g. https://amazon.com, https://aws.amazon.com). Required. A bare domain such as amazon.com is still accepted and treated as https://amazon.com. Its hostname is used for whitelist/blacklist matching with subdomain support, so 'amazon.com' on the whitelist allows https://aws.amazon.com."
  3. 1 tool update
    • Addedreport_purchase_outcome
  4. 1 tool update
    • Changedrequest_purchase1 field changed
      • changedInput schema / properties / idempotency_key / description
        Previous value: -"Stable key for this one purchase intent. Reuse the SAME key when retrying so retries don't double-charge or double-issue a card (the server dedups on it atomically). Generate a fresh key only for a genuinely new purchase. Independent of the key, the server also runs a best-effort near-duplicate check on (merchant, amount) across the whole account and escalates suspected duplicates to owner approval; passing a stable key is still strongly recommended because it is the only fully atomic protection against concurrent double-submits."New value: +"Stable key for this one purchase intent. Reuse the SAME key when retrying so retries don't double-charge or double-issue a card (the server dedups on it atomically). Generate a fresh key only for a genuinely new purchase. Independent of the key, the server also runs a best-effort near-duplicate check on (merchant, amount) across the whole account and escalates suspected duplicates to pending_review for the account owner to decide; passing a stable key is still strongly recommended because it is the only fully atomic protection against concurrent double-submits."
  5. 4 tool updates
    • First observedcheck_status
    • First observedget_spending_summary
    • First observedrequest_purchase
    • First observedretrieve_card

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    B
    maintenance
    Provides AI agents with a prepaid, capped payment method so they can request charges without accessing real accounts. Enforces spending limits, requires human approval for larger transactions, and supports out-of-band approvals via CLI, dashboard, or Telegram.
    MIT
  • -
    license
    Not graded
    quality
    F
    maintenance
    Enables AI agents to manage and use prepaid virtual Visa cards with hard budget limits for secure online transactions. It provides tools for creating cards, checking balances, and retrieving payment credentials with human-in-the-loop approvals.
    1
    -
  • A
    license
    A
    quality
    A
    maintenance
    AI-native payment infrastructure that enables AI agents to make purchases, issue virtual cards, and manage spending within delegated budgets and policy controls.
    7
    321 npm
    MIT
Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.