AIURION Agentic 3D Printing — San Francisco

Create Approved Stripe Checkout

printing.checkout.create

Create a Stripe Checkout URL after the customer approves the quote. Stripe authorizes the card; AIURION captures payment only after manually approving the model.

Input Schema

TableJSON Schema

Name	Required	Description
`quoteId`	Yes	AIURION quote UUID returned by printing.quotes.create.
`materialId`	No	AIURION material identifier listed by printing.capabilities.get.
`accessToken`	No	Guest token returned by printing.sessions.start. Optional when Authorization already carries a permanent key or guest token.
`idempotencyKey`	Yes	Stable unique key for retrying checkout creation.
`productionSpeed`	No	Requested production priority: standard or rush.
`approvalConfirmed`	Yes	Set true only after the customer reviews and approves the quote.
`fulfillmentMethod`	No	How the completed parts should be delivered.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already signal a write operation that is not destructive. The description additionally explains the payment model: Stripe authorizes the card, while AIURION captures payment only after manual approval. This adds important behavior beyond the schema.

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?

Two tightly written sentences give the key purpose and the payment-capture nuance with no filler. The most important trigger condition is front-loaded in the first sentence.

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?

The description is sufficient given the annotated schema, output schema, and clear preconditions. It defines the action, the correct timing, and the payment-flow caveat, so an agent has enough to select and call the tool correctly.

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?

Schema coverage is 100%, so parameter meaning is already fully documented. The description adds no new parameter-specific semantics and does not need to, given the rich schema descriptions.

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 names a specific action (create) and resource (Stripe Checkout URL) and adds a precise precondition (after the customer approves the quote). This clearly separates it from printing.quotes.create, which creates the quote itself.

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?

It explicitly says to use the tool after customer approval of the quote, which gives clear contextual timing. It stops short of explicitly naming alternatives or giving when-not-to-use guidance, but the resource and precondition are enough for most cases.

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

All AIURION Agentic 3D Printing — San Francisco tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation5/5

Each tool targets a distinct resource/action: capabilities, checkout, orders, quotes (create/get/update), and sessions. There is no overlap in purpose, so an agent can unambiguously select the correct tool.

Naming Consistency5/5

All tool names follow a consistent dotted pattern: printing.<resource>.<action>. Verbs are uniform (get, create, update, start) and snake_case is used throughout, making the API predictable.

Tool Count5/5

Seven tools is well-scoped for a 3D printing service, covering the main workflow (capability discovery, session creation, quote management, checkout, and order tracking) without redundancy or bloat.

Completeness4/5

The surface covers the core lifecycle: capabilities, session, quote CRUD (create/get/update), checkout, and order status. A minor gap is lack of explicit delete/cancel operations, but these can be worked around via update or are not essential for the stated flow.

Resources

Need Help?