Skip to main content
Glama
Sign In

Keepp

by link.keepp
OverviewDiscussionsAdmin

Change a product

update_product
DestructiveIdempotent

Changes a product. Send only what changes: every field left out keeps its current value, and null clears an optional one. Pricing is replaced whole when sent. Orders already placed keep the price they were bought at. If the product is on the page, the page is republished so it shows the change. Show what changes, the price and currency especially. Before calling, show the person exactly what will be saved and get their explicit yes in the conversation. Never assume a currency.

Input Schema

NameRequiredDescriptionDefault
titleNoWhat the product is called.
policyNoRefund and terms shown to the customer before they book.
pricingNoHow it is paid for. "stripe" takes real money and needs Stripe connected; "display" only shows a price; "free" is no charge. Ask the person which currency they charge in before suggesting a price — never assume US dollars, and say the currency whenever you quote an amount.
supportNoHow a customer reaches the seller about a booking.
businessYesThe page handle, as it appears in keepp.link/<handle>.
mediaUrlsNoUp to 5 image URLs. Outside images are downloaded and stored on Keepp; nothing needs uploading.
productIdYesFrom list_catalog.
questionsNoExtra questions asked of the customer. Send the list back as get_product or get_booking_unit gave it.
stockLimitNoHow many can be sold; null for unlimited.
deliveryUrlNoWhat a buyer gets after paying: the course, download or file link. Shown on the buyer's order page once they have paid (their confirmation email links there, and never contains it).
descriptionNo
quantitySelectableNoWhether a buyer can choose how many to buy.
deliveryInstructionsNoShown with the delivery link on the buyer's order page after paying.

Output Schema

NameRequiredDescriptionDefault
updatedYesFalse when the person declined, and nothing was updated.
productIdNo
pageRefreshedNoWhether the published page was republished to show the change. False when it is not on the page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / pricing / description
      Previous value: -"How it is paid for. \"stripe\" takes real money and needs Stripe connected; \"display\" only shows a price; \"free\" is no charge. Free and display need a Pro plan. Ask the person which currency they charge in before suggesting a price — never assume US dollars, and say the currency whenever you quote an amount."New value: +"How it is paid for. \"stripe\" takes real money and needs Stripe connected; \"display\" only shows a price; \"free\" is no charge. Ask the person which currency they charge in before suggesting a price — never assume US dollars, and say the currency whenever you quote an amount."
  2. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations (destructiveHint true, idempotentHint true), the description discloses genuine behavioral traits: omitted fields are preserved, null clears optional fields, pricing objects are replaced whole rather than merged, already-placed orders retain their purchase price, and the page is republished on change. This is exactly the mutation semantics an agent needs.

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-loads the core patch semantics in the first sentence and stays tightly focused. Slight redundancy — the 'never assume a currency' instruction is echoed from the pricing schema description, and the price/currency caution is restated — keeps it from a 5.

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?

For a 13-parameter mutation tool with nested objects, an output schema, and annotations covering safety hints, the description covers the missing pieces: patch vs replace semantics, side effects (republish), order-price immutability, and the confirmation-before-write requirement. Nothing critical is left to inference.

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?

Schema coverage is already 92% (baseline 3), but the description adds non-schema semantics: whole-pricing replacement on send and the hard rule to never assume a currency. That meaningfully augments the schema for the pricing field.

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?

States a specific verb and resource ("Changes a product") and immediately clarifies that it is a partial/patch update, which distinguishes it from create_product and delete_product. It does not name those siblings explicitly, so it stops short of a 5.

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?

Gives clear operational guidance: send only the changed fields, show the person the exact diff (especially price and currency) and get an explicit yes before calling. It lacks explicit routing to alternatives like update_booking_unit, but the when/how-to-invoke context is strong.

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

All Keepp toolsInspect
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