Skip to main content
Glama
r28ai

stripe-billing-ops-mcp

by r28ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

stripe_invoice_items_create

Add a line item to a Stripe invoice, either from an existing price or a custom amount. Attach it to a draft invoice or let it bill on the next subscription cycle.

Instructions

Add a line to an invoice. Name an existing price as pricing.price, or give an amount directly. Without invoice the line waits for the customer's next subscription invoice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
amountNoThe amount in the smallest currency unit. Negative reduces what the invoice is due. Cents, not dollars: $15.00 is 1500, and 15 puts fifteen cents on the invoice. Multiply a decimal amount by 100.
periodNoThe service period this line covers.
invoiceNoThe draft invoice to add this line to, at most 250 lines. Absent, the line waits for the customer's next subscription invoice and a standalone invoice will not collect it on its own.
pricingNoAn existing price to bill, named as `pricing.price`.
taxCodeNoThe tax code for what is being billed.
currencyNoThree-letter lowercase ISO currency code.
customerYesThe ID of the customer to bill.
metadataNoSet of key-value pairs attached to the line.
quantityNoHow many units this line bills.
discountsNoCoupons or promotion codes applying to this line alone.
priceDataNoA price created inline for this line.
descriptionNoWhat this line says on the invoice.
taxBehaviorNoWhether the amount includes tax. Once set to inclusive or exclusive it cannot be changed.
discountableNoWhether invoice-level discounts apply to this line.
subscriptionNoBill this line on that subscription's invoices only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations disclose mutation (readOnlyHint=false) and open-world reach, so the safety profile is covered. The description usefully adds lifecycle behavior — that a line without `invoice` defers to the customer's next subscription invoice — which is non-obvious and not captured by annotations.

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?

Three short sentences, zero filler, with the core action front-loaded and the deferred-invoice caveat last. Every sentence earns its place.

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?

For a 15-parameter mutation tool with full schema coverage, annotations for the mutation profile, and no output schema, the description covers purpose, the two pricing paths, and the missing-invoice behavior. The required `customer` parameter is left to the schema, a minor gap.

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% and the schema already documents all 15 parameters in depth (units, formats, limits). The description's `pricing.price` vs `amount` note restates what the schema says, adding little beyond it, so baseline 3 is appropriate.

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?

"Add a line to an invoice" gives a specific verb and resource that clearly maps to creating a Stripe invoice item, and the pricing/amount guidance sharpens it. It does not explicitly name or rule out sibling tools such as stripe_invoices_create, so it stops short of full sibling differentiation.

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 states two concrete ways to supply the line's value (name an existing price via `pricing.price`, or pass `amount` directly) and explains the conditional behavior when `invoice` is omitted. It gives clear operating context but no explicit when-to-use-this-vs-an-alternative routing.

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