Authoryze
Server Details
Give your AI agent a spending limit: approval controls and single-use virtual cards.
- 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
Scored across 5 tools
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.
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.
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.
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 toolscheck_statusCheck purchase request statusRead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | The request_id returned by request_purchase |
get_spending_summaryGet spending summaryARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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.
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.
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.
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.
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.
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 checkoutIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | What 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. | |
| outcome | Yes | completed: the merchant took the payment. not_completed: checkout didn't go through. | |
| request_id | Yes | The request_id returned by request_purchase |
request_purchaseRequest a purchaseDestructiveInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Purchase amount in the specified currency | |
| currency | No | ISO 4217 currency code, defaults to USD | |
| description | Yes | What is being purchased | |
| merchant_url | Yes | 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. | |
| category_hint | No | Merchant category slug (e.g. cloud_compute, software_saas) | |
| justification | Yes | Why this purchase is needed. Required for all requests | |
| merchant_name | No | Optional human-readable merchant name (e.g. 'AWS', 'GitHub') | |
| idempotency_key | No | 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. | |
| merchant_country_code | Yes | ISO 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 cardDestructiveInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | The request_id returned by request_purchase |
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
- Changed
check_status2 fields changed- added
Input schema / properties / request_id / formatAdded value: +"uuid" - added
Input schema / properties / request_id / patternAdded 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})$"
- Changed
report_purchase_outcome2 fields changed- added
Input schema / properties / request_id / formatAdded value: +"uuid" - added
Input schema / properties / request_id / patternAdded 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})$"
- Changed
request_purchase6 fields changed- added
Input schema / properties / category_hint / maxLengthAdded value: +64 - added
Input schema / properties / currency / patternAdded value: +"^[A-Za-z]{3}$" - added
Input schema / properties / description / maxLengthAdded value: +500 - added
Input schema / properties / justification / maxLengthAdded value: +2000 - added
Input schema / properties / merchant_name / maxLengthAdded value: +200 - added
Input schema / properties / merchant_url / maxLengthAdded value: +2048
- Changed
retrieve_card2 fields changed- added
Input schema / properties / request_id / formatAdded value: +"uuid" - added
Input schema / properties / request_id / patternAdded 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})$"
1 tool update
- Changed
request_purchase1 field changed- changed
Input schema / properties / merchant_url / descriptionPrevious 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."
1 tool update
- Added
report_purchase_outcome
1 tool update
- Changed
request_purchase1 field changed- changed
Input schema / properties / idempotency_key / descriptionPrevious 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."
4 tool updates
- First observed
check_status - First observed
get_spending_summary - First observed
request_purchase - First observed
retrieve_card
Related MCP Connectors
AI agent spending controls. Set limits, blocklists, and caps. Approve transactions from your phone.
Prepaid virtual cards for AI agents: one-time cards, spend caps, human approvals.
Payment infrastructure for AI agents: spending rules, approval flows, single-use virtual cards.
Spending control for AI agents: approved budgets, a decision before each payment, signed receipts.
Related MCP Servers
- AlicenseAqualityDmaintenanceSpending limits for AI agents. Create budgets, enforce limits, track spend across x402, cards, MPP, or any payment rail.78 npmApache 2.0
- AlicenseNot gradedqualityBmaintenanceProvides 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
- -licenseNot gradedqualityFmaintenanceEnables 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-

Shatale MCP Serverofficial
AlicenseAqualityAmaintenanceAI-native payment infrastructure that enables AI agents to make purchases, issue virtual cards, and manage spending within delegated budgets and policy controls.7321 npmMIT
Glama MCP Gateway
Add one secure layer between your agents and this server.