Tulina

stripe_checkout

Hosted collection — payment links and Checkout sessions.

"create_link" is the safest way to collect money here: it returns a reusable URL to a page hosted by Stripe, so no card number ever touches oto, and nobody is charged until a human opens it and pays.

⚠️ Creating a link can fail with "the product tax code is missing" on accounts eligible for managed payments (verified live). Fix it on the product: stripe_catalog(op="update_product", product_id=…, tax_code="txcd_10000000").

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "stripe_checkout"
  }
}

Input Schema

Name	Required	Description	Default
`op`	No	"list_links" (default) \| "get_link" \| "link_line_items" \| "create_link" \| "update_link" \| "list_sessions" \| "get_session" \| "session_line_items".	list_links
`_org`	No	Org (id) de CET APPEL. `oto_list_orgs()`.
`limit`	No
`_group`	No	Équipe (id) de CET APPEL, sous son org parente.
`active`	No	filter on "list_links"; on "update_link", `active=false` switches a link off without deleting it.
`status`	No
`_run_id`	No	OBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
`_project`	No	Projet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
`max_uses`	No	"create_link" — the link deactivates itself after N completed checkouts (1 = paid once, by whoever opens it first).
`metadata`	No	on the link itself. Stripe does NOT copy it onto the subscription / payment created at checkout — use `created_metadata` for that.
`price_id`	No	REQUIRED by "create_link" — from `stripe_catalog`.
`quantity`	No	"create_link" (default 1).
`_instance`	No	Instance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
`session_id`	No	REQUIRED by "get_session"/"session_line_items".
`customer_id`	No
`starting_after`	No
`payment_link_id`	No	REQUIRED by "get_link"/"link_line_items"/"update_link".
`created_metadata`	No	"create_link" — metadata set on what each checkout creates: the subscription for a recurring price, the payment intent otherwise. Reads the price first (key needs Prices: Read).
`managed_payments`	No	"create_link" — `false` refuses Stripe Managed Payments (Stripe as merchant of record), `true` asks for it. Omitted = the account's own default, and an account can turn it ON for every new link without anyone noticing: pass `false` when the business sells in its own name with Stripe Tax.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries the full disclosure burden. It does valuable work for create_link — no card data touches oto, no charge until a human pays, the URL is reusable, and creation can fail on a missing product tax code with a concrete fix. But the mutation surface of update_link and the read operations are left undescribed, so half the behavioral picture is missing.

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 safest-path recommendation, then the warning and its fix. Every sentence carries operational weight; the only cost is that the prose is heavily skewed to one of eight operations rather than balanced.

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

Completeness3/5

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

For an 8-operation multiplexer with 19 parameters and no annotations, the description explains only the create_link path. Read operations and update_link semantics are undocumented, and there is no note on which ops mutate Stripe state. The output schema exists, so return-value explanation is correctly omitted.

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 description coverage is 79%, so the schema already documents most parameters (price_id, session_id, payment_link_id, max_uses, managed_payments). The description adds a cross-tool remedy for the tax-code failure, which is genuinely beyond the schema, but does not clarify the op multiplexing or which parameters bind to which operation beyond what the schema states.

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?

The opening line names the resource precisely — payment links and Checkout sessions — and the description frames the tool as a hosted-collection surface, which distinguishes it from siblings like stripe_payment or stripe_invoice. It does not explicitly say how it differs from those siblings, but the verb+resource is unambiguous.

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

Usage Guidelines3/5

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

It gives one strong routing hint ('create_link is the safest way to collect money here') and explains why, plus a remedy path via stripe_catalog for the tax-code failure. However, it offers no guidance for the remaining seven operations (list_links, get_link, update_link, list_sessions, etc.) or for when to prefer this tool over stripe_payment/stripe_invoice.

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

All Tulina 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?