Skip to main content
Glama

Change the service area

update_service_area
Destructive

Changes which places the connected account's AI receptionist serves, and puts the change live for real callers straight away. In Australia the area is one list that can mix whole states, councils, suburbs and postcodes (a postcode adds every suburb in it); in Qatar it is a list of municipalities (type region). Name places as people write them, adding the state (and for a suburb, the postcode) when a name could mean more than one place; if a name still matches several, nothing changes and the error lists the matches to ask the user about. remove takes places off the list and runs before add, so one call can swap areas. coverAll: true serves the whole country instead of a list; adding areas to a whole-country setting narrows it to just those areas. The list cannot leave out part of a listed area: to stop serving one suburb of a listed state or council, remove that state or council and add the parts still served. outOfAreaPolicy sets what happens to callers outside the area: reject (told so, not booked) or flag_for_review (details taken for the team to check). Call get_ai_setup first: its serviceArea setting lists every place served now. Before calling, tell the user exactly which places will be added or removed (or that the whole country will be served) and that it goes live immediately, and get their explicit yes; then pass confirm: true. Saved as a new version that restore_ai_setup_version can undo.

Input Schema

NameRequiredDescriptionDefault
addNoPlaces to start serving
removeNoPlaces on the list to stop serving
confirmYestrue only after the user has explicitly approved this specific change in the conversation
coverAllNotrue to serve the whole country instead of a list; not combined with add or remove
outOfAreaPolicyNoWhat happens to callers outside the area

Output Schema

NameRequiredDescriptionDefault
changesYes
messageYes
successYes
versionNo
liveWarningYes
_environmentYesThe Nexwin country and environment that supplied the result
restoredFromNo
previousVersionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and non-idempotent, but the description adds the traits that matter most: the change goes live for real callers immediately, it can still be undone via restore_ai_setup_version, and an ambiguous place name causes a no-op with an error listing the matches. It also documents the structural constraint that a listed area cannot be partially excluded.

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?

The core action and its immediate-live consequence are front-loaded in the first sentence, and virtually every subsequent sentence carries rules an agent cannot infer elsewhere. It is however a very dense block of run-on clauses, and the audience/permission framing near the end could be tightened without losing meaning.

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?

With an output schema present, the description need not explain return values, and it still covers prerequisites, confirmation requirements, ordering, geography-specific rules, coverage semantics, and reversibility. Nothing needed to invoke this correctly in either region is missing.

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 100%, so the bar is higher than baseline, yet the description still adds real semantics: a postcode adds every suburb in it, region is the Qatar municipality type, coverAll narrows rather than widens when areas are also added, and outOfAreaPolicy's two enum values are expanded into actual caller outcomes (reject = told, not booked; flag_for_review = details taken). Some of this duplicates the schema description text for confirm and coverAll, keeping it short of a 5.

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?

"Changes which places the connected account's AI receptionist serves" names a specific verb and resource, and the description distinguishes this mutation from the sibling read tools get_ai_setup and update_ai_setup. An agent can tell immediately this is the service-area setter rather than the general AI-setup updater.

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 states the prerequisite ("Call get_ai_setup first"), the required conversation flow (tell the user the exact places, get an explicit yes, then pass confirm: true), and the ordering rule that remove runs before add so one call can swap areas. Alternatives and when-not conditions (coverAll is "not combined with add or remove") are explicit.

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