Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

open_billing_portal

Read-only

Get a Stripe Billing Portal URL so a paying customer can update their card, view invoices, or cancel; send plan switches to Kiln Billing in the web app.

Instructions

Get a Stripe Billing Portal URL so a paying customer can update their card, see invoices, or cancel. Plan switches are not in the portal and never made by an agent: explain the plans, then send the person to Billing in the Kiln web app (https://app.kiln3d.com/settings/billing) to choose and confirm.

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": "open_billing_portal"
  }
}

Input Schema

NameRequiredDescriptionDefault
return_urlNoNo longer used, for the same reason. Default: "https://app.kiln3d.com/settings/billing".
license_keyNoNo longer used. Accepted so an older install's call still works.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.5.1
    • addedInput schema / properties / license_key / description
      Added value: +"No longer used.  Accepted so an older install's call still works."
    • changedInput schema / properties / return_url / description
      Previous value: -"Default: \"https://kiln3d.com/account\"."New value: +"No longer used, for the same reason. Default: \"https://app.kiln3d.com/settings/billing\"."
  2. Addedv1.5.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds real behavioral content beyond that: the tool returns a URL rather than performing changes, and agents must never make plan switches. It does not mention URL expiry, subscription-required errors, or auth prerequisites, which would matter for a billed-account operation.

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 sentences, zero filler, with the core action and scope front-loaded before the exclusion and redirect. The embedded URL is functional, not decorative.

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?

No output schema exists, so the description carries the burden of saying what comes back, and it does state the return value is a Billing Portal URL. With zero required parameters and annotations covering safety, the main residual gap is failure behavior (no active subscription, unreachable Stripe) which goes unmentioned.

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 100% and both parameters are documented there as accepted-but-unused legacy fields; the description says nothing about them. Baseline 3 applies because the schema fully carries parameter meaning, though a one-line note that no arguments matter would have prevented an agent from trying to populate return_url or license_key meaningfully.

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 (get a Stripe Billing Portal URL) plus the customer-facing purpose (update card, see invoices, cancel). It explicitly carves out what this tool does NOT cover (plan switches), which separates it from siblings like start_subscription_checkout and upgrade_kiln.

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 use case and an explicit exclusion, then names the alternative path for the excluded case: explain plans, then send the user to the Kiln web app billing settings URL. An agent has a complete routing rule without needing to infer anything.

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

Deploy Server

Other Tools