Skip to main content
Glama

update_product_rate_plan_charge

Update a product rate plan charge by submitting only the fields you want to change, such as price or billing period. The tool merges your input with existing charge data and validates before calling the API.

Instructions

Update a product rate plan charge. PUT /product-rateplan-charges/{chargeId}. You can send only the fields you want to change (e.g. chargeTier with new price); the tool fetches the current charge and merges your input so the backend receives all required fields. Validates in MCP before calling the API. Optional inputs: name, chargeType, chargeModel, billCycleType, category, chargeTier (currency, price as dollars e.g. 22.87 or cents e.g. 2287), taxable, weight, endDateCondition, billingPeriod, billingTiming, billingPeriodAlignment, specificBillingPeriod, billCycleDay (1-31 when billCycleType specificDayOfMonth), weeklyBillCycleDay (when specificDayOfWeek), monthlyBillCycleYear (1-12 when specificMonthOfYear). When chargeType is recurring, billingPeriod, specificBillingPeriod, billingPeriodAlignment, billingTiming are required.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chargeIdYesProduct rate plan charge ID (required)
nameNoCharge name
chargeTypeNooneTime, recurring, or usage
chargeModelNoflatFeePricing, perUnitPricing, tieredPricing, or volumePricing
billCycleTypeNochargeTriggerDay, defaultFromCustomer, specificDayOfMonth, specificDayOfWeek, specificMonthOfYear, subscriptionStartDay, subscriptionFreeTrial
categoryNophysical or digital
chargeTierNoArray of {currency, price (dollars e.g. 22.87 or cents e.g. 2287), optional startingUnit, endingUnit, priceFormat, tier}. To update only price, send this and chargeId; other fields are filled from current charge.
taxableNoWhether taxable
weightNoWeight (integer)
descriptionNoDescription
endDateConditionNosubscriptionEnd or fixedPeriod
billingPeriodNoday, week, month, or year (required if chargeType recurring)
billingTimingNoinAdvance or inArrears (required if chargeType recurring)
billingPeriodAlignmentNoalignToCharge, alignToSubscriptionStart, alignToTermStart (required if chargeType recurring)
specificBillingPeriodNoRequired when chargeType recurring
billCycleDayNo1-31 when billCycleType is specificDayOfMonth
weeklyBillCycleDayNosunday, monday, tuesday, wednesday, thursday, friday, saturday when billCycleType is specificDayOfWeek
monthlyBillCycleYearNo1-12 when billCycleType is specificMonthOfYear
Behavior3/5

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

No annotations provided, so description carries full behavioral disclosure burden. Describes merge logic and pre-validation, and explains price format. However, does not address error handling, idempotency, or consequences of invalid data beyond validation.

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?

The description is well-structured: starts with purpose and endpoint, then lists optional inputs with conditional requirements. It is dense but not wasteful; every sentence adds value. Slightly long but necessary for the complexity.

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?

Given 18 parameters, no output schema, and no annotations, the description covers all parameters, merge behavior, validation, and required conditions thoroughly. It provides sufficient context for an AI agent to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage, baseline is 3. Description adds meaning by explaining the merge behavior for chargeTier, specifying price formats (dollars or cents), and clarifying required parameters conditionally (e.g., billingPeriod when chargeType recurring).

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 clearly states the tool updates a product rate plan charge, specifies the HTTP method and endpoint, and distinguishes from sibling tools like create or delete by using 'Update' and mentioning the merge logic.

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?

Explains when to use the tool (to update an existing charge), describes the partial update behavior (send only changed fields), and lists required fields for recurring charges. Lacks explicit when-not-to-use guidance, but context from siblings and the description suffice.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rhinosaas/rebillia-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server