Aqua Flow store

Create checkout link

create_checkout_link

Read-onlyIdempotent

Build a link that fills the store cart with the chosen products and quantities, and show an order summary view. It does not place an order or take payment: the shopper opens the link, reviews the cart and pays on the site. Use when the user has decided what to buy.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "items": "<items>"
    },
    "name": "create_checkout_link"
  }
}

Input Schema

Name	Required	Description	Default
`items`	Yes	Products to put in the cart

Output Schema

Name	Required	Description	Default
`lines`	Yes
`total`	Yes
`currency`	No
`checkout_url`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, and the description is consistent with them by clarifying that no order is placed and no payment is taken — the link only stages a cart. The detail that the shopper completes payment on the site resolves the main ambiguity an agent would have. It omits link lifetime/expiry and reuse behavior, which would be useful given idempotentHint.

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, then the critical non-behavior, then the trigger condition — a sensible order with no filler. The clause after the colon partly restates the preceding clause, a minor redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the schema carries the item limits. For a one-parameter link generator the description covers purpose, boundary conditions and trigger well; only link lifecycle details are missing.

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?

Only one parameter, and schema description coverage is 100% with min/max constraints and per-item quantity already documented. The description's phrase 'chosen products and quantities' restates the schema rather than adding new meaning (e.g., whether duplicate product_ids merge), so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and artifact: 'Build a link that fills the store cart with the chosen products and quantities' plus an order-summary view. That is clearly distinct from the read-only siblings (search, compare, get, list), though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use when the user has decided what to buy' gives a positive trigger condition, and the second sentence draws a firm boundary: it does not place an order or take payment. It stops short of naming an alternative tool for the case where the user has not yet decided.

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

All Aqua Flow store 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?