Skip to main content
Glama

Change communication settings

update_communication_settings
Idempotent

Propose supported visitor chat/widget settings through a validated partial patch after reading get_communication_settings. Include channel="widget". Omitted settings stay unchanged; review the exact change before applying. Do not say saved/applied while approval is pending or a call failed. This never connects credentials, buys numbers, pays fees, submits registrations or changes provider routing; use the exact secure setup page for those steps.

Input Schema

NameRequiredDescriptionDefault
changeYes
site_idYes
user_goalNoOptional: the user's goal behind this call, in one short sentence of plain words (e.g. "add a page so customers can book tables"). No names, emails or other personal details.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / user_goal
      Added value: +{
      +  "description": "Optional: the user's goal behind this call, in one short sentence of plain words (e.g. \"add a page so customers can book tables\"). No names, emails or other personal details.",
      +  "type": "string"
      +}
  2. Added

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the annotations, the description discloses partial-patch semantics ('Omitted settings stay unchanged'), an approval-pending state, and a caution not to claim the change was saved/applied prematurely. It also rules out several external side effects, which is valuable for a mutation tool even with annotations present.

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?

The description is front-loaded with the core action and prerequisite, then adds constraints and exclusions in a tight set of sentences. Every sentence contributes operationally useful information.

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

Completeness3/5

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

It covers the workflow, partial-patch behavior, approval caveat, and out-of-scope actions, which is important for this complex nested tool. However, with no output schema and many nested parameters undocumented, the definition is still incomplete about what the validated patch will accept and what the proposal response contains.

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 description coverage is only 33%, so the description needs to carry more parameter meaning than it does. It explains that channel is required and that omitted fields stay unchanged, but it does not clarify the many nested widget, voice, prechat-form, or smart_answers settings.

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?

The description states a specific action and scope: proposing supported visitor chat/widget settings via a validated partial patch. It clearly distinguishes itself from get_communication_settings and from credential/payment/registration setup tasks, though the word 'propose' slightly blurs whether it applies changes directly or only stages them.

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?

It explicitly says to read get_communication_settings first, to include channel="widget", and to review the exact change before applying. It also names when not to use this tool: credential connection, number purchase, fees, registrations, and provider routing belong on the secure setup page.

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