CueFrame

Create Checkout

create_checkout

Top up the CURRENT org's credit wallet. Body { plan: "credit_pack_10"|"credit_pack_30"|"credit_pack_100" } → returns { url }: a hosted Stripe checkout page to open in a browser and confirm payment. There are no subscription tiers — a pack is a one-off top-up, and it is also the only thing that raises the generation (premium_credits) allowance. Always a URL — an existing saved card is NEVER charged silently; the human confirms on Stripe. The org is resolved from your key, never the body. Requires the billing:write scope. Only send a user here when get_account shows the relevant balance at or near zero. Discover the packs with list_plans.

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": {
      "body": "<body>"
    },
    "name": "create_checkout"
  }
}

Input Schema

Name	Required	Description	Default
`body`	Yes
`commandId`	No	Retry identity. A call repeated with the same commandId returns the first result instead of acting twice.

Output Schema

Name	Required	Description
`url`	No	Hosted Stripe checkout URL to open in a browser to complete payment. Always present on success — an existing saved card is never charged without confirming here.
`plan`	No
`interval`	No
`productId`	No	Resolved billing catalog product id.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedOct 28, 2026
- addedInput schema / $defs
```
Added value: +{
+  "__schema0": {
+    "enum": [
+      "month",
+      "year"
+    ],
+    "type": "string"
+  },
+  "__schema1": {
+    "maxLength": 128,
+    "minLength": 1,
+    "type": "string"
+  }
+}
```
- addedInput schema / properties / body / properties / interval / $ref
```
Added value: +"#/$defs/__schema0"
```
- removedInput schema / properties / body / properties / interval / enum
```
Removed value: -[
-  "month",
-  "year"
-]
```
- removedInput schema / properties / body / properties / interval / type
```
Removed value: -"string"
```
- addedInput schema / properties / commandId / $ref
```
Added value: +"#/$defs/__schema1"
```
- removedInput schema / properties / commandId / maxLength
```
Removed value: -128
```
- removedInput schema / properties / commandId / minLength
```
Removed value: -1
```
- removedInput schema / properties / commandId / type
```
Removed value: -"string"
```

Changed1 schema field changedOct 22, 2026

addedInput schema / properties / commandId

Added value: +{
+  "description": "Retry identity. A call repeated with the same commandId returns the first result instead of acting twice.",
+  "maxLength": 128,
+  "minLength": 1,
+  "type": "string"
+}

First observedOct 10, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, but the description adds genuinely new facts: an existing saved card is NEVER charged silently, the human confirms on Stripe, the org is resolved from the API key and not the body, and billing:write scope is required. It stops short of covering idempotency/retry behavior (commandId) even though idempotentHint=false, which is the one behavioral gap.

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 core action and return value are front-loaded in the first sentence, and every subsequent sentence adds a real constraint. It is somewhat run-on with several em-dash asides and could be trimmed, but there is no filler.

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?

For a mutating, payment-adjacent tool it covers what an agent needs: what is created, that the output is a { url } to hand to a human, that no charge happens server-side, the required scope, and where to look before calling. An output schema exists, so the terse return-value mention is sufficient.

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?

With 50% schema coverage the description must compensate, and it partially does: it enumerates the three plan values and warns that the org is never in the body. But it silently omits the `interval` and `commandId` parameters entirely, and the schema's own `interval` description (monthly/annual, '~2 months free') and `plan` description ('Plan tier to subscribe to') actively conflict with the description's insistence that no subscription exists.

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 ('Top up the CURRENT org's credit wallet') and immediately clarifies the concept against the nearest confusion ('There are no subscription tiers — a pack is a one-off top-up'), which no sibling tool covers. An agent can distinguish this from get_account, get_usage, and list_plans without opening a 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?

Explicitly gates invocation: 'Only send a user here when get_account shows the relevant `balance` at or near zero' and routes discovery to 'list_plans'. That is a when-to-use, a when-not-to-use, and named alternatives in one place — the highest bar.

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

All CueFrame 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.