Skip to main content
Glama

Authoryze

by ai.authoryze

Retrieve the single-use card

retrieve_card
Destructive

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 the card consumes the purchase's spending envelope, 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
request_idYesThe request_id returned by request_purchase

TDQS

A4.6/5.0
Behavior5/5

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

The annotations only carry destructiveHint: true, but the description adds critical behavioral context: the card is shown only once, a second call returns already_retrieved, and drawing consumes the spending envelope. It also explains AVS implications and the singleton nature of the display. This goes well beyond the annotation and is not contradicted by it.

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?

The description is long but every sentence carries weight — usage constraints, response fields, billing address handling, and null-value guidance are all essential. It is front-loaded with the most critical constraint ('Call exactly ONCE') and remains focused. Slightly long, but justified by the tool's complexity.

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's complexity (single-use, spending envelope, AVS, null handling), the description covers all relevant aspects: when to call, what it returns, how to use billing address vs shipping address, and how to handle missing data. There is no output schema, so the description must convey response behavior, and it does thoroughly.

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

Parameters3/5

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

Schema coverage is 100% for the single request_id parameter, and its description ('The request_id returned by request_purchase') is adequate. The tool description does not add extra parameter detail beyond that, so a baseline of 3 is appropriate.

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?

The description clearly states the verb ('Draw and return') and the resource ('single-use virtual card for an APPROVED purchase request'), and explicitly distinguishes it from the sibling check_status by saying 'use check_status for that.' It is unambiguous about what the tool does and what it does not.

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?

The description gives explicit when-to-use ('only when you are ready to pay'), when-not-to-use ('do NOT call this speculatively, to poll status, or more than once'), names the alternative tool (check_status), and instructs waiting for approval before calling. This is exemplary usage guidance.

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

All Authoryze toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a distinct role in the purchase lifecycle: submitting, checking status, retrieving the card, and viewing spending limits. The descriptions carefully separate read-only status checks from the one-time card draw.

Naming Consistency5/5

All tool names follow a clear verb_noun pattern: check_status, get_spending_summary, request_purchase, retrieve_card. The style is consistent and each verb accurately signals the action.

Tool Count5/5

Four tools cover the full purchase request workflow without unnecessary extras. Each tool addresses a distinct and necessary step, and the count feels appropriately scoped for the server's purpose.

Completeness4/5

The core lifecycle of request, status check, card retrieval, and spending visibility is well covered. Minor gaps exist, such as no explicit way to cancel a pending request or list historical purchases, but agents can work around these.

Resources