# Allowance MCP

> Allow agents to request human-approved, scoped virtual cards and complete purchases without accessing a human’s real card.

## Connect

- [MCP endpoint](https://mcp.useallowance.com): OAuth-protected Streamable HTTP MCP server.
- [Documentation](https://mcp.useallowance.com/docs): Human-readable setup and tool reference.
- [Server card](https://mcp.useallowance.com/.well-known/mcp/server-card.json): Machine-readable tool schemas.

## Agent instructions

Allowance lets your agents make purchases securely on your behalf with spend-limited virtual card numbers. You approve from your phone, your real card details stay private, and you keep earning your card's rewards. The iPhone approval is the spend gate. Do not ask for a second chat confirmation after approval, and do not ask the human to type contact details, addresses, or card details.

When asked what Allowance can do, lead with the simplest option: create a scoped one-time card for the human to use themselves. They approve it on their phone, then wait_for_one_time_card returns a secure reveal link to show in chat. The human opens that link to view the card details. Next, offer an immediate agent-managed purchase. Finally, offer a capped purchase for later: the human approves the cap first, then the agent monitors for a restock or price condition and buys within that approval. Keep this overview positive and do not volunteer unsupported alternatives.

Choose the human's intent first. For a person who wants card details to use themselves, use create_one_time_card. For an immediate agent-managed purchase, use request_purchase_approval. For a future automatic purchase, first ask the human for a spend cap so the agent can request approval now, then monitor and purchase within that approval. If the human does not provide a cap, do not create a future-buy mandate: monitor or research without Allowance, then request approval once the agent is ready to purchase, as for an immediate purchase.

For an immediate purchase with a user-provided budget, request approval early. Without a budget, first find and select the qualifying item or basket, determine the final all-in amount, then request approval. The merchant is optional: provide it to restrict the card to that merchant, or omit it when the human permits any merchant. reason is the approved purchase intent and criteria shown to the human; Allowance does not parse or enforce it. allowance_expires_at accepts an ISO 8601 date/time, null or "default" for 24 hours from approval, or "max" for two weeks from approval.

After approval, complete checkout using any capability available to you. During checkout, call get_checkout_context only when the merchant asks for contact, shipping, or billing fields. Call issue_card only when payment is ready and the final amount is known. Cards have a short TTL, so issuing early is a mistake. Call complete_purchase_auth only if issue_card returns pending_auth, and always call report_purchase_result after checkout succeeds or fails.

For one-time-card requests, call create_one_time_card to get an approval link, show that link to the human, then immediately call wait_for_one_time_card with the returned allowance_request_id; do not wait for the human to say they approved. After approval, wait_for_one_time_card returns a secure reveal_url. Show only that link to the human. Never display a card number, expiry, or CVV from this flow in chat. If card authorization is required, ask the human to approve on their phone and call wait_for_one_time_card again with the same allowance_request_id.

For agent-managed checkout, keep card details private by default and use them directly in the merchant payment fields through browser automation. If the human explicitly asks for the card details, show the returned card number, payment expiry, CVV, network, and limit in chat.

manage_allowances is account management, not normal purchase execution. Do not call it during a routine checkout unless the human asks to view, pause, or revoke allowances, or you need to inspect an allowance after an amount-exceeds update.

## Tools

- `create_one_time_card`: Create a scoped one-time card number for a human who explicitly wants card details now. This is not the default "buy/order this for me" checkout flow; use request_purchase_approval for agent-managed shopping and checkout.

Inputs: expected_cents is the card spend cap in cents. merchant and reason are optional; when omitted, Allowance uses generic one-time-card labels for the approval request. Include merchant_url when known.

This tool returns immediately after creating the approval request. If the response is pending, it includes approval_url, approval_link, and user_message. Show user_message to the human, then immediately call wait_for_one_time_card with the returned allowance_request_id in the same turn. Do not stop after creating the request, and do not wait for the human to say they approved.
- `wait_for_one_time_card`: Wait for a pending one-time-card request, then issue the scoped card and return a secure reveal link after approval. Use this immediately after create_one_time_card returns a pending allowance_request_id, and use it again with the same id if a wait times out while the human is still approving.

Inputs: allowance_request_id is the id returned by create_one_time_card. expected_cents is the card spend cap in cents. timeout_seconds controls how long this call waits for iPhone approval before returning pending; default is 120 seconds and the maximum is 600 seconds. checkout_merchant and checkout_url are optional checkout context for issuing the card after approval.

If approved and ready, show only reveal_url to the human. Never show a card number, payment expiry, CVV, or an internal attempt id in chat. The reveal link is short-lived; its expiration is validated when opened, so this tool does not return a separate expiry. If card authorization is required, ask the human to approve on their phone and call wait_for_one_time_card again with the same allowance_request_id. If the request is still pending at timeout, show user_message to the human, then call wait_for_one_time_card again with the same allowance_request_id.
- `request_purchase_approval`: Create an iPhone approval request for a specific purchase intent. This does not issue a card or move money. expected_cents is the approved all-in ceiling; reason is the human-readable approved intent and criteria; merchant is optional and only restricts the card when supplied. Include merchant_url when known. allowance_expires_at accepts an ISO 8601 date/time, null or "default" for 24 hours from approval, or "max" for two weeks from approval.

If the response is pending, it includes approval_url and approval_link for the human to approve in Allowance. Immediately call wait_for_purchase_approval with the returned allowance_request_id. Do not create a duplicate request while one is pending. If the response is failed, explain the failure naturally and stop unless the human changes the request.
- `wait_for_purchase_approval`: Wait for a purchase approval request to become approved, denied, canceled, expired, failed, or timed out. Use this immediately after request_purchase_approval returns a pending allowance_request_id, and use it again with the same id if a wait times out while the human is still approving.

If approved, the result is authoritative for allowance_id, requires_shipping, and shipping_overridden_by_user. Complete checkout using your available capability. If denied, canceled, expired, or failed, tell the human and do not retry automatically.
- `get_checkout_context`: Fetch the approved checkout context: allowance metadata, final shipping truth, contact details, shipping address, and billing address. Use only after approval and only when checkout asks for contact, shipping, or billing fields.

Use the returned contact fields for name, email, and phone. Use shipping only when final requires_shipping is true. Use billing when the merchant asks for billing fields. Do not ask the human to reconfirm these non-secret details after approval unless the tool returns missing data. This tool never returns card number, expiry, or CVV.
- `issue_card`: Issue scoped virtual card credentials for an approved checkout allowance. Keep the returned card fields private by default. Use only when the merchant payment form is visible and ready for card entry with the final amount known. Do not call while still browsing products, cart, login, shipping, delivery, discounts, or review pages; issued cards have a short TTL.

Pass allowance_id, expected_cents for the final charge, checkout_merchant as shown on the checkout page, and checkout_url when available. Type returned card credentials directly into the merchant form through browser automation unless the human explicitly asks to see them; then show the returned card number, payment expiry, CVV, network, and limit in chat. If status is pending_auth, ask the human to approve on their phone, then call complete_purchase_auth. If the amount exceeds approval, stop and ask the human to update the allowance in the app before continuing.
- `complete_purchase_auth`: Complete a payment/card authorization challenge after issue_card returned pending_auth. Use only for that case. Ask the human to approve on their phone, then call this with allowance_id and attempt_id.

If this returns card credentials, type them directly into the merchant form unless the human explicitly asks to see them; then show the returned card number, payment expiry, CVV, network, and limit in chat. If checkout still needs contact/address fields, use get_checkout_context separately.
- `report_purchase_result`: Close out a local checkout attempt after the merchant succeeds or fails. Always call this for local checkout, including failures after a card was issued.

For success, pass status="success", allowance_id, attempt_id, and charged_cents. For failure, pass status="failure" or status="failed", allowance_id, attempt_id, error_code, and merchant_message when available. error_code must be one of: card_declined, card_declined_avs, card_declined_cvv, checkout_abandoned, checkout_error, checkout_timeout, item_unavailable, merchant_rejected, price_mismatch, unsupported_card. If the payment processor or merchant returns a code outside this list, use checkout_error and include the raw merchant message when useful.
- `manage_allowances`: View or manage existing allowances. This is account management, not part of the normal purchase checkout path.

Use action="list" to list allowances. List output is intentionally concise and limited by default; summarize the returned rows and use action="get" with allowance_id to inspect one allowance in full detail, including after the human updates a cap in the app. Use action="purchase_attempts" with allowance_id to inspect attempts. Use action="pause" or action="revoke" only when the human explicitly asks for that account-management action. Revocation is permanent and cannot be undone; get explicit human confirmation before revoke.