Skip to main content
Glama

update_product

Idempotent

Change a site's name, whether people who aren't logged in may write, the simple form's words and colour, or its test domains (its dev and uat copies, owner only). Give only what should change.

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": {
      "product_id": "<product_id>"
    },
    "name": "update_product"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoA new name for the site.
introNoThe line under the heading, up to 300 characters.
buttonNoThe words on the send button, up to 60 characters.
colourNoThe button's colour as a # and six hex digits, like #1f6feb.
headingNoThe simple form's heading, up to 60 characters.
thank_youNoWhat the form says after a message is sent, up to 300 characters.
product_idYesThe site's id (a uuid), from list_products.
test_domainsNoThe site's test domains, such as its dev and uat copies: up to two, never one of its own domains. On them its live key opens test tickets, and logged-in users are signed with the test secret. This replaces the list; [] removes them. Owner only.
let_anyone_writeNoWhether people who aren't logged in to the site may send a message (they give their email). false means logged-in users only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • changedInput schema / properties / button / type
      Previous value: -[
      -  "string",
      -  "null"
      -]New value: +"string"
    • changedInput schema / properties / colour / type
      Previous value: -[
      -  "string",
      -  "null"
      -]New value: +"string"
    • changedInput schema / properties / heading / type
      Previous value: -[
      -  "string",
      -  "null"
      -]New value: +"string"
    • changedInput schema / properties / intro / type
      Previous value: -[
      -  "string",
      -  "null"
      -]New value: +"string"
    • changedInput schema / properties / let_anyone_write / type
      Previous value: -[
      -  "boolean",
      -  "null"
      -]New value: +"boolean"
    • changedInput schema / properties / name / type
      Previous value: -[
      -  "string",
      -  "null"
      -]New value: +"string"
    • changedInput schema / properties / test_domains / type
      Previous value: -[
      -  "array",
      -  "null"
      -]New value: +"array"
    • changedInput schema / properties / thank_you / type
      Previous value: -[
      -  "string",
      -  "null"
      -]New value: +"string"
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the description needn't restate safety. It earns credit for adding non-obvious behaviour: partial-update semantics, the fact that test_domains replaces the whole list and '[] removes them', and that the owner-only restriction applies. What is not disclosed is the effect on unrelated site settings or what the call returns after a successful change.

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?

Two sentences: the first enumerates the mutable surface, the second delivers the partial-update rule. No filler, no restated title, and the most load-bearing constraint arrives immediately after the field list.

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?

With nine parameters, full schema coverage, a required product_id and no output schema, the description covers the mutation contract and the one field with unusual semantics. It leaves a small gap in not indicating what is returned or confirming that all other site settings are unaffected, but nothing needed to call the tool correctly is missing.

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 description coverage is 100%, so the schema already explains every one of the nine parameters, including the rich test_domains semantics; the baseline is 3. The description adds only the cross-parameter PATCH convention ('give only what should change') and reinforces the owner-only constraint, which is genuine but marginal value over the structured data.

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 concrete verb ('Change') plus the resource ('a site') and enumerates exactly which attributes are mutable: name, public write access, simple-form copy and colour, test domains. That is far more than a restated name. It stops short of 5 because overlapping siblings (update_button, save_form, use_simple_form) are never named, so an agent must infer whether form copy belongs here or there.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Give only what should change' is a genuinely useful instruction that tells the agent this is a partial update and unspecified fields are untouched. However there is no statement of when to prefer this over siblings like update_button or save_form, and no prerequisite or exclusion beyond the inline 'owner only' on test_domains. Usage context is implied rather than stated.

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