Freelancer Ops MCP

Overview Schema Source Related Servers Discussions Admin

stripe_invoice_items_create

Add a line item to a Stripe invoice using a price or amount. Without an invoice, the line waits for the customer's next subscription invoice.

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.

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": {
      "customer": "<customer>"
    },
    "name": "stripe_invoice_items_create"
  }
}

Input Schema

Name	Required	Description
`amount`	No	The 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.
`period`	No	The service period this line covers.
`invoice`	No	The 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.
`pricing`	No	An existing price to bill, named as `pricing.price`.
`taxCode`	No	The tax code for what is being billed.
`currency`	No	Three-letter lowercase ISO currency code.
`customer`	Yes	The ID of the customer to bill.
`metadata`	No	Set of key-value pairs attached to the line.
`quantity`	No	How many units this line bills.
`discounts`	No	Coupons or promotion codes applying to this line alone.
`priceData`	No	A price created inline for this line.
`description`	No	What this line says on the invoice.
`taxBehavior`	No	Whether the amount includes tax. Once set to inclusive or exclusive it cannot be changed.
`discountable`	No	Whether invoice-level discounts apply to this line.
`subscription`	No	Bill this line on that subscription's invoices only.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 18, 2026

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.