Agentic Fabrication Network (AFN)

Create checkout

create_checkout

Create the order and get a hosted payment link for a chosen offer. Call this as soon as the user picks an offer + shipping speed. This tool takes NO personal details: never ask for — and never pass — a name, address, email, or phone; the secure payment page collects the shipping address, email, and phone (and billing) itself, even when the user volunteered them in chat. Returns checkout_url — give it to the user to pay; UFP places the vendor order automatically after payment.

Input Schema

Name	Required	Description
`offer_id`	Yes
`return_url`	No	Exact URL of the page the user is on right now, IF the client application knows it (a web app embedding this tool passes its own page URL). The post-payment page shows a 'Return to <site>' button pointing here. Omit when unknown — never invent one.
`coupon_code`	No	Coupon code, only if the user provided one (early-adopter codes from the AFN team). Case-insensitive. The discount appears on the payment page; a 100%-off code makes the total $0 with no card required. Never invent or guess a code.
`shipping_option_id`	Yes	One of the offer's shipping option ids

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedOct 26, 2026

removedInput schema / properties / billing_city
```
Removed value: -{
-  "type": "string"
-}
```

removedInput schema / properties / billing_name

Removed value: -{
-  "description": "Billing address, only when the buyer answered the billing question (e.g. said it differs from shipping, or a checkout UI's 'same as shipping' checkbox — then send the shipping values verbatim). Never ask for it; omit and the payment page handles billing.",
-  "type": "string"
-}

removedInput schema / properties / billing_state

Removed value: -{
-  "description": "Two-letter US state",
-  "maxLength": 2,
-  "minLength": 2,
-  "type": "string"
-}

removedInput schema / properties / billing_street1
```
Removed value: -{
-  "type": "string"
-}
```
removedInput schema / properties / billing_street2
```
Removed value: -{
-  "type": "string"
-}
```
removedInput schema / properties / billing_zip
```
Removed value: -{
-  "type": "string"
-}
```

removedInput schema / properties / city

Removed value: -{
-  "type": "string"
-}

removedInput schema / properties / email

Removed value: -{
-  "description": "Buyer email (only if the user provided it)",
-  "format": "email",
-  "type": "string"
-}

removedInput schema / properties / name

Removed value: -{
-  "description": "Recipient full name (only if the user provided it)",
-  "type": "string"
-}

removedInput schema / properties / phone

Removed value: -{
-  "type": "string"
-}

removedInput schema / properties / state

Removed value: -{
-  "description": "Two-letter US state",
-  "maxLength": 2,
-  "minLength": 2,
-  "type": "string"
-}

removedInput schema / properties / street1

Removed value: -{
-  "description": "Street address (only if the user provided it)",
-  "type": "string"
-}

removedInput schema / properties / street2

Removed value: -{
-  "type": "string"
-}

removedInput schema / properties / zip

Removed value: -{
-  "type": "string"
-}

Changed1 schema field changedAug 25, 2026

addedInput schema / properties / coupon_code

Added value: +{
+  "description": "Coupon code, only if the user provided one (early-adopter codes from the AFN team). Case-insensitive. The discount appears on the payment page; a 100%-off code makes the total $0 with no card required. Never invent or guess a code.",
+  "type": "string"
+}

Changed6 schema fields changedJul 26, 2026

addedInput schema / properties / billing_city
```
Added value: +{
+  "type": "string"
+}
```

addedInput schema / properties / billing_name

Added value: +{
+  "description": "Billing address, only when the buyer answered the billing question (e.g. said it differs from shipping, or a checkout UI's 'same as shipping' checkbox — then send the shipping values verbatim). Never ask for it; omit and the payment page handles billing.",
+  "type": "string"
+}

addedInput schema / properties / billing_state

Added value: +{
+  "description": "Two-letter US state",
+  "maxLength": 2,
+  "minLength": 2,
+  "type": "string"
+}

addedInput schema / properties / billing_street1
```
Added value: +{
+  "type": "string"
+}
```
addedInput schema / properties / billing_street2
```
Added value: +{
+  "type": "string"
+}
```
addedInput schema / properties / billing_zip
```
Added value: +{
+  "type": "string"
+}
```

Changed1 schema field changedJul 26, 2026

addedInput schema / properties / return_url

Added value: +{
+  "description": "Exact URL of the page the user is on right now, IF the client application knows it (a web app embedding this tool passes its own page URL). The post-payment page shows a 'Return to <site>' button pointing here. Omit when unknown — never invent one.",
+  "format": "uri",
+  "type": "string"
+}

First observedJul 24, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only say it is a non-read-only, non-destructive, closed-world call. The description adds the substantive behavior: no PII is accepted because the hosted page collects address/email/phone, the returned checkout_url is what the user pays with, and the vendor order is placed automatically after payment. That is exactly the context annotations cannot carry.

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 action and the trigger, then the PII constraint, then the return value — good ordering. Slightly padded by the em-dash aside and the double negative phrasing ('never ask for — and never pass'), though the emphasis is arguably warranted for a high-risk constraint.

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?

No output schema exists, and the description explicitly explains the single meaningful return value (checkout_url) and what happens downstream after payment. Combined with annotations and 75% schema coverage, an agent has everything needed to call this correctly and hand off the result.

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?

Schema coverage is 75% and the schema already documents return_url and coupon_code well (including 'never invent one'). The description reinforces the required pair as 'the offer the user picked' and 'shipping speed' and reinforces the no-PII rule, but does not add meaning for coupon_code or return_url beyond the schema.

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?

States a specific verb and resource plus the outcome ('Create the order and get a hosted payment link for a chosen offer'), which separates it from quote-stage siblings like preview_quote and finalize_quote. An agent can tell exactly what this produces without opening the schema.

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?

Gives an explicit trigger ('Call this as soon as the user picks an offer + shipping speed') and a hard exclusion that overrides normal assistant behavior (never ask for or pass personal details, even if volunteered). The only missing piece is naming a sibling as the alternative, but the trigger condition is unambiguous.

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

All Agentic Fabrication Network (AFN) tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?