Skip to main content
Glama

Product Admin by Nova (CIVAI)

update_product

Update product fields (partial patch — only send fields to change).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoLowercase product id (letters, digits, hyphen, underscore).
nameNo
site_urlNo
mobile_pushNo
pipeline_typeNo
payment_configNo
content_enabledNoEnable/disable the content pipeline for this product.
default_countryNo
logistics_configNo
publish_destinationsNoWhere generated content publishes to. Each entry is one of {type: 'webhook', webhook_url, webhook_secret?}, {type: 'x_post', twitter_account_id}, or {type: 'ar_calendar', audience_resolver_project_id, audience_resolver_calendar_id} (requires audience_resolver_publisher_token to be connected first).
audience_resolver_publisher_tokenNoPublisher JWT minted from the Audience Resolver dashboard, connecting this product to an AR account so content can be pushed to its calendars. Set via connect_audience_resolver, not directly.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / audience_resolver_publisher_token
      Added value: +{
      +  "description": "Publisher JWT minted from the Audience Resolver dashboard, connecting this product to an AR account so content can be pushed to its calendars. Set via connect_audience_resolver, not directly.",
      +  "type": "string"
      +}
    • changedInput schema / properties / publish_destinations / description
      Previous value: -"Where generated content publishes to. Each entry is either {type: 'webhook', webhook_url, webhook_secret?} or {type: 'x_post', twitter_account_id}."New value: +"Where generated content publishes to. Each entry is one of {type: 'webhook', webhook_url, webhook_secret?}, {type: 'x_post', twitter_account_id}, or {type: 'ar_calendar', audience_resolver_project_id, audience_resolver_calendar_id} (requires audience_resolver_publisher_token to be connected first)."
    • addedInput schema / properties / publish_destinations / items / properties / audience_resolver_calendar_id
      Added value: +{
      +  "type": "string"
      +}
    • addedInput schema / properties / publish_destinations / items / properties / audience_resolver_project_id
      Added value: +{
      +  "type": "string"
      +}
    • changedInput schema / properties / publish_destinations / items / properties / type / enum
      Previous value: -[
      -  "webhook",
      -  "x_post"
      -]New value: +[
      +  "webhook",
      +  "x_post",
      +  "ar_calendar"
      +]
  2. Changed2 schema fields changed
    • addedInput schema / properties / content_enabled
      Added value: +{
      +  "description": "Enable/disable the content pipeline for this product.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / publish_destinations
      Added value: +{
      +  "description": "Where generated content publishes to. Each entry is either {type: 'webhook', webhook_url, webhook_secret?} or {type: 'x_post', twitter_account_id}.",
      +  "items": {
      +    "properties": {
      +      "twitter_account_id": {
      +        "type": "string"
      +      },
      +      "type": {
      +        "enum": [
      +          "webhook",
      +          "x_post"
      +        ],
      +        "type": "string"
      +      },
      +      "webhook_secret": {
      +        "type": "string"
      +      },
      +      "webhook_url": {
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "type"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  3. First observed

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the full disclosure burden. It usefully signals patch semantics (unmentioned fields are left untouched), but says nothing about auth requirements, whether changes trigger downstream effects, or how nested config objects are merged.

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?

A single tight sentence with the essential patch semantics front-loaded and zero filler; every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter mutation tool with nested objects, no annotations, no output schema, and low schema coverage, the description is far too thin. It omits auth/permission needs, merge behavior for nested configs, and any response expectations.

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

Parameters2/5

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

Schema coverage is only 36%, so the description is expected to compensate for undocumented parameters, yet it adds no per-field meaning at all beyond 'fields'. Params like site_url, mobile_push, pipeline_type, payment_config, logistics_config, and default_country remain undocumented in both places.

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 clear verb+resource (update product fields) and the description's 'partial patch' qualifier pins down the operation type. It is distinguishable from create_product/get_product/delete_product by name, though it does not explicitly contrast with its siblings.

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?

The 'only send fields to change' guidance implies correct usage for a patch endpoint, but gives no explicit when-to-use/when-not or pointer to alternatives like set_payment_config or set_logistics_config, which are separate siblings covering some of the same fields.

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