Skip to main content
Glama

Edit a service, class or rental

owner_update_offering
DestructiveIdempotent

Only for business owners signed in to Awning. Change name, description, duration, price, advance booking or cleanup time, or archive it. Confirm with the owner first; archiving cannot be undone. Use it to change a service that exists; to add a new one use owner_add_offering. Send only what changes.

Input Schema

NameRequiredDescriptionDefault
nameNoNew name
priceNoNew price in major units of the business currency, e.g. 2500
archiveNoTrue removes the service from the page; this cannot be undone
business_idNoWhich business, when the owner runs several: business_id from owner_status. Leave out when there is only one.
descriptionNoNew description
offering_idYesThe service to change: offerings[].offering_id from get_business or owner_status
duration_minNoNew length in minutes
buffer_after_minNoCleanup or turnaround minutes kept free after each booking
min_advance_hoursNoHow many hours ahead a booking must be made

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changed
    • addedInput schema / properties / archive / description
      Added value: +"True removes the service from the page; this cannot be undone"
    • addedInput schema / properties / buffer_after_min / description
      Added value: +"Cleanup or turnaround minutes kept free after each booking"
    • changedInput schema / properties / business_id / description
      Previous value: -"Only needed if you manage several businesses"New value: +"Which business, when the owner runs several: business_id from owner_status. Leave out when there is only one."
    • addedInput schema / properties / description / description
      Added value: +"New description"
    • addedInput schema / properties / duration_min / description
      Added value: +"New length in minutes"
    • addedInput schema / properties / min_advance_hours / description
      Added value: +"How many hours ahead a booking must be made"
    • addedInput schema / properties / name / description
      Added value: +"New name"
    • addedInput schema / properties / offering_id / description
      Added value: +"The service to change: offerings[].offering_id from get_business or owner_status"
    • addedInput schema / properties / price / description
      Added value: +"New price in major units of the business currency, e.g. 2500"
  2. Changed2 schema fields changed
    • addedInput schema / properties / description / maxLength
      Added value: +600
    • addedInput schema / properties / name / maxLength
      Added value: +120
  3. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, but the description adds crucial context: 'Confirm with the owner first; archiving cannot be undone.' It also specifies authentication ('business owners signed in to Awning') and partial-update semantics, going beyond the structured 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?

Four tight sentences, front-loaded with the primary purpose and constraints. No redundant or filler text; every sentence adds useful guidance.

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 the mutation complexity, destructive nature, and absent output schema, the description covers authentication, confirmation, irreversibility, alternative tools, and partial updates. It provides everything an agent needs to invoke correctly.

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 100%, so the baseline is 3. The description adds useful meaning by listing the editable fields and clarifying 'Send only what changes', which communicates partial-update behavior not explicit in the schema. However, it doesn't add further parameter-level detail beyond what the schema already provides.

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: 'Change ... a service that exists', lists editable fields, and explicitly distinguishes from the sibling tool owner_add_offering. An agent can tell exactly what it does.

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?

Explicitly states when to use (business owners signed in to Awning, to change existing services), when not to use (archiving requires confirmation, adding a new service uses owner_add_offering), and how to call it ('Send only what changes').

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources