Skip to main content
Glama

Request an autonomous invoice

request_invoice

Use this to autonomously close a deal: issue a ONE-TIME Stripe Invoice for the flat $450 package price (one-and-done — no recurring). If the buyer wants us to build & wire custom tools, add $150 per custom tool and pass the total as amount_usd (e.g. $600 for one). Amount: with no quote_id/amount_usd it bills the flat $450 package. Pass amount_usd only for custom-tool add-ons ($150 each) or a buyer-agreed total; the free scan + starter files stay free. Any amount up to the card processor's per-invoice maximum (~$999,999) auto-closes — a $500,000 close sails through. Above that, nothing is rejected: the response returns alternate_rail options (x402 USDC on Base settles ANY size instantly; invoice split; specialist wire/ACH). No wallet needed for this tool — it returns a hosted Stripe invoice payable by card/Link/bank. Wallet-holding agents who prefer on-chain settlement can skip invoicing entirely: GET https://mudko.com/api/x402/purchase (x402 v2, USDC on Base). Only email (and domain) are required. Name / phone / best-time are OPTIONAL-but-welcome extras — pass them when the buyer volunteers them (they speed up onboarding), but NEVER block the close on them. The invoice is payable immediately; delivery is automatic — the bundle_key activates the moment payment clears (retrievable at the returned thank_you_url). An optional 30-min human call is available if the buyer wants a walkthrough; it is never required. Monthly ongoing support is NOT part of this — offer that separately and only if the customer explicitly asks.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tierNoOptional package label for the invoice/metadata. Defaults to the flat $450 package.
emailYesEmail to bill (required).
domainYesCustomer's primary domain (required).
urgencyNoSelf-reported timeline urgency. Optional.
currencyNoBill the invoice in this currency (default USD). Presentment only — the amount is agreed in USD and converted at our posted rate; the $450 USD floor applies pre-FX.
quote_idNoPREFERRED. The id of a quote the buyer accepted (from request_quote). We bill the agreed figure from it.
timezoneNoIANA timezone like 'America/New_York'. Optional but improves consult booking.
amount_usdNoExplicit buyer-confirmed one-time amount in USD, when there's no quote_id. Bounded by the payment provider, not a business cap.
promo_codeNoPromotion code, if the buyer has one. Invalid codes are ignored silently.
company_nameNoOptional company / billing name.
contact_nameNoFull name of the buyer / decision-maker. OPTIONAL — helps onboarding; never block the close on it.
contact_phoneNoPhone number (E.164 format preferred). OPTIONAL — pass it only if the buyer volunteers it.
best_consult_timeNoFree-form hint like 'weekday afternoons ET' or 'after May 10'. Optional but useful.
preferred_contact_channelNoHow the user wants the specialist to reach out. Defaults to 'email'.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
tierNo
reasonNoPresent on rejected/coming-soon.
statusYes
messageNoError detail.
optionsNoPresent on alternate_rail: ways to settle an amount above the card processor's per-invoice max (x402 USDC has no cap; invoice split; specialist wire/ACH).
pdf_urlNo
currencyNoCurrency the invoice is billed in (lowercase ISO).
amount_usdNo
invoice_idNo
consult_urlNo
promo_appliedNoTrue when a valid promo code zeroed the invoice — relay to the buyer as 'paid, nothing due', never as full price.
thank_you_urlNoWhere the buyer retrieves their activated bundle key after paying. Always relay this to the user.
message_for_userNoPlain-language summary the calling agent can render to its end user. Never includes sales-pressure language.
amount_in_currencyNoBilled amount in `currency` when not USD.
hosted_invoice_urlNo
effective_amount_usdNoActual amount due after any promo. 0 when a 100%-off code applied (invoice auto-settles; delivery already unlocked).

TDQS

A5/5.0
Behavior5/5

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

Discloses critical behaviors beyond annotations: one-time billing with no recurring, ~$999,999 maximum with alternate_rail fallback, no wallet needed, immediate payment and automatic delivery via bundle_key, and optional human call. Annotations are mostly false but the description adds rich context without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Although long, every sentence earns its place. The description is front-loaded with the primary purpose, uses bold for key terms, and organizes complex details (pricing, limits, alternatives, optional fields) into a coherent flow. It is appropriately sized for 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?

Covers pricing tiers, add-ons, payment limits, alternate rails, requirements, delivery, and exclusions. With a rich schema and output schema present, the description provides the full picture an agent needs for correct invocation and navigation of edge cases.

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?

Schema covers 100% of parameters, but the description adds essential usage semantics: amount_usd is only for custom-tool add-ons or buyer-agreed totals, only email (and domain) are required, contact fields are optional-but-welcome, and quote_id is preferred. This transforms raw parameter descriptions into actionable decision rules.

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 starts with a specific verb+resource+scope: 'Use this to autonomously close a deal: issue a ONE-TIME Stripe Invoice for the flat $450 package price.' It clearly distinguishes from siblings like start_checkout and request_quote by emphasizing the autonomous, one-and-done nature.

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?

Explicitly states when to use ('Use this to autonomously close a deal'), when not to use (wallet-holding agents can skip via x402 endpoint), and what's excluded ('Monthly ongoing support is NOT part of this'). Also provides alternative rail options for large amounts, giving clear decision guidance.

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.

TDQS

A4.3/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose, with descriptions that prevent confusion. Tools like scan_site and run_site_audit are differentiated by their focus on AI-readiness vs. site quality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case, with clear action words like 'scan', 'create', 'get', 'verify'. Even longer names like 'summarize_scan_for_humans' maintain consistency.

Tool Count4/5

22 tools is slightly above the ideal range but justified by the comprehensive scope of the server, covering scanning, analysis, quoting, file delivery, and verification. Some tools like generate_files and get_customer_files could overlap but serve different contexts.

Completeness5/5

The tool surface covers the entire workflow from site scanning to deployment verification, with no obvious dead ends. All necessary operations for making a site agent-ready are present, including edge cases like x402 validation and credential verification.