Handled Locator

by com.handledlocal

Overview Discussions Admin

Server Details

Manage a store locator by chatting: locations, tags, booking buttons, map styling, embed code.

Ownership verified

Status: Healthy
Uptime: 98.6% over 21 days
Last Tested: 2026-09-30 23:18
Transport: Streamable HTTP · MCP 2025-06-18
URL

TDQS

A4/5.0

Scored 2026-09-28 01:50 across 18 tools

Disambiguation4/5

Most tools target a distinct resource+action, and the descriptions proactively separate easily-confused pairs (e.g. tag_locations vs set_custom_field, 'who OWNS vs who can reach' for territory). However, a few boundaries still blur: tag_locations can also style tags (overlapping set_tag_style), spotlight and territory are both visitor-facing rule engines, and find_nearest_locations can answer data queries that list_locations also covers.

Naming Consistency4/5

The set is overwhelmingly snake_case verb_noun (create_location, list_tags, apply_configuration, rollback_configuration), which is easy to predict. The two exceptions, spotlight and territory, are bare nouns that dispatch behavior through an action parameter, breaking the otherwise consistent pattern.

Tool Count4/5

18 tools is slightly heavy but each roughly earns its place across location CRUD, configuration lifecycle, tagging, custom fields, routing/spotlight rules, and embed code. There is no obvious redundancy, though the array of config tools (propose/apply/describe/rollback/versions) contributes to the bulk.

Completeness4/5

Location lifecycle is fully covered (create/get/list/update/delete) and configuration has a complete propose-apply-rollback-history loop. Minor gaps exist: no dedicated tag deletion, no location duplication/merge, and territory polygons must be drawn in the dashboard rather than via the API.

Available Tools

18 tools

apply_configurationApply a configuration proposalA

Destructive

Inspect

Make a prepared proposal live on the customer's website. Only call this after showing the person the differences from propose_configuration and getting their agreement. Refused if the locator changed since the proposal was prepared.

ParametersJSON Schema

Name	Required	Description	Default
`proposalId`	Yes	The id returned by propose_configuration.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, so the agent knows this is a mutating operation. The description adds valuable behavioral context beyond that: it states the tool will be 'Refused if the locator changed since the proposal was prepared,' which is a runtime failure condition the agent needs to know. It also implies a stateful workflow (proposal must exist and be agreed upon). It doesn't detail the exact side effects of making the proposal live, but the destructive annotation plus the refusal condition provide solid transparency.

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?

Three sentences, each earning its place: the first states the action, the second gives the critical usage precondition, the third warns about a failure condition. It is front-loaded with the core purpose and contains zero filler. This is an exemplary concise definition.

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?

For a single-parameter tool with a clear destructive annotation and a well-described workflow, the description is nearly complete. It covers the purpose, the prerequisite, and a key failure condition. The only minor gap is that it doesn't describe what the response looks like or what 'making live' concretely changes on the website, but with no output schema and a simple parameter set, the description provides enough for an agent to call it correctly.

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% – the single parameter proposalId is fully described in the schema as 'The id returned by propose_configuration.' The description adds the context that this id comes from a prepared proposal and that applying it is the action, but it doesn't add new parameter-level meaning beyond the schema. Baseline 3 is appropriate since the schema carries the parameter documentation.

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?

The description clearly states the tool's function: 'Make a prepared proposal live on the customer's website.' It uses a specific verb ('apply') and resource ('configuration proposal'), and distinguishes it from the sibling propose_configuration by explicitly naming that tool. The purpose is unambiguous and an agent can easily tell this apart from related tools like rollback_configuration or describe_configuration.

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?

The description provides explicit when-to-use guidance: 'Only call this after showing the person the differences from propose_configuration and getting their agreement.' It also names the sibling tool propose_configuration as the prerequisite step, and warns about a condition that blocks usage ('Refused if the locator changed since the proposal was prepared'). This is strong, actionable guidance for an agent deciding when to invoke the tool.

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

create_locationAdd a locationAInspect

Add one location, or many in a single call. A plain address is geocoded automatically, so lat and lng are only needed to override the result. Pass locations with an array to add a batch: adding ten showrooms is one call, not ten, and the reply says exactly which ones landed. Counts against the plan's location allowance.

ParametersJSON Schema

Name	Required	Description
`lat`	No	Latitude. Supplying lat and lng skips geocoding.
`lng`	No	Longitude.
`city`	No
`name`	No	Business or store name.
`email`	No
`hours`	No	Opening hours keyed by ISO weekday, 1 = Monday. Each value is ONE {open, close} in 24h HH:MM, or null for closed — not a list, and a list is rejected. Example: {"1": {"open": "09:00", "close": "17:00"}, "7": null}. REPLACES the whole week: any day left out is cleared. To change one day without restating the rest, use hoursPatch.
`phone`	No
`state`	No
`address`	No	Full address as a person would write it. Geocoded automatically unless lat and lng are supplied.
`website`	No
`imageUrl`	No
`priority`	No	Higher sorts first when there is no visitor position.
`timezone`	No	IANA timezone, for example America/Chicago.
`locations`	No	Several locations to add in one call (at most 50). Use this instead of the top-level fields when adding more than one; each entry takes the same fields.
`hoursPatch`	No	Change only the days named, leaving every other day exactly as it is. Same shape as hours but partial: {"7": {"open": "10:00", "close": "16:00"}} changes Sunday alone, and {"7": null} closes it. Use this to edit hours; it cannot silently revert a day you did not mention. Ignored if hours is also sent.
`postalCode`	No
`visibility`	No	hidden keeps the location in the account but off the public locator.
`countryCode`	No	Two-letter ISO country code.
`description`	No
`markerColor`	No	Hex colour for this location's map marker.
`addressLine1`	No	Street line, when the address is structured.
`customFields`	No	Extra fields, keyed by the label shown to visitors. The value is either a plain string, or an object {value, color, icon, style} where `value` is the URL or text. There is no `label` or `url` key: the label is the key, and the URL goes in `value`. Example: {"Book a table": {"value": "https://example.com/book", "color": "#C2540E"}}. Never use this for tags or categories; use the categories field instead.
`locationType`	No	point is a physical address, service_area covers a radius, online is a stockist with no address.
`onlineRegions`	No	For an online location: two-letter country codes it ships to or serves, e.g. ["us", "ca"]. Empty means every visitor sees it.
`serviceRadiusKm`	No	Radius in km, for a service_area location.
`serviceAreaCircleVisible`	No	For a service_area location: whether to draw its coverage circle. Null (the default) follows the locator's serviceAreaCircleVisible setting. False draws the pin without the circle.

TDQS

A3.8/5.0

Behavior4/5

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

The description goes beyond the minimal annotations by disclosing that geocoding is automatic, that the reply reports exactly which batch items landed, and that the operation counts against the plan's location allowance. These are meaningful behavioral details not present in the annotations.

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 description is short, front-loaded with the core action, and each sentence contributes a useful operational fact. The batch point is slightly repeated, but the overall structure is efficient and scannable.

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?

For a complex 26-parameter create tool with no output schema and sparse annotations, the description provides key context such as batching, geocoding, response confirmation, and quota impact. It does not address duplicate behavior, authentication/permissions, or detailed error/return shapes, but the schema covers most parameter-level semantics.

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?

The description reinforces the geocoding override behavior and the batch semantics of locations, but the input schema already documents these details in its parameter-level descriptions. With 69% schema description coverage, the description adds some value without fully compensating for the less-covered parameters.

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?

The description opens with a precise verb and resource: 'Add one location, or many in a single call.' This clearly distinguishes create_location from the sibling update_location and delete_location tools and makes the batch capability explicit.

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?

It gives useful in-tool guidance, such as using the locations array for batching and only supplying lat/lng to override geocoding. However, it does not explicitly say when to prefer create_location over update_location/delete_location or state any when-not-to-use conditions, so usage remains mostly implied.

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

delete_locationDelete a location, or many at onceA

DestructiveIdempotent

Inspect

Remove a location from the locator. This is a soft delete: the row is retained so analytics history stays intact, and it can be restored from the dashboard. Pass ids instead of id to delete up to 200 in one call.

ParametersJSON Schema

Name	Required	Description	Default
`id`	No	Location id.
`ids`	No	Several location ids, to apply the same change to all of them in one call (at most 200). Use either id or ids.

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already mark destructive and idempotent behavior, but the description adds material context beyond them: soft delete, retained row, intact analytics history, and restorability from the dashboard. This tells the agent about side effects and reversibility. No contradiction with 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?

Three concise sentences, each carrying distinct information: the core action, the soft-delete side effect, and the batch path. The most important information is front-loaded, with no filler or redundant examples.

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?

For a 2-parameter delete tool with rich annotations and full schema coverage, the description supplies the key extra context an agent needs: soft-delete semantics and batch limits. The absence of return-value details is acceptable given there is no output schema and the behavior is sufficiently specified.

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 coverage is 100%, so the schema already documents both `id` and `ids` fully. The description mostly restates the batch behavior and 200-item limit already present in the schema, adding no substantive new parameter semantics.

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?

Description uses 'Remove a location from the locator' with a clear verb and resource, and the title/batch mention makes the scope obvious. Even among create/update/list siblings, delete is unambiguous. The soft-delete clarification also distinguishes it from a hard delete.

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

Usage Guidelines4/5

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

The description clearly states what the tool does and explicitly covers the batch path with 'Pass ids instead of id', giving clear context for when to use it. It does not name alternatives or provide when-not guidance, but the tool's single purpose makes the intended use obvious.

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

describe_configurationDescribe the locator configurationA

Read-onlyIdempotent

Inspect

The current value of everything on the locator, with the schema beside it: behaviour settings, brand tokens, result-card layouts and visitor-facing wording. Use it to read what is set now. To write a change you do not need it: propose_configuration's own input schema lists every key and allowed value. Pass section to get one part instead of all 30KB.

ParametersJSON Schema

Name	Required	Description	Default
`section`	No	Which part to return. all (default), settings, brand, tokens (what the brand COMPUTES to: the derived muted text, borders, alternate surface and shadow, which are stored nowhere), layouts, labels, or one settings group: search (Search & location), results (Results & sorting), filters (Filter behaviour), hours (Hours & open status), map (Map behaviour), markers (Map markers), layout (Layout & fields), directions (Directions & links), data (Data formatting).

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: the tokens are computed values that are stored nowhere, and the full output is roughly 30KB — useful expectations for an agent deciding whether to page through output. No contradiction with 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?

Three sentences with zero waste: the first states the output, the second gives use case and routing, the third explains the parameter. The most decision-relevant information (what it returns and when to use it) is front-loaded, and the sibling routing is compact.

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?

For a read-only tool with one optional parameter, no output schema, and annotations covering the safety profile, the description is complete: it states the return content, the size implication, the section scoping, and the write-tool alternative. Nothing an agent needs to call it 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% and the enum values each carry detailed explanations of what they return, so the schema does the heavy lifting. The description adds modest value beyond that: clarifying the default (all) and framing section as a way to avoid the full 30KB payload, which is useful but does not change the baseline for fully documented parameters.

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?

The description states a specific verb (read/describe) and resource (the locator configuration), and enumerates exactly what is returned: behaviour settings, brand tokens, result-card layouts, and visitor-facing wording, each with the schema beside it. It also distinguishes itself from the write sibling propose_configuration, so an agent can differentiate the tools without opening schemas.

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?

The description explicitly says when to use this tool ('Use it to read what is set now') and when not to ('To write a change you do not need it'), naming propose_configuration as the alternative and explaining why (its input schema lists every key and allowed value). It also gives guidance for the optional section parameter as a way to scope the read.

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

find_nearest_locationsFind the nearest locationsA

Read-onlyIdempotent

Inspect

Rank locations by distance from a point, the way the widget ranks them for a visitor. Also answers questions about the data when given tag or q without a point.

ParametersJSON Schema

Name	Required	Description
`q`	No	Match against name, address and description.
`lat`	No	Latitude of the point to measure from.
`lng`	No	Longitude of the point to measure from.
`tag`	No	Only locations carrying this category name.
`limit`	No	Default 25, maximum 200.
`units`	No	Default km.
`radius`	No	Only return locations within this distance.
`includeHidden`	No	Include locations hidden from the public locator.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, lowering the burden on the description. The description adds useful context beyond the schema: ranking is widget-consistent, and the tool behaves differently without a point. It does not describe output format, but that is a minor gap given the read-only 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?

Two sentences with no filler. The primary behavior is front-loaded, and the second sentence efficiently introduces the alternative mode. Every word contributes to understanding.

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?

For a read-only tool with a fully documented schema and zero required parameters, the description provides enough to understand the two invocation patterns. The absence of an output schema is not fully compensated, but 'rank locations' implies the result shape, leaving only minor ambiguity about edge-case calls with no parameters.

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 meaning beyond individual parameter docs by revealing the relationship between lat/lng and q/tag: a point drives distance ranking, while q/tag can substitute for it to answer data questions.

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?

The description uses a specific verb ('rank') with a clear resource ('locations') and criterion ('by distance from a point'). It also adds a second mode with 'tag or q without a point', which distinguishes this from a plain listing tool like list_locations.

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

Usage Guidelines4/5

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

It clearly states when the primary ranking behavior applies (when a point is provided) and when the alternative data-question mode applies (tag/q without a point). It does not explicitly compare against sibling tools or state exclusions, so it falls short of a 5.

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

get_embed_codeGet the embed codeA

Read-onlyIdempotent

Inspect

The HTML snippet that puts this locator on a website, plus the public site id it carries. Paste it where the map should appear.

ParametersJSON Schema

Name	Required	Description	Default
`near`	No	A place to search near when the page opens, e.g. 'Austin, TX'.
`tags`	No	Lock this embed to locations carrying any of these tags (names or slugs), for a page about one product, service or region.

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds useful context by disclosing the exact return payload: an HTML snippet carrying a public site ID. This is sufficient for a simple getter.

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, front-loaded with the main deliverable and ending with actionable placement guidance. There is no filler or redundant restatement.

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?

For a simple read-only tool with no required parameters and no output schema, the description explains enough about the return value and how to use it. It only lacks minor cross-tool routing context, which is already captured under usage guidelines.

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?

The input schema describes both parameters fully with 100% coverage. The description does not add parameter-level meaning, but the baseline 3 applies because the schema already carries the burden.

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 clearly identifies the resource (embed code for this locator) and what it returns (an HTML snippet plus the public site ID), going beyond the title. However, it does not explicitly contrast with siblings or use a direct retrieval verb.

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

Usage Guidelines2/5

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

The last sentence implies a use case: paste the snippet where the map should appear on a website. But there is no explicit guidance about when to choose this tool over siblings or when to use the optional near/tags parameters.

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

get_locationGet a locationA

Read-onlyIdempotent

Inspect

Full details for one location, including hours and custom fields.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Location id.

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds minimal behavioral context beyond that — it mentions the output includes hours and custom fields but does not disclose any side effects, auth needs, or rate limits. It neither enriches nor contradicts the 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?

The description is a single, front-loaded sentence: 'Full details for one location, including hours and custom fields.' It conveys the core purpose immediately with zero filler or redundancy.

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?

This is a simple get-by-id tool with one parameter, and annotations cover the safety profile. The description mentions key output fields (hours, custom fields) but does not fully enumerate all return details; however, 'full details' implies completeness. Adequate for the simplicity, though a touch more specificity about output structure would be ideal.

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?

The schema description for the 'id' parameter is clear ('Location id.'), and coverage is 100%. The tool description adds no extra semantic detail about the parameter, so the baseline score of 3 applies.

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?

The description clearly states the tool retrieves full details for one location, including hours and custom fields. This distinguishes it from list_locations (which presumably returns summaries) and find_nearest_locations, and the resource and scope are unambiguous.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like list_locations or find_nearest_locations. The description lacks any context about prerequisites or scenarios, leaving the agent to infer usage from the name alone.

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

list_configuration_versionsList configuration historyA

Read-onlyIdempotent

Inspect

The locator's configuration history, newest first, with what caused each version. Use it to find a version number to roll back to.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Default 20, maximum 100.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, and non-destructive behavior, so the description adds useful behavioral context beyond them: the result order ('newest first') and the inclusion of causal information. This is meaningful, though it does not detail the full return payload shape.

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 two short sentences with no redundancy. The core object and ordering are front-loaded, followed by the practical use case, so every sentence earns its place.

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?

For a simple read-only listing tool with one optional parameter, the description covers what is returned, the ordering, and the typical use case. There is no output schema, so slightly more detail about each version object could help, but the description is sufficient for correct invocation.

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% because the only parameter, limit, is documented with its default and maximum. The description adds no parameter-specific meaning, which is acceptable given the schema already handles it.

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?

The description states a specific verb ('list') and resource ('configuration history'), and immediately specifies ordering and content ('newest first, with what caused each version'). The rollback use case helps distinguish it from sibling configuration tools like describe_configuration and rollback_configuration.

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

Usage Guidelines4/5

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

It explicitly tells the agent when to use the tool: to find a version number to roll back to. It does not name alternatives or state when not to use it, but the intended workflow context is clear enough for tool selection.

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

list_locationsList locationsA

Read-onlyIdempotent

Inspect

List the locations on this locator, newest first. Use search to find one by name or address before editing it.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Default 50, maximum 200.
`offset`	No	For paging through more than one page of results.
`search`	No	Match against name and address.
`visibility`	No

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds useful context beyond annotations: the result ordering ('newest first') and the locator-scoped nature of the list.

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 concise sentences, with the core purpose and ordering front-loaded, followed by a helpful usage hint. No wasted words.

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?

The description is sufficient for a simple read-only list operation: it states scope, ordering, and a search usage hint. It doesn't explain return shape, but there is no output schema and the operation is low-complexity, so this is an acceptable gap.

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 coverage is 75%, so most parameters already have descriptions. The description adds modest emphasis on using 'search' for finding by name or address, but doesn't meaningfully expand on limit, offset, or visibility semantics beyond what the schema 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?

The description states a specific verb ('List') and resource ('locations on this locator') and adds ordering ('newest first'). This clearly distinguishes it from sibling tools like get_location (single resource) and list_tags (different resource type).

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

Usage Guidelines4/5

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

The description gives clear context for using the search parameter to find a specific location before editing, which is actionable guidance. It doesn't explicitly name alternative tools or exclusion conditions, but the intended use case is reasonably clear.

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

list_tagsList tagsA

Read-onlyIdempotent

Inspect

The tags (categories) on this locator, with how many locations carry each one. Tags are what visitors filter by on the map.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral detail beyond annotations by stating the output includes how many locations carry each tag, which is not visible from the schema.

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 a single, tightly written sentence that conveys the subject, scope, and output detail without wasted words. It is front-loaded with the core purpose and adds context only where it helps.

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?

For a zero-parameter, read-only list tool with no output schema, the description is complete: it states what is listed, the per-tag counts, and the role of tags in the map filtering context. No critical information is missing for an agent to invoke it 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?

The input schema has no parameters, so the description has no need to explain parameter meaning. The baseline of 4 is appropriate because no parameter documentation burden exists.

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?

The description clearly states the tool lists tags/categories on the locator and includes the count of locations carrying each one. It also distinguishes the resource from sibling tools by explaining tags are what visitors filter by on the map, so it cannot be confused with tag_locations or list_locations.

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

Usage Guidelines4/5

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

The description provides clear context: this tool is for retrieving the tags available for filtering and their usage counts. It doesn't explicitly name alternatives or state when-not-to-use, but the read-only, informational purpose is evident from the description and annotations.

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

propose_configurationPropose a configuration changeAInspect

Prepare a change to how the locator looks or behaves, WITHOUT applying it. Returns the exact list of differences. Show that list to the person and get their agreement before calling apply_configuration. This tool's input schema lists every key and every allowed value, so write the patch straight from it; a rejected patch names every wrong key and value at once. Only send the keys you want to change.

ParametersJSON Schema

Name	Required	Description
`labels`	No	Visitor-facing wording overrides. {place} and {count} are substituted where the default uses them.
`layouts`	No	Which fields each surface shows, and in what order.
`request`	Yes	What the person asked for, in their words. Stored with the proposal as its record.
`summary`	Yes	One sentence describing what this change does.
`branding`	No	Brand changes. accentColor sits at this level; every other token goes inside settings.
`settings`	No	Behaviour settings to change. Only send the keys you want to change. Heights are two keys: mapHeight for the map and listMaxHeight for the result list.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare destructiveHint=false, and the description reinforces that with 'WITHOUT applying it'. It adds genuinely new behavior: the tool returns an exact diff, and a rejected patch reports every wrong key and value at once. It doesn't mention whether proposals expire or are stored beyond the request record, but that is a minor gap.

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?

Front-loads the non-applying, diff-returning nature, then the confirmation workflow, then the patch-writing rule. Every sentence carries a distinct instruction with no padding.

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?

For a very large nested schema with no output schema, the description covers what matters most: the return value (exact list of differences), validation feedback, and the human-approval gate before apply_configuration. Nothing an agent needs to call this 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 documents all six parameters and their nested keys. The description adds only the operational rule to send partial patches rather than the full object, which is useful but not syntax or format detail beyond the schema; baseline 3 is appropriate.

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 ('Prepare a change to how the locator looks or behaves') and immediately narrows scope with 'WITHOUT applying it'. An agent can distinguish this from apply_configuration without opening either schema.

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?

Explicit workflow: show the returned diff to the person and get agreement before calling apply_configuration, naming the sibling that does the apply. It also specifies the patch-writing rule ('only send the keys you want to change'), leaving nothing to inference.

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

rollback_configurationRoll back the configurationA

Destructive

Inspect

Restore a previous configuration version. This creates a new version rather than erasing history, so a rollback can itself be rolled back.

ParametersJSON Schema

Name	Required	Description	Default
`targetVersion`	Yes	Version number to restore, from list_configuration_versions.

TDQS

A3.8/5.0

Behavior4/5

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

The description goes beyond the destructiveHint annotation by explaining that rollback creates a new version instead of erasing history, making the operation reversible. This is valuable behavioral context that helps an agent understand side effects despite the destructive hint. No contradiction with annotations is 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 two sentences with no filler. It front-loads the core action and then adds the key behavioral nuance, making it easy to scan and understand.

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?

For a simple one-parameter tool with annotations, the description is largely complete: it explains the operation, the main side effect, and the reversibility. It does not describe return values or explicitly guide alternative tool selection, but these are minor gaps given the low complexity.

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 coverage is 100% and the only parameter, targetVersion, is already documented as 'Version number to restore, from list_configuration_versions.' The description adds no additional parameter-level detail, which is acceptable given the complete schema.

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 resource: 'Restore a previous configuration version.' It adds a useful distinction—rollback creates a new version rather than erasing history—so the tool's purpose is clear. However, it does not explicitly differentiate from sibling tools like apply_configuration.

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 intended use (restoring a previous configuration version) is implied by the description, but no explicit when-to-use or when-not-to-use guidance is provided. Alternatives such as apply_configuration or list_configuration_versions are not mentioned.

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

set_custom_fieldSet a custom field across locationsA

DestructiveIdempotent

Inspect

Put the same extra field on many locations at once: a booking button, a social link, or a labelled fact like "Parking: street only". A value that is a URL becomes a clickable button; anything else shows as plain text. NOT for tags or categories, which are a different thing entirely: use tag_locations for those. Set remove to true to take the field off instead.

ParametersJSON Schema

Name	Required	Description
`key`	Yes	The field's name, shown as its label. For example "Book a table".
`icon`	No	Optional glyph on the button.
`color`	No	Hex colour for the button, for example "#C2540E". Ignored for plain text.
`style`	No	Default filled. Outline uses the colour as border and text only.
`value`	No	The field's value. A URL makes it a button, anything else shows as a labelled fact.
`remove`	No	Take this field off the given locations instead of setting it.
`locationIds`	Yes	Location ids to change. At most 200.

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already signal a destructive, idempotent write operation, so the bar is lower. The description adds valuable behavioral detail beyond annotations: URL values become clickable buttons, non-URLs render as plain text, and remove toggles the operation from set to remove. This helps the agent anticipate side effects and rendering behavior.

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 compact and front-loaded: it states the core use case, gives examples, distinguishes from related tools, and covers the removal behavior in three sentences. Every sentence earns its place; there is no filler or repetition of schema content.

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?

Given 7 parameters, the schema covers all parameter details, and annotations cover safety traits, the description provides the essential operational context: batch behavior, value formatting, exclusions, and removal. It does not discuss return values, but there is no output schema and the tool is primarily an action, so this is not a significant gap.

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 description coverage is 100%, so the schema already documents all parameters. The description still adds meaning by explaining the value semantics (URL vs plain text) and the remove flag's effect, with illustrative examples like 'Book a table' and 'Parking: street only'. This exceeds the baseline without duplicating the schema.

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?

The description clearly states the action and resource: 'Put the same extra field on many locations at once' with concrete examples. It also explicitly differentiates from related functionality by saying 'NOT for tags or categories... use tag_locations for those', making the tool's scope unmistakable.

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?

The description gives explicit when-to-use guidance: for placing the same extra field across many locations, and explicitly excludes tags/categories with a pointer to the alternative tool. It also provides the conditional for removal: 'Set remove to true to take the field off instead.' This is direct, actionable routing guidance.

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

set_tag_styleStyle a tagA

Idempotent

Inspect

Set how an EXISTING tag looks: put it in a filter group, give it a colour, or a glyph. This is what turns flat tags into the grouped, labelled filter dropdowns with icons that the polished examples use — the one thing tag_locations cannot do. Use the exact tag name. If the tag does not exist yet, tag some locations with it first (tag_locations), then style it.

ParametersJSON Schema

Name	Required	Description
`tag`	Yes	The exact name of an existing tag, for example "Ghost pepper".
`icon`	No	Optional glyph shown on the tag's chip.
`color`	No	Hex colour for the tag's chip and, when markers follow tag colour, its map pins. For example "#E64893".
`group`	No	Filter group to put the tag in, for example "Flavour". Tags that share a group render as one labelled filter dropdown. An empty string removes the grouping.

TDQS

A4.3/5.0

Behavior4/5

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

With annotations already covering readOnlyHint=false, destructiveHint=false and idempotentHint=true, the description adds value beyond them: it states the hard precondition that the tag must already exist and warns that styling cannot create tags. This is meaningful behavioral context that the annotations do not convey.

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?

Three sentences with the core action front-loaded. Each sentence earns its place: the first states what it does, the second explains why it matters and differentiates it, the third gives the actionable precondition. Slightly wordy in the middle ('polished examples' phrasing) but nothing is redundant.

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?

For a 4-parameter mutation tool with no output schema, the description covers purpose, sibling differentiation, and the key precondition clearly. The schema handles parameter-level details like enum values and the empty-string group behavior, so what remains (result appearance, idempotence) is already covered by annotations or is minor.

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 documents each parameter with examples ('#E64893', 'Flavour', icon enum). The description adds only conceptual glue — mapping colour/glyph/group to the visual result — rather than new format or syntax details, so the baseline of 3 is appropriate.

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?

The description opens with a specific verb and resource: 'Set how an EXISTING tag looks', then enumerates the exact capabilities (filter group, colour, glyph). It explicitly differentiates from the sibling tool tag_locations ('the one thing tag_locations cannot do') and explains the intended outcome (grouped, labelled filter dropdowns with icons), so an agent can identify it unambiguously.

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?

The description gives explicit when-to-use guidance: style tags that already exist, and if a tag does not exist, tag locations with it first via tag_locations, then style it. It also names the exact alternative (tag_locations) and what it cannot do, leaving no ambiguity about tool selection or prerequisites.

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

spotlightSpotlight rulesA

Destructive

Inspect

Rules that change what a visitor sees depending on where and when they search: a banner for a region or a date range, featured locations, only certain locations, or hidden ones. One trigger and one action each, applied in list order after territories. Use action=list first to see what exists.

ParametersJSON Schema

Name	Required	Description
`id`	No	The rule, for update, delete, enable and disable.
`name`	No	What the rule is called, for create and update.
`action`	Yes	What to do. list is read-only.
`endsAt`	No	ISO timestamp. After it the rule is dormant. Optional.
`startsAt`	No	ISO timestamp. Before it the rule is dormant. Optional.
`actionKind`	No	What happens. banner = a message above the results; feature = move locations to the top or bottom; only = show just these, taken from the whole network; hide = remove these.
`triggerKind`	No	When the rule applies. always = every search; no_results = a search that found nothing; radius = within a distance of a point; polygon = inside a drawn area; postcodes = a postcode list, only matched by a typed search; filter = while a tag filter is on.
`actionFields`	No	The action's own fields: {message, linkUrl, linkLabel} for banner, {locationIds: [...], position: 'top'\|'bottom'} for feature, {locationIds: [...]} for only and hide.
`triggerFields`	No	The trigger's own fields: {lat, lng, radiusKm} for radius, {points: [[lat, lng], ...]} for polygon (at least three), {postcodes: [...]} allowing a trailing * for a prefix, {tagId} for filter. Empty for always and no_results.

TDQS

A4.4/5.0

Behavior4/5

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

The description discloses that rules are applied in list order after territories, which is a behavioral trait not visible in the schema. It also notes that 'list is read-only' in the schema, and the description's 'Use action=list first' reinforces safe exploration. The destructiveHint annotation is true, and the description doesn't contradict it; it could add more about the consequences of delete/disable, but the annotation covers the destructive nature.

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 compact and information-dense. It front-loads the core purpose, then gives a quick overview of rule types, and ends with a practical usage tip. Every sentence earns its place; no fluff or repetition of schema details.

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?

For a tool with 9 parameters, nested objects, and no output schema, the description plus the rich schema covers the essential semantics. The description explains the rule model (one trigger, one action, list order) and the schema covers all field details. The only minor gap is that the description doesn't explain what the output of 'list' looks like, but since there's no output schema, a brief note could help. Still, the combination is strong enough for an agent to use the tool correctly.

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 documents all parameters thoroughly. The description adds a high-level summary of what triggers and actions do, but doesn't add much beyond the schema's own field descriptions. The nested objects (actionFields, triggerFields) are well-documented in the schema, so the description doesn't need to compensate. Baseline 3 is appropriate.

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?

The description clearly states what the tool does: it manages rules that change what a visitor sees based on where and when they search. It enumerates the action types (banner, feature, only, hide) and trigger types, and distinguishes itself from sibling tools by focusing on visitor-facing spotlight rules rather than location CRUD or configuration management.

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?

The description explicitly advises using 'action=list first to see what exists', which is a clear usage guideline for a CRUD-like tool. It also explains the rule application order ('applied in list order after territories'), giving the agent context on how rules interact. While it doesn't name specific sibling alternatives, the tool's domain is distinct enough that the guidance is sufficient.

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

tag_locationsTag or untag locationsA

Idempotent

Inspect

THE tool for tagging. Use this for "tag these as X", "add the X tag", "categorise these as X", "mark these as X". Adds a tag to locations or takes it off them, and creates the tag if it does not exist yet. Tags are a real thing on the locator: they become the filter chips visitors use on the map. Pass group, color or icon to style the tag in the same call, which also avoids set_tag_style's requirement that the tag already exist. Never express a tag as a custom field. Use list_locations first to get the ids.

ParametersJSON Schema

Name	Required	Description
`tag`	Yes	Tag name, for example "Flagship". Created if new.
`icon`	No	Optional. Glyph for the tag's chip. Applied in this same call.
`color`	No	Optional. Hex colour for the tag's chip, for example "#E64893". Applied in this same call.
`group`	No	Optional. Filter group for the tag, for example "Flavour". Applied in this same call, so a tag can be created, applied and grouped at once.
`action`	No	Default add. Use remove to take the tag off these locations.
`locationIds`	Yes	Location ids to change. At most 200.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already mark the operation as idempotent and non-destructive. The description adds context that the tag becomes a filter chip, that styling can be applied in the same call, and that tags are created if missing. This is valuable beyond the annotations, though it does not enumerate every side effect (e.g., effect of removing a tag).

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 description is longer than necessary, but every sentence contributes: usage examples, core behavior, real-world effect, styling shortcut, alternative avoidance, and prerequisite. The key purpose is front-loaded, and the warnings earn their place.

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?

For a 6-parameter tool with no output schema, the description covers usage triggers, alternatives, prerequisites, and tag-creation side effects. It could mention the 200-location limit or error behaviors, but the schema already covers the limit and completeness is adequate for correct invocation.

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 parameters are already documented. The description reinforces that icon/color/group are applied in the same call and suggests using list_locations for ids, but adds no fundamentally new parameter-level semantics beyond the schema's existing descriptions.

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?

The description explicitly states the tool tags or untags locations, creates tags if absent, and positions itself as the canonical tool for tagging. It distinguishes from siblings by referencing set_tag_style and warning against expressing tags as custom fields, making the tool's purpose unambiguous.

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?

Provides concrete natural-language triggers ('tag these as X', 'add the X tag'), an explicit alternative (set_tag_style requiring a pre-existing tag), and a prerequisite (use list_locations first). This tells the agent exactly when to use this tool and what to avoid.

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

territoryDealer territoriesA

Destructive

Inspect

Who OWNS an address, as distinct from who can reach it. A service radius says how far a location travels; a territory decides which dealer an enquiry belongs to. Use action=list first. Postcode territories can be built here; polygons and regions are drawn on the map in the dashboard. Nothing reaches a visitor until action=publish.

ParametersJSON Schema

Name	Required	Description
`id`	No	The territory, for delete and add_postcodes.
`op`	No	For add_postcodes: whether this list grants coverage or carves it out. Default include.
`lat`	No	For explain.
`lng`	No	For explain.
`mode`	No	For set_mode. off ignores territories; preferred pins the owner and keeps the rest; exclusive returns only the owner; fallback shows the owner only when the ordinary search found nothing.
`name`	No	What the territory is called, for create.
`rank`	No	Lower wins when two territories cover the same address. Default 0.
`action`	Yes	What to do. list and explain are read-only.
`postcode`	No	For explain: the visitor's postcode, when known. Postcode rules cannot match without it.
`exclusive`	No	An exclusive territory returns only its owner for a covered address; otherwise the owner is pinned to the top and the rest still show.
`postcodes`	No	For add_postcodes. Full codes or prefixes written like SW1A*. Free text is accepted and split on commas, spaces and newlines.
`locationId`	No	The dealer that owns this territory, for create.

TDQS

A3.9/5.0

Behavior4/5

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

The description adds a key non-obvious behavior: 'Nothing reaches a visitor until action=publish', which is not derivable from the annotations or schema alone. The annotations already mark the tool destructive and not read-only, and the description does not contradict that; it adds workflow context about publishing.

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 description is compact and each sentence contributes: concept, distinction, first action, creation boundary, and publish requirement. It is somewhat conceptual in the opening, but not wasteful; the key operational instruction is included.

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?

For a 12-parameter tool with multiple action modes, the description complements the rich schema by explaining the core workflow and the publish gate. It does not explain every action, but the schema describes those in detail, and no output schema is expected. The description is sufficient for an agent to start correctly.

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 documents all parameters thoroughly. The description adds minimal parameter-level meaning beyond orienting the agent to actions like list and publish, so the baseline of 3 is appropriate.

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 clearly identifies the resource as dealer territories and distinguishes it from service radius: a territory decides which dealer an enquiry belongs to, while a service radius measures reach. It does not use a direct verb like 'manage' or 'configure', but the intent is evident and it differentiates from the sibling location tools.

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

Usage Guidelines4/5

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

It explicitly instructs the agent to 'Use action=list first', which is a concrete usage guideline. It also states where the tool is and is not applicable: postcode territories are built here, while polygons and regions are drawn on the dashboard map. This gives clear context without naming sibling alternatives explicitly.

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

update_locationUpdate a location, or many at onceA

DestructiveIdempotent

Inspect

Change one or more fields on an existing location. Only the fields you send are touched. Changing the address re-geocodes it. Pass ids instead of id to apply the same fields to many locations in one call, for example hiding a batch or setting priority across a region; address, coordinates and name stay one-at-a-time.

ParametersJSON Schema

Name	Required	Description
`id`	No	Location id.
`ids`	No	Several location ids, to apply the same change to all of them in one call (at most 200). Use either id or ids.
`lat`	No	Latitude. Supplying lat and lng skips geocoding.
`lng`	No	Longitude.
`city`	No
`name`	No	Business or store name.
`email`	No
`hours`	No	Opening hours keyed by ISO weekday, 1 = Monday. Each value is ONE {open, close} in 24h HH:MM, or null for closed — not a list, and a list is rejected. Example: {"1": {"open": "09:00", "close": "17:00"}, "7": null}. REPLACES the whole week: any day left out is cleared. To change one day without restating the rest, use hoursPatch.
`phone`	No
`state`	No
`address`	No	Full address as a person would write it. Geocoded automatically unless lat and lng are supplied.
`website`	No
`imageUrl`	No
`priority`	No	Higher sorts first when there is no visitor position.
`timezone`	No	IANA timezone, for example America/Chicago.
`hoursPatch`	No	Change only the days named, leaving every other day exactly as it is. Same shape as hours but partial: {"7": {"open": "10:00", "close": "16:00"}} changes Sunday alone, and {"7": null} closes it. Use this to edit hours; it cannot silently revert a day you did not mention. Ignored if hours is also sent.
`postalCode`	No
`visibility`	No	hidden keeps the location in the account but off the public locator.
`countryCode`	No	Two-letter ISO country code.
`description`	No
`markerColor`	No	Hex colour for this location's map marker.
`addressLine1`	No	Street line, when the address is structured.
`customFields`	No	Extra fields, keyed by the label shown to visitors. The value is either a plain string, or an object {value, color, icon, style} where `value` is the URL or text. There is no `label` or `url` key: the label is the key, and the URL goes in `value`. Example: {"Book a table": {"value": "https://example.com/book", "color": "#C2540E"}}. Never use this for tags or categories; use the categories field instead.
`locationType`	No	point is a physical address, service_area covers a radius, online is a stockist with no address.
`onlineRegions`	No	For an online location: two-letter country codes it ships to or serves, e.g. ["us", "ca"]. Empty means every visitor sees it.
`serviceRadiusKm`	No	Radius in km, for a service_area location.
`serviceAreaCircleVisible`	No	For a service_area location: whether to draw its coverage circle. Null (the default) follows the locator's serviceAreaCircleVisible setting. False draws the pin without the circle.

TDQS

A4.4/5.0

Behavior4/5

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

The description discloses meaningful behavioral details beyond the annotations: only sent fields are touched, changing the address triggers re-geocoding, and batch updates apply the same fields to many locations. It does not expand on the destructive implications hinted by destructiveHint=true, but it does not contradict that annotation either.

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 compact: three sentences, no fluff, with the core partial-update behavior first and batching details second. Every sentence adds information an agent needs before calling the tool.

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?

For a 27-parameter mutating tool with no output schema, the description plus rich schema is largely sufficient. It covers partial updates, re-geocoding, and batch constraints; the only omissions are explicit return behavior and consequences of destructiveHint=true, which are not strictly needed for selecting and invoking the tool.

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?

With 70% schema coverage, the schema already documents many parameters, and the description adds important cross-parameter semantics: `ids` vs `id`, one-at-a-time address/coordinates/name, and automatically skipping geocoding when lat/lng are supplied. This is useful beyond the schema, though the description intentionally leaves detailed per-field behavior to the schema.

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?

The first sentence states a specific action and target: 'Change one or more fields on an existing location.' This clearly distinguishes the tool from siblings like create_location, delete_location, and get_location. The title also communicates batch capability immediately.

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

Usage Guidelines4/5

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

The description explains when to use `ids` instead of `id`, and notes that address, coordinates, and name stay one-at-a-time. It does not explicitly contrast with create/delete/other siblings, but the existing-location scope and clear batching guidance provide strong usage context.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateSep 28, 2026

Changedpropose_configuration2 fields changed

addedInput schema / properties / labels / properties / outsideTerritory

Added value: +{
+  "description": "results. Default: \"No location covers {place} yet. Showing the nearest instead.\".",
+  "type": "string"
+}

addedInput schema / properties / settings / properties / territoryAreasOnMap

Added value: +{
+  "description": "Show territories on the map. Draw each location's published territory, such as its ZIP codes, instead of a circle. Only applies when locatorLayout is not listOnly or gridOnly.",
+  "type": "boolean"
+}

1 tool updateSep 27, 2026

Changedpropose_configuration6 fields changed

addedInput schema / properties / labels / properties / resultsCount

Added value: +{
+  "description": "results. Default: \"{count} locations\".",
+  "type": "string"
+}

addedInput schema / properties / labels / properties / resultsCountNear

Added value: +{
+  "description": "results. Default: \"{count} locations near {place}\".",
+  "type": "string"
+}

addedInput schema / properties / labels / properties / sortBy

Added value: +{
+  "description": "results. Default: \"Sort by\".",
+  "type": "string"
+}

addedInput schema / properties / labels / properties / sortName

Added value: +{
+  "description": "results. Default: \"Name\".",
+  "type": "string"
+}

addedInput schema / properties / labels / properties / sortNearest

Added value: +{
+  "description": "results. Default: \"Nearest\".",
+  "type": "string"
+}

addedInput schema / properties / settings / properties / resultsHeader

Added value: +{
+  "description": "Results line. A line above the results saying how many there are, such as 12 locations near Chicago. Only applies when locatorLayout is not mapOnly. hidden = Hidden; count = Count; countAndSort = Count and a sort control.",
+  "enum": [
+    "hidden",
+    "count",
+    "countAndSort"
+  ],
+  "type": "string"
+}

1 tool updateSep 27, 2026
- Changedpropose_configuration1 field changed
  - changedInput schema / properties / labels / properties / opensAt / description
```
Previous value: -"hours. Default: \"Opens {time}\"."New value: +"hours. Default: \"Opens at {time}\"."
```

1 tool updateSep 20, 2026

Changeddescribe_configuration2 fields changed

changedInput schema / properties / section / description

Previous value: -"Which part to return. all (default), settings, brand, layouts, labels, or one settings group: search (Search & location), results (Results & sorting), filters (Filter behaviour), hours (Hours & open status), map (Map behaviour), markers (Map markers), layout (Layout & fields), directions (Directions & links), data (Data formatting)."New value: +"Which part to return. all (default), settings, brand, tokens (what the brand COMPUTES to: the derived muted text, borders, alternate surface and shadow, which are stored nowhere), layouts, labels, or one settings group: search (Search & location), results (Results & sorting), filters (Filter behaviour), hours (Hours & open status), map (Map behaviour), markers (Map markers), layout (Layout & fields), directions (Directions & links), data (Data formatting)."

changedInput schema / properties / section / enum

Previous value: -[
-  "all",
-  "settings",
-  "brand",
-  "layouts",
-  "labels",
-  "search",
-  "results",
-  "filters",
-  "hours",
-  "map",
-  "markers",
-  "layout",
-  "directions",
-  "data"
-]New value: +[
+  "all",
+  "settings",
+  "brand",
+  "tokens",
+  "layouts",
+  "labels",
+  "search",
+  "results",
+  "filters",
+  "hours",
+  "map",
+  "markers",
+  "layout",
+  "directions",
+  "data"
+]

1 tool updateSep 20, 2026
- Addedterritory

2 tool updatesSep 20, 2026

Changedcreate_location4 fields changed

changedInput schema / properties / hours / description

Previous value: -"Opening hours keyed by ISO weekday, 1 = Monday. Each value is a list of {open, close} in 24h HH:MM, or null for closed. REPLACES the whole week: any day left out is cleared. To change one day without restating the rest, use hoursPatch."New value: +"Opening hours keyed by ISO weekday, 1 = Monday. Each value is ONE {open, close} in 24h HH:MM, or null for closed — not a list, and a list is rejected. Example: {\"1\": {\"open\": \"09:00\", \"close\": \"17:00\"}, \"7\": null}. REPLACES the whole week: any day left out is cleared. To change one day without restating the rest, use hoursPatch."

changedInput schema / properties / hoursPatch / description

Previous value: -"Change only the days named, leaving every other day exactly as it is. Same shape as hours but partial: {\"7\": [{\"open\": \"10:00\", \"close\": \"16:00\"}]} changes Sunday alone. Use this to edit hours; it cannot silently revert a day you did not mention. Ignored if hours is also sent."New value: +"Change only the days named, leaving every other day exactly as it is. Same shape as hours but partial: {\"7\": {\"open\": \"10:00\", \"close\": \"16:00\"}} changes Sunday alone, and {\"7\": null} closes it. Use this to edit hours; it cannot silently revert a day you did not mention. Ignored if hours is also sent."

changedInput schema / properties / locations / items / properties / hours / description

Previous value: -"Opening hours keyed by ISO weekday, 1 = Monday. Each value is a list of {open, close} in 24h HH:MM, or null for closed. REPLACES the whole week: any day left out is cleared. To change one day without restating the rest, use hoursPatch."New value: +"Opening hours keyed by ISO weekday, 1 = Monday. Each value is ONE {open, close} in 24h HH:MM, or null for closed — not a list, and a list is rejected. Example: {\"1\": {\"open\": \"09:00\", \"close\": \"17:00\"}, \"7\": null}. REPLACES the whole week: any day left out is cleared. To change one day without restating the rest, use hoursPatch."

changedInput schema / properties / locations / items / properties / hoursPatch / description

Previous value: -"Change only the days named, leaving every other day exactly as it is. Same shape as hours but partial: {\"7\": [{\"open\": \"10:00\", \"close\": \"16:00\"}]} changes Sunday alone. Use this to edit hours; it cannot silently revert a day you did not mention. Ignored if hours is also sent."New value: +"Change only the days named, leaving every other day exactly as it is. Same shape as hours but partial: {\"7\": {\"open\": \"10:00\", \"close\": \"16:00\"}} changes Sunday alone, and {\"7\": null} closes it. Use this to edit hours; it cannot silently revert a day you did not mention. Ignored if hours is also sent."

Changedupdate_location2 fields changed

changedInput schema / properties / hours / description

Previous value: -"Opening hours keyed by ISO weekday, 1 = Monday. Each value is a list of {open, close} in 24h HH:MM, or null for closed. REPLACES the whole week: any day left out is cleared. To change one day without restating the rest, use hoursPatch."New value: +"Opening hours keyed by ISO weekday, 1 = Monday. Each value is ONE {open, close} in 24h HH:MM, or null for closed — not a list, and a list is rejected. Example: {\"1\": {\"open\": \"09:00\", \"close\": \"17:00\"}, \"7\": null}. REPLACES the whole week: any day left out is cleared. To change one day without restating the rest, use hoursPatch."

changedInput schema / properties / hoursPatch / description

Previous value: -"Change only the days named, leaving every other day exactly as it is. Same shape as hours but partial: {\"7\": [{\"open\": \"10:00\", \"close\": \"16:00\"}]} changes Sunday alone. Use this to edit hours; it cannot silently revert a day you did not mention. Ignored if hours is also sent."New value: +"Change only the days named, leaving every other day exactly as it is. Same shape as hours but partial: {\"7\": {\"open\": \"10:00\", \"close\": \"16:00\"}} changes Sunday alone, and {\"7\": null} closes it. Use this to edit hours; it cannot silently revert a day you did not mention. Ignored if hours is also sent."

6 tool updatesSep 20, 2026

Changedcreate_location5 fields changed

changedInput schema / properties / hours / description

Previous value: -"Opening hours keyed by ISO weekday, 1 = Monday. Each value is a list of {open, close} in 24h HH:MM, or null for closed."New value: +"Opening hours keyed by ISO weekday, 1 = Monday. Each value is a list of {open, close} in 24h HH:MM, or null for closed. REPLACES the whole week: any day left out is cleared. To change one day without restating the rest, use hoursPatch."

addedInput schema / properties / hoursPatch

Added value: +{
+  "description": "Change only the days named, leaving every other day exactly as it is. Same shape as hours but partial: {\"7\": [{\"open\": \"10:00\", \"close\": \"16:00\"}]} changes Sunday alone. Use this to edit hours; it cannot silently revert a day you did not mention. Ignored if hours is also sent.",
+  "type": "object"
+}

addedInput schema / properties / locations

Added value: +{
+  "description": "Several locations to add in one call (at most 50). Use this instead of the top-level fields when adding more than one; each entry takes the same fields.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "address": {
+        "description": "Full address as a person would write it. Geocoded automatically unless lat and lng are supplied.",
+        "type": "string"
+      },
+      "addressLine1": {
+        "description": "Street line, when the address is structured.",
+        "type": "string"
+      },
+      "city": {
+        "type": "string"
+      },
+      "countryCode": {
+        "description": "Two-letter ISO country code.",
+        "type": "string"
+      },
+      "customFields": {
+        "description": "Extra fields, keyed by the label shown to visitors. The value is either a plain string, or an object {value, color, icon, style} where `value` is the URL or text. There is no `label` or `url` key: the label is the key, and the URL goes in `value`. Example: {\"Book a table\": {\"value\": \"https://example.com/book\", \"color\": \"#C2540E\"}}. Never use this for tags or categories; use the categories field instead.",
+        "type": "object"
+      },
+      "description": {
+        "type": "string"
+      },
+      "email": {
+        "type": "string"
+      },
+      "hours": {
+        "description": "Opening hours keyed by ISO weekday, 1 = Monday. Each value is a list of {open, close} in 24h HH:MM, or null for closed. REPLACES the whole week: any day left out is cleared. To change one day without restating the rest, use hoursPatch.",
+        "type": "object"
+      },
+      "hoursPatch": {
+        "description": "Change only the days named, leaving every other day exactly as it is. Same shape as hours but partial: {\"7\": [{\"open\": \"10:00\", \"close\": \"16:00\"}]} changes Sunday alone. Use this to edit hours; it cannot silently revert a day you did not mention. Ignored if hours is also sent.",
+        "type": "object"
+      },
+      "imageUrl": {
+        "type": "string"
+      },
+      "lat": {
+        "description": "Latitude. Supplying lat and lng skips geocoding.",
+        "type": "number"
+      },
+      "lng": {
+        "description": "Longitude.",
+        "type": "number"
+      },
+      "locationType": {
+        "description": "point is a physical address, service_area covers a radius, online is a stockist with no address.",
+        "enum": [
+          "point",
+          "service_area",
+          "online"
+        ],
+        "type": "string"
+      },
+      "markerColor": {
+        "description": "Hex colour for this location's map marker.",
+        "type": "string"
+      },
+      "name": {
+        "description": "Business or store name.",
+        "type": "string"
+      },
+      "onlineRegions": {
+        "description": "For an online location: two-letter country codes it ships to or serves, e.g. [\"us\", \"ca\"]. Empty means every visitor sees it.",
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "phone": {
+        "type": "string"
+      },
+      "postalCode": {
+        "type": "string"
+      },
+      "priority": {
+        "description": "Higher sorts first when there is no visitor position.",
+        "type": "number"
+      },
+      "serviceAreaCircleVisible": {
+        "description": "For a service_area location: whether to draw its coverage circle. Null (the default) follows the locator's serviceAreaCircleVisible setting. False draws the pin without the circle.",
+        "type": [
+          "boolean",
+          "null"
+        ]
+      },
+      "serviceRadiusKm": {
+        "description": "Radius in km, for a service_area location.",
+        "type": "number"
+      },
+      "state": {
+        "type": "string"
+      },
+      "timezone": {
+        "description": "IANA timezone, for example America/Chicago.",
+        "type": "string"
+      },
+      "visibility": {
+        "description": "hidden keeps the location in the account but off the public locator.",
+        "enum": [
+          "visible",
+          "hidden"
+        ],
+        "type": "string"
+      },
+      "website": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "name"
+    ],
+    "type": "object"
+  },
+  "maxItems": 50,
+  "type": "array"
+}

addedInput schema / properties / serviceAreaCircleVisible

Added value: +{
+  "description": "For a service_area location: whether to draw its coverage circle. Null (the default) follows the locator's serviceAreaCircleVisible setting. False draws the pin without the circle.",
+  "type": [
+    "boolean",
+    "null"
+  ]
+}

removedInput schema / required
```
Removed value: -[
-  "name"
-]
```

Changedpropose_configuration6 fields changed

addedInput schema / properties / settings / properties / serviceAreaCircleColor

Added value: +{
+  "description": "Service area fill. The circle's fill colour. Used only when Service area colour is set to Custom. Only applies when serviceAreaCircleColorSource is custom.",
+  "type": "string"
+}

addedInput schema / properties / settings / properties / serviceAreaCircleColorSource

Added value: +{
+  "description": "Service area colour. Where a coverage circle takes its colour from, independently of the pins. Only applies when serviceAreaCircleVisible is true. marker = Match the pin; accent = Brand accent; custom = Custom colour.",
+  "enum": [
+    "marker",
+    "accent",
+    "custom"
+  ],
+  "type": "string"
+}

addedInput schema / properties / settings / properties / serviceAreaCircleOpacity

Added value: +{
+  "description": "Service area fill opacity. How solid the circle's fill is. Lower values keep overlapping areas readable. Only applies when serviceAreaCircleVisible is true. In %.",
+  "maximum": 100,
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / settings / properties / serviceAreaCircleStrokeColor

Added value: +{
+  "description": "Service area outline. The circle's outline colour. Leave empty to follow the fill colour. Only applies when serviceAreaCircleVisible is true.",
+  "type": "string"
+}

addedInput schema / properties / settings / properties / serviceAreaCircleStrokeWeight

Added value: +{
+  "description": "Service area outline width. Thickness of the circle's outline. Zero removes it, leaving the fill alone. Only applies when serviceAreaCircleVisible is true. In px.",
+  "maximum": 8,
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / settings / properties / serviceAreaCircleVisible

Added value: +{
+  "description": "Service area circles. Draw the coverage circle around service-area locations. Only applies when locatorLayout is not listOnly or gridOnly.",
+  "type": "boolean"
+}

Changedset_custom_field1 field changed

changedInput schema / properties / icon / enum

Previous value: -[
-  "store",
-  "shopping-bag",
-  "shopping-cart",
-  "coffee",
-  "utensils",
-  "wine",
-  "car",
-  "truck",
-  "package",
-  "fuel",
-  "circle-parking",
-  "wifi",
-  "clock",
-  "credit-card",
-  "accessibility",
-  "dog",
-  "baby",
-  "wrench",
-  "stethoscope",
-  "pill",
-  "dumbbell",
-  "building-2",
-  "warehouse",
-  "leaf",
-  "star"
-]New value: +[
+  "store",
+  "shopping-bag",
+  "shopping-cart",
+  "coffee",
+  "utensils",
+  "wine",
+  "car",
+  "truck",
+  "package",
+  "fuel",
+  "circle-parking",
+  "wifi",
+  "clock",
+  "calendar",
+  "credit-card",
+  "accessibility",
+  "dog",
+  "baby",
+  "wrench",
+  "stethoscope",
+  "pill",
+  "dumbbell",
+  "building-2",
+  "warehouse",
+  "leaf",
+  "star"
+]

Changedset_tag_style1 field changed

changedInput schema / properties / icon / enum

Previous value: -[
-  "store",
-  "shopping-bag",
-  "shopping-cart",
-  "coffee",
-  "utensils",
-  "wine",
-  "car",
-  "truck",
-  "package",
-  "fuel",
-  "circle-parking",
-  "wifi",
-  "clock",
-  "credit-card",
-  "accessibility",
-  "dog",
-  "baby",
-  "wrench",
-  "stethoscope",
-  "pill",
-  "dumbbell",
-  "building-2",
-  "warehouse",
-  "leaf",
-  "star"
-]New value: +[
+  "store",
+  "shopping-bag",
+  "shopping-cart",
+  "coffee",
+  "utensils",
+  "wine",
+  "car",
+  "truck",
+  "package",
+  "fuel",
+  "circle-parking",
+  "wifi",
+  "clock",
+  "calendar",
+  "credit-card",
+  "accessibility",
+  "dog",
+  "baby",
+  "wrench",
+  "stethoscope",
+  "pill",
+  "dumbbell",
+  "building-2",
+  "warehouse",
+  "leaf",
+  "star"
+]

Changedtag_locations3 fields changed

addedInput schema / properties / color

Added value: +{
+  "description": "Optional. Hex colour for the tag's chip, for example \"#E64893\". Applied in this same call.",
+  "type": "string"
+}

addedInput schema / properties / group

Added value: +{
+  "description": "Optional. Filter group for the tag, for example \"Flavour\". Applied in this same call, so a tag can be created, applied and grouped at once.",
+  "type": "string"
+}

addedInput schema / properties / icon

Added value: +{
+  "description": "Optional. Glyph for the tag's chip. Applied in this same call.",
+  "enum": [
+    "store",
+    "shopping-bag",
+    "shopping-cart",
+    "coffee",
+    "utensils",
+    "wine",
+    "car",
+    "truck",
+    "package",
+    "fuel",
+    "circle-parking",
+    "wifi",
+    "clock",
+    "calendar",
+    "credit-card",
+    "accessibility",
+    "dog",
+    "baby",
+    "wrench",
+    "stethoscope",
+    "pill",
+    "dumbbell",
+    "building-2",
+    "warehouse",
+    "leaf",
+    "star"
+  ],
+  "type": "string"
+}

Changedupdate_location3 fields changed

changedInput schema / properties / hours / description

Previous value: -"Opening hours keyed by ISO weekday, 1 = Monday. Each value is a list of {open, close} in 24h HH:MM, or null for closed."New value: +"Opening hours keyed by ISO weekday, 1 = Monday. Each value is a list of {open, close} in 24h HH:MM, or null for closed. REPLACES the whole week: any day left out is cleared. To change one day without restating the rest, use hoursPatch."

addedInput schema / properties / hoursPatch

Added value: +{
+  "description": "Change only the days named, leaving every other day exactly as it is. Same shape as hours but partial: {\"7\": [{\"open\": \"10:00\", \"close\": \"16:00\"}]} changes Sunday alone. Use this to edit hours; it cannot silently revert a day you did not mention. Ignored if hours is also sent.",
+  "type": "object"
+}

addedInput schema / properties / serviceAreaCircleVisible

Added value: +{
+  "description": "For a service_area location: whether to draw its coverage circle. Null (the default) follows the locator's serviceAreaCircleVisible setting. False draws the pin without the circle.",
+  "type": [
+    "boolean",
+    "null"
+  ]
+}

1 tool updateSep 19, 2026
- Removedlocation_pages

6 tool updatesSep 19, 2026

Changedcreate_location1 field changed

addedInput schema / properties / onlineRegions

Added value: +{
+  "description": "For an online location: two-letter country codes it ships to or serves, e.g. [\"us\", \"ca\"]. Empty means every visitor sees it.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Changedget_embed_code2 fields changed

addedInput schema / properties / near

Added value: +{
+  "description": "A place to search near when the page opens, e.g. 'Austin, TX'.",
+  "type": "string"
+}

addedInput schema / properties / tags

Added value: +{
+  "description": "Lock this embed to locations carrying any of these tags (names or slugs), for a page about one product, service or region.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Addedlocation_pages
Changedpropose_configuration1 field changed
- addedInput schema / properties / labels / properties / learnMore
```
Added value: +{
+  "description": "results. Default: \"Learn more\".",
+  "type": "string"
+}
```
Addedspotlight

Changedupdate_location1 field changed

addedInput schema / properties / onlineRegions

Added value: +{
+  "description": "For an online location: two-letter country codes it ships to or serves, e.g. [\"us\", \"ca\"]. Empty means every visitor sees it.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

4 tool updatesSep 18, 2026

Changeddelete_location2 fields changed

addedInput schema / properties / ids

Added value: +{
+  "description": "Several location ids, to apply the same change to all of them in one call (at most 200). Use either id or ids.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 200,
+  "type": "array"
+}

removedInput schema / required
```
Removed value: -[
-  "id"
-]
```

Changeddescribe_configuration1 field changed

addedInput schema / properties / section

Added value: +{
+  "description": "Which part to return. all (default), settings, brand, layouts, labels, or one settings group: search (Search & location), results (Results & sorting), filters (Filter behaviour), hours (Hours & open status), map (Map behaviour), markers (Map markers), layout (Layout & fields), directions (Directions & links), data (Data formatting).",
+  "enum": [
+    "all",
+    "settings",
+    "brand",
+    "layouts",
+    "labels",
+    "search",
+    "results",
+    "filters",
+    "hours",
+    "map",
+    "markers",
+    "layout",
+    "directions",
+    "data"
+  ],
+  "type": "string"
+}

Changedpropose_configuration12 fields changed

addedInput schema / properties / branding / additionalProperties
```
Added value: +false
```

changedInput schema / properties / branding / description

Previous value: -"Brand changes: { accentColor?: '#RRGGBB', settings?: { ...brand tokens } }."New value: +"Brand changes. accentColor sits at this level; every other token goes inside settings."

addedInput schema / properties / branding / properties

Added value: +{
+  "accentColor": {
+    "description": "The brand accent: markers, links, active controls.",
+    "pattern": "^#[0-9A-Fa-f]{6}$",
+    "type": "string"
+  },
+  "settings": {
+    "additionalProperties": false,
+    "properties": {
+      "backgroundColor": {
+        "description": "Six-digit hex colour, e.g. #1F2A44.",
+        "pattern": "^#[0-9A-Fa-f]{6}$",
+        "type": "string"
+      },
+      "borderColor": {
+        "anyOf": [
+          {
+            "pattern": "^#[0-9A-Fa-f]{6}$",
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "description": "null derives a hairline from the text colour."
+      },
+      "borderWeight": {
+        "enum": [
+          "hairline",
+          "standard",
+          "bold"
+        ],
+        "type": "string"
+      },
+      "borderWidthPx": {
+        "anyOf": [
+          {
+            "maximum": 8,
+            "minimum": 0,
+            "type": "number"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "description": "Overrides borderWeight."
+      },
+      "buttonColor": {
+        "description": "Six-digit hex colour, e.g. #1F2A44.",
+        "pattern": "^#[0-9A-Fa-f]{6}$",
+        "type": "string"
+      },
+      "buttonSize": {
+        "enum": [
+          "small",
+          "medium",
+          "large"
+        ],
+        "type": "string"
+      },
+      "cornerRadiusPx": {
+        "anyOf": [
+          {
+            "maximum": 48,
+            "minimum": 0,
+            "type": "number"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "description": "Overrides cornerStyle."
+      },
+      "cornerStyle": {
+        "enum": [
+          "sharp",
+          "soft",
+          "pill"
+        ],
+        "type": "string"
+      },
+      "customFontDisplay": {
+        "anyOf": [
+          {
+            "additionalProperties": false,
+            "properties": {
+              "faces": {
+                "items": {
+                  "additionalProperties": false,
+                  "properties": {
+                    "url": {
+                      "description": "Public https URL of a .woff2 file.",
+                      "type": "string"
+                    },
+                    "weight": {
+                      "enum": [
+                        400,
+                        600
+                      ],
+                      "type": "number"
+                    }
+                  },
+                  "required": [
+                    "weight",
+                    "url"
+                  ],
+                  "type": "object"
+                },
+                "type": "array"
+              },
+              "family": {
+                "description": "CSS family name, e.g. \"Cormorant Garamond\".",
+                "type": "string"
+              },
+              "source": {
+                "enum": [
+                  "google",
+                  "upload"
+                ],
+                "type": "string"
+              }
+            },
+            "required": [
+              "family",
+              "faces"
+            ],
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "description": "A self-hosted web font. Also set fontDisplay (or fontText) to \"custom\" for it to be used. null removes it."
+      },
+      "customFontText": {
+        "anyOf": [
+          {
+            "additionalProperties": false,
+            "properties": {
+              "faces": {
+                "items": {
+                  "additionalProperties": false,
+                  "properties": {
+                    "url": {
+                      "description": "Public https URL of a .woff2 file.",
+                      "type": "string"
+                    },
+                    "weight": {
+                      "enum": [
+                        400,
+                        600
+                      ],
+                      "type": "number"
+                    }
+                  },
+                  "required": [
+                    "weight",
+                    "url"
+                  ],
+                  "type": "object"
+                },
+                "type": "array"
+              },
+              "family": {
+                "description": "CSS family name, e.g. \"Cormorant Garamond\".",
+                "type": "string"
+              },
+              "source": {
+                "enum": [
+                  "google",
+                  "upload"
+                ],
+                "type": "string"
+              }
+            },
+            "required": [
+              "family",
+              "faces"
+            ],
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "description": "A self-hosted web font. Also set fontDisplay (or fontText) to \"custom\" for it to be used. null removes it."
+      },
+      "fontDisplay": {
+        "description": "Headings and the business name.",
+        "enum": [
+          "system",
+          "website",
+          "humanist",
+          "serif",
+          "custom"
+        ],
+        "type": "string"
+      },
+      "fontFamily": {
+        "description": "Legacy single font. Prefer fontDisplay and fontText.",
+        "enum": [
+          "system",
+          "website",
+          "humanist",
+          "serif",
+          "custom"
+        ],
+        "type": "string"
+      },
+      "fontScale": {
+        "enum": [
+          "compact",
+          "standard",
+          "large"
+        ],
+        "type": "string"
+      },
+      "fontText": {
+        "description": "Body copy, addresses and controls.",
+        "enum": [
+          "system",
+          "website",
+          "humanist",
+          "serif",
+          "custom"
+        ],
+        "type": "string"
+      },
+      "markerImageUrl": {
+        "anyOf": [
+          {
+            "pattern": "^https://",
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "description": "A custom map-marker image, hosted anywhere over https (upload it to your own storage and paste the link, like Webflow). Also set the markerStyle setting to \"custom\" for it to show; null clears it and returns to the pin/dot style."
+      },
+      "primaryButtonStyle": {
+        "enum": [
+          "filled",
+          "outline"
+        ],
+        "type": "string"
+      },
+      "secondaryButtonColor": {
+        "anyOf": [
+          {
+            "pattern": "^#[0-9A-Fa-f]{6}$",
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "description": "null follows the accent colour."
+      },
+      "shadowStyle": {
+        "enum": [
+          "none",
+          "soft",
+          "hard"
+        ],
+        "type": "string"
+      },
+      "spacing": {
+        "enum": [
+          "compact",
+          "comfortable",
+          "spacious"
+        ],
+        "type": "string"
+      },
+      "tagChipBackground": {
+        "anyOf": [
+          {
+            "pattern": "^#[0-9A-Fa-f]{6}$",
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "description": "Fill colour of the category chips on result cards. null keeps the faint ink tint. Pair with tagChipTextColor for the neutral grey-pill look."
+      },
+      "tagChipTextColor": {
+        "anyOf": [
+          {
+            "pattern": "^#[0-9A-Fa-f]{6}$",
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "description": "Text colour inside category chips. null follows the body text colour."
+      },
+      "textColor": {
+        "description": "Six-digit hex colour, e.g. #1F2A44.",
+        "pattern": "^#[0-9A-Fa-f]{6}$",
+        "type": "string"
+      }
+    },
+    "type": "object"
+  }
+}

addedInput schema / properties / labels / additionalProperties
```
Added value: +false
```

changedInput schema / properties / labels / description

Previous value: -"Visitor-facing wording overrides, by label key."New value: +"Visitor-facing wording overrides. {place} and {count} are substituted where the default uses them."

addedInput schema / properties / labels / properties

Added value: +{
+  "approximateNear": {
+    "description": "search. Default: \"Near {place}\".",
+    "type": "string"
+  },
+  "backToResults": {
+    "description": "results. Default: \"Back to results\".",
+    "type": "string"
+  },
+  "clearGroup": {
+    "description": "search. Default: \"Clear {group}\".",
+    "type": "string"
+  },
+  "clearSearch": {
+    "description": "search. Default: \"Clear search\".",
+    "type": "string"
+  },
+  "closedDay": {
+    "description": "hours. Default: \"Closed\".",
+    "type": "string"
+  },
+  "closedNow": {
+    "description": "hours. Default: \"Closed now\".",
+    "type": "string"
+  },
+  "closedToday": {
+    "description": "hours. Default: \"Closed today\".",
+    "type": "string"
+  },
+  "closedUntil": {
+    "description": "hours. Default: \"Opens {day} at {time}\".",
+    "type": "string"
+  },
+  "directions": {
+    "description": "links. Default: \"Directions\".",
+    "type": "string"
+  },
+  "email": {
+    "description": "links. Default: \"Email\".",
+    "type": "string"
+  },
+  "empty": {
+    "description": "results. Default: \"No locations to show yet.\".",
+    "type": "string"
+  },
+  "emptyInitial": {
+    "description": "results. Default: \"Search to see locations.\".",
+    "type": "string"
+  },
+  "enquiryCancel": {
+    "description": "results. Default: \"Cancel\".",
+    "type": "string"
+  },
+  "enquiryEmail": {
+    "description": "results. Default: \"Your email\".",
+    "type": "string"
+  },
+  "enquiryMessage": {
+    "description": "results. Default: \"What can we help with?\".",
+    "type": "string"
+  },
+  "enquiryName": {
+    "description": "results. Default: \"Your name\".",
+    "type": "string"
+  },
+  "enquiryOpen": {
+    "description": "results. Default: \"Send an enquiry\".",
+    "type": "string"
+  },
+  "enquiryPhone": {
+    "description": "results. Default: \"Phone (optional)\".",
+    "type": "string"
+  },
+  "enquirySending": {
+    "description": "results. Default: \"Sending\".",
+    "type": "string"
+  },
+  "enquirySent": {
+    "description": "results. Default: \"Thanks. Someone will be in touch.\".",
+    "type": "string"
+  },
+  "enquirySubmit": {
+    "description": "results. Default: \"Send\".",
+    "type": "string"
+  },
+  "enquiryTitle": {
+    "description": "results. Default: \"We will pass this to the right branch\".",
+    "type": "string"
+  },
+  "expandSearch": {
+    "description": "search. Default: \"Expand search\".",
+    "type": "string"
+  },
+  "fallback": {
+    "description": "results. Default: \"No exact matches - showing all {count} locations.\".",
+    "type": "string"
+  },
+  "filterNoMatches": {
+    "description": "search. Default: \"No matching filters\".",
+    "type": "string"
+  },
+  "hideMap": {
+    "description": "search. Default: \"Hide map\".",
+    "type": "string"
+  },
+  "loadError": {
+    "description": "results. Default: \"Couldn’t load locations. Please try again later.\".",
+    "type": "string"
+  },
+  "loading": {
+    "description": "results. Default: \"Loading locations…\".",
+    "type": "string"
+  },
+  "locateMe": {
+    "description": "search. Default: \"Use my location\".",
+    "type": "string"
+  },
+  "locationBlocked": {
+    "description": "search. Default: \"Location is blocked for this site. Allow it in your browser settings, or search for a town or postcode instead.\".",
+    "type": "string"
+  },
+  "locationUnavailable": {
+    "description": "search. Default: \"We couldn't use your location. Search for a town or postcode instead.\".",
+    "type": "string"
+  },
+  "mapError": {
+    "description": "results. Default: \"Map failed to load.\".",
+    "type": "string"
+  },
+  "mapKeyMissing": {
+    "description": "results. Default: \"Map unavailable - a map key has not been added yet.\".",
+    "type": "string"
+  },
+  "nearMe": {
+    "description": "search. Default: \"Your location\".",
+    "type": "string"
+  },
+  "nearNotFound": {
+    "description": "search. Default: \"We couldn't find that place. Try a postcode or a town name.\".",
+    "type": "string"
+  },
+  "nearPlaceholder": {
+    "description": "search. Default: \"Enter a town or postcode\". The search box placeholder while searchBehaviour is nearLocation (the default).",
+    "type": "string"
+  },
+  "nearSubmit": {
+    "description": "search. Default: \"Search\".",
+    "type": "string"
+  },
+  "nearbyTab": {
+    "description": "results. Default: \"Nearby locations ({count})\".",
+    "type": "string"
+  },
+  "nearestLocation": {
+    "description": "results. Default: \"Nearest location\".",
+    "type": "string"
+  },
+  "noMatches": {
+    "description": "results. Default: \"No locations match your search.\".",
+    "type": "string"
+  },
+  "noNearby": {
+    "description": "results. Default: \"No locations found near {place}.\".",
+    "type": "string"
+  },
+  "onlineTab": {
+    "description": "results. Default: \"Online options ({count})\".",
+    "type": "string"
+  },
+  "openNow": {
+    "description": "search. Default: \"Open now\".",
+    "type": "string"
+  },
+  "openUntil": {
+    "description": "hours. Default: \"Open until {time}\".",
+    "type": "string"
+  },
+  "opensAt": {
+    "description": "hours. Default: \"Opens {time}\".",
+    "type": "string"
+  },
+  "radiusAny": {
+    "description": "search. Default: \"Any distance\".",
+    "type": "string"
+  },
+  "radiusLabel": {
+    "description": "search. Default: \"Search radius\".",
+    "type": "string"
+  },
+  "radiusOption": {
+    "description": "search. Default: \"{radius}\".",
+    "type": "string"
+  },
+  "resetAll": {
+    "description": "search. Default: \"Reset\".",
+    "type": "string"
+  },
+  "searchPlaceholder": {
+    "description": "search. Default: \"Search by name, city, or zip\". The search box placeholder only while searchBehaviour is filterText.",
+    "type": "string"
+  },
+  "serviceArea": {
+    "description": "results. Default: \"Serves {radius}km radius\".",
+    "type": "string"
+  },
+  "sheetExpandedLabel": {
+    "description": "results. Default: \"Tap to view map\".",
+    "type": "string"
+  },
+  "sheetPeekLabel": {
+    "description": "results. Default: \"{count} results - tap to view list\".",
+    "type": "string"
+  },
+  "showMap": {
+    "description": "search. Default: \"Show map\".",
+    "type": "string"
+  },
+  "website": {
+    "description": "links. Default: \"Website\".",
+    "type": "string"
+  }
+}

addedInput schema / properties / layouts / additionalProperties
```
Added value: +false
```

changedInput schema / properties / layouts / description

Previous value: -"Field layout per surface: { card?, popup?, detail? }, each { order, hidden, regions }."New value: +"Which fields each surface shows, and in what order."

addedInput schema / properties / layouts / properties

Added value: +{
+  "card": {
+    "additionalProperties": false,
+    "properties": {
+      "hidden": {
+        "description": "Fields not shown on this surface.",
+        "items": {
+          "enum": [
+            "image",
+            "openStatus",
+            "serviceArea",
+            "distance",
+            "address",
+            "description",
+            "categories",
+            "hours",
+            "phone",
+            "email",
+            "website",
+            "directions",
+            "customFields"
+          ],
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "order": {
+        "description": "The fields to show, top to bottom. Fields you leave out keep their current place.",
+        "items": {
+          "enum": [
+            "image",
+            "openStatus",
+            "serviceArea",
+            "distance",
+            "address",
+            "description",
+            "categories",
+            "hours",
+            "phone",
+            "email",
+            "website",
+            "directions",
+            "customFields"
+          ],
+          "type": "string"
+        },
+        "type": "array"
+      }
+    },
+    "type": "object"
+  },
+  "detail": {
+    "additionalProperties": false,
+    "properties": {
+      "hidden": {
+        "description": "Fields not shown on this surface.",
+        "items": {
+          "enum": [
+            "image",
+            "openStatus",
+            "serviceArea",
+            "distance",
+            "address",
+            "description",
+            "categories",
+            "hours",
+            "phone",
+            "email",
+            "website",
+            "directions",
+            "customFields"
+          ],
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "order": {
+        "description": "The fields to show, top to bottom. Fields you leave out keep their current place.",
+        "items": {
+          "enum": [
+            "image",
+            "openStatus",
+            "serviceArea",
+            "distance",
+            "address",
+            "description",
+            "categories",
+            "hours",
+            "phone",
+            "email",
+            "website",
+            "directions",
+            "customFields"
+          ],
+          "type": "string"
+        },
+        "type": "array"
+      }
+    },
+    "type": "object"
+  },
+  "popup": {
+    "additionalProperties": false,
+    "properties": {
+      "hidden": {
+        "description": "Fields not shown on this surface.",
+        "items": {
+          "enum": [
+            "image",
+            "openStatus",
+            "serviceArea",
+            "distance",
+            "address",
+            "description",
+            "categories",
+            "hours",
+            "phone",
+            "email",
+            "website",
+            "directions",
+            "customFields"
+          ],
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "order": {
+        "description": "The fields to show, top to bottom. Fields you leave out keep their current place.",
+        "items": {
+          "enum": [
+            "image",
+            "openStatus",
+            "serviceArea",
+            "distance",
+            "address",
+            "description",
+            "categories",
+            "hours",
+            "phone",
+            "email",
+            "website",
+            "directions",
+            "customFields"
+          ],
+          "type": "string"
+        },
+        "type": "array"
+      }
+    },
+    "type": "object"
+  }
+}

addedInput schema / properties / settings / additionalProperties
```
Added value: +false
```

changedInput schema / properties / settings / description

Previous value: -"Behaviour settings by key, from describe_configuration."New value: +"Behaviour settings to change. Only send the keys you want to change. Heights are two keys: mapHeight for the map and listMaxHeight for the result list."

addedInput schema / properties / settings / properties

Added value: +{
+  "addressAutocomplete": {
+    "description": "Address autocomplete. Suggests real addresses as the visitor types. Requires a geocoding provider to be connected first. Only applies when searchBehaviour is nearLocation. off = Off; full = Full address autocomplete; cityRegion = City and region only.",
+    "enum": [
+      "off",
+      "full",
+      "cityRegion"
+    ],
+    "type": "string"
+  },
+  "addressSearchCountries": {
+    "description": "Address countries. Restricts place and address searches to selected countries, using ISO codes such as US, CA, or GB. Only applies when searchBehaviour is nearLocation.",
+    "type": "string"
+  },
+  "autoLocateVisitors": {
+    "description": "Visitor location. Ask the browser for the visitor's location as soon as the widget loads, so they see nearby results without typing. Only applies when searchBehaviour is nearLocation.",
+    "type": "boolean"
+  },
+  "autoSelectFirst": {
+    "description": "After a search. What happens to the closest result once a visitor has searched. none = Leave everything unselected; highlight = Highlight the first result; detail = Open the first result's details; popup = Open its map popup.",
+    "enum": [
+      "none",
+      "highlight",
+      "detail",
+      "popup"
+    ],
+    "type": "string"
+  },
+  "cardClickBehaviour": {
+    "description": "Result click. Highlight keeps the list in place and moves the map. highlight = Highlight it on the map; detail = Open full details.",
+    "enum": [
+      "highlight",
+      "detail"
+    ],
+    "type": "string"
+  },
+  "clusterShape": {
+    "description": "Cluster shape. The shape of the numbered bubble that stands in for overlapping pins. Only applies when markerClustering is true. circle = Circle; rounded = Rounded square; square = Square.",
+    "enum": [
+      "circle",
+      "rounded",
+      "square"
+    ],
+    "type": "string"
+  },
+  "deduplicateOnImport": {
+    "description": "Duplicate rows. Flags an imported row when a location with the same name and address already exists, and leaves it unticked so it is not imported twice.",
+    "type": "boolean"
+  },
+  "defaultMapCenter": {
+    "description": "Opening centre. Search for the town or region where the locator should open. Only applies when defaultMapView is place.",
+    "type": "string"
+  },
+  "defaultMapView": {
+    "description": "When the locator opens. Choose what visitors see before they search. locations = Show all locations; approximate = Start approximately near the visitor; place = Start at a place I choose; empty = Wait until the visitor searches.",
+    "enum": [
+      "locations",
+      "approximate",
+      "place",
+      "empty"
+    ],
+    "type": "string"
+  },
+  "defaultMapZoom": {
+    "description": "Opening zoom. How close the map starts when it opens on a fixed place. Only applies when defaultMapView is place. 4 = Country; 6 = Region; 8 = State; 11 = City; 13 = District; 15 = Neighbourhood.",
+    "enum": [
+      "4",
+      "6",
+      "8",
+      "11",
+      "13",
+      "15"
+    ],
+    "type": "string"
+  },
+  "defaultOpenClosedView": {
+    "description": "Default hours view. What the Open now toggle is set to when the widget first loads. Only applies when openClosedFilter is true. all = Show all locations; openOnly = Show open locations only.",
+    "enum": [
+      "all",
+      "openOnly"
+    ],
+    "type": "string"
+  },
+  "defaultSearchRadius": {
+    "description": "Default search radius. The distance searched when a visitor has not picked one. Only applies when showRadiusSelector is true. unlimited = Any distance; 10 = 10; 25 = 25; 50 = 50; 100 = 100.",
+    "enum": [
+      "unlimited",
+      "10",
+      "25",
+      "50",
+      "100"
+    ],
+    "type": "string"
+  },
+  "directionsProvider": {
+    "description": "Directions provider. Match the device sends iPhone and iPad visitors to Apple Maps and everyone else to Google Maps. google = Always Google Maps; apple = Always Apple Maps; device = Match the visitor's device.",
+    "enum": [
+      "google",
+      "apple",
+      "device"
+    ],
+    "type": "string"
+  },
+  "distanceNumericFormat": {
+    "description": "Distance format. Choose how many decimal places appear beside locations. default = Smart rounding; whole = Whole numbers; oneDecimal = One decimal.",
+    "enum": [
+      "default",
+      "whole",
+      "oneDecimal"
+    ],
+    "type": "string"
+  },
+  "distancePlacement": {
+    "description": "Distance position. Where the distance sits inside a result card. Only applies when locatorLayout is not mapOnly. details = With the details; afterActions = Below the buttons.",
+    "enum": [
+      "details",
+      "afterActions"
+    ],
+    "type": "string"
+  },
+  "distanceUnits": {
+    "description": "Distance units. Autodetect uses miles for visitors in the US, UK, and a few others, and kilometres everywhere else. auto = Autodetect from visitor; mi = Miles; km = Kilometres.",
+    "enum": [
+      "auto",
+      "mi",
+      "km"
+    ],
+    "type": "string"
+  },
+  "enquiryForm": {
+    "description": "Enquiry form. Let a visitor send an enquiry from the locator, routed to the dealer whose territory covers the address they searched. off = Off; afterSearch = Show after a search.",
+    "enum": [
+      "off",
+      "afterSearch"
+    ],
+    "type": "string"
+  },
+  "exportFormat": {
+    "description": "Export format. The file type used when you download your locations. csv = CSV; json = JSON.",
+    "enum": [
+      "csv",
+      "json"
+    ],
+    "type": "string"
+  },
+  "filterBehaviour": {
+    "description": "Filter matching. Match any is the forgiving default and rarely returns nothing. any = Match any selected filter; all = Match all selected filters.",
+    "enum": [
+      "any",
+      "all"
+    ],
+    "type": "string"
+  },
+  "filterPlacement": {
+    "description": "Filter placement. Choose where visitors see category and open-now filters. top = Top row; results = Above results; hidden = Hidden.",
+    "enum": [
+      "top",
+      "results",
+      "hidden"
+    ],
+    "type": "string"
+  },
+  "filterStyle": {
+    "description": "Filter style. Dropdowns keep the toolbar compact when you have many filters. dropdown = Dropdown per group; inline = Inline checkboxes.",
+    "enum": [
+      "dropdown",
+      "inline"
+    ],
+    "type": "string"
+  },
+  "fullScreenControl": {
+    "description": "Fullscreen control. Adds a control that expands the map to fill the browser window. Only applies when locatorLayout is not listOnly or gridOnly.",
+    "type": "boolean"
+  },
+  "geolocationErrorAlerts": {
+    "description": "Location errors. Tells the visitor when an automatic browser location request was refused or failed. Only applies when autoLocateVisitors is true.",
+    "type": "boolean"
+  },
+  "googleMapId": {
+    "description": "Google map ID. A cloud-styled map ID from the Google Cloud console, used instead of the built-in themes. Only applies when mapProvider is google.",
+    "type": "string"
+  },
+  "gridColumns": {
+    "description": "Grid columns. Sets how many result cards appear across when a grid layout is selected. Only applies when locatorLayout is gridBelow or gridOnly. In columns.",
+    "maximum": 6,
+    "minimum": 1,
+    "type": "number"
+  },
+  "groupedCardTags": {
+    "description": "Group tags. Puts each tag group's name above its own row of chips.",
+    "type": "boolean"
+  },
+  "hideBodyBeforeSearch": {
+    "description": "Hide locator body. Hide the map and results until a visitor searches.",
+    "type": "boolean"
+  },
+  "hideMarkersOutsideRadius": {
+    "description": "Radius marker visibility. Keeps the map showing only what is in the list. Off leaves distant pins visible for context. Only applies when showRadiusSelector is true.",
+    "type": "boolean"
+  },
+  "limitResults": {
+    "description": "Result limit. Caps how many locations appear in the list at once. Lower numbers keep long lists manageable on mobile. In locations.",
+    "maximum": 500,
+    "minimum": 1,
+    "type": "number"
+  },
+  "linkIconStyle": {
+    "description": "Link style. Icons alone are compact but less obvious. Icons with text is the safest for a general audience. textOnly = Text only; iconsAndText = Icons and text; iconsOnly = Icons only.",
+    "enum": [
+      "textOnly",
+      "iconsAndText",
+      "iconsOnly"
+    ],
+    "type": "string"
+  },
+  "listMaxHeight": {
+    "description": "List height. How tall the scrolling result list is, in pixels. Only applies when locatorLayout is not mapOnly. In px.",
+    "maximum": 1200,
+    "minimum": 150,
+    "type": "number"
+  },
+  "listScrollbar": {
+    "description": "Result list scrollbar. Whether the scrolling result list uses the browser's own scrollbar or a themed one. Only applies when locatorLayout is not mapOnly. auto = Browser default; themed = Match the text colour.",
+    "enum": [
+      "auto",
+      "themed"
+    ],
+    "type": "string"
+  },
+  "listTextAlign": {
+    "description": "Result text alignment. Aligns the name, address and details inside each result card. Only applies when locatorLayout is not mapOnly. left = Left; center = Centre.",
+    "enum": [
+      "left",
+      "center"
+    ],
+    "type": "string"
+  },
+  "locateMeButton": {
+    "description": "Use my location. Lets visitors use browser location without receiving a permission prompt on page load. Only applies when searchBehaviour is nearLocation. iconText = Icon and text; iconOnly = Icon only; hidden = Hidden.",
+    "enum": [
+      "iconText",
+      "iconOnly",
+      "hidden"
+    ],
+    "type": "string"
+  },
+  "locatorFrame": {
+    "description": "Outer frame. Draws a border around the whole locator and its map. none = No frame; border = Bordered.",
+    "enum": [
+      "none",
+      "border"
+    ],
+    "type": "string"
+  },
+  "locatorLayout": {
+    "description": "Locator layout. Where the list sits relative to the map. listLeft = List left of the map; listRight = List right of the map; listBelow = List below the map; gridBelow = Grid below the map; listOnly = List only, no map; gridOnly = Grid only, no map; mapOnly = Map only, no list.",
+    "enum": [
+      "listLeft",
+      "listRight",
+      "listBelow",
+      "gridBelow",
+      "listOnly",
+      "gridOnly",
+      "mapOnly"
+    ],
+    "type": "string"
+  },
+  "mapHeight": {
+    "description": "Map height. How tall the map area is on wider screens, in pixels. Narrow screens cap it at half the screen height so the results stay reachable. Only applies when locatorLayout is not listOnly or gridOnly. In px.",
+    "maximum": 900,
+    "minimum": 150,
+    "type": "number"
+  },
+  "mapProvider": {
+    "description": "Map provider. Which map renders your locator. Both render on your own account, so you add a key and the map loads bill to you. Only applies when locatorLayout is not listOnly or gridOnly. mapbox = Mapbox (your key); google = Google Maps (your key).",
+    "enum": [
+      "mapbox",
+      "google"
+    ],
+    "type": "string"
+  },
+  "mapTheme": {
+    "description": "Map style. Streets is the standard road map; Light, Dark, and Satellite are the alternate tile styles. Only applies when locatorLayout is not listOnly or gridOnly. streets = Streets; light = Light; dark = Dark; satellite = Satellite.",
+    "enum": [
+      "streets",
+      "light",
+      "dark",
+      "satellite"
+    ],
+    "type": "string"
+  },
+  "mapboxStyleUrl": {
+    "description": "Mapbox style. A style of your own from Mapbox Studio, used instead of the four built-in themes. Only applies when mapProvider is mapbox.",
+    "type": "string"
+  },
+  "markerClustering": {
+    "description": "Marker clusters. Replaces overlapping pins with a single numbered cluster that splits apart as the visitor zooms in. Only applies when locatorLayout is not listOnly or gridOnly.",
+    "type": "boolean"
+  },
+  "markerColorSource": {
+    "description": "Marker colour. Tag colour keeps the meaning your tags carry; Brand accent makes the pins match the rest of your locator. Only applies when locatorLayout is not listOnly or gridOnly. category = Tag colour; accent = Brand accent.",
+    "enum": [
+      "category",
+      "accent"
+    ],
+    "type": "string"
+  },
+  "markerImageAnchor": {
+    "description": "Artwork anchor. Which point of the artwork sits on the location's coordinate. Only applies when markerStyle is custom. bottom = Bottom edge (like a pin); center = Centre (like a dot).",
+    "enum": [
+      "bottom",
+      "center"
+    ],
+    "type": "string"
+  },
+  "markerImageWidth": {
+    "description": "Artwork size. How wide the uploaded marker artwork is drawn, in pixels. Only applies when markerStyle is custom. In px.",
+    "maximum": 96,
+    "minimum": 16,
+    "type": "number"
+  },
+  "markerNumbering": {
+    "description": "Marker numbers. Matches each pin to its position in the list, so a visitor can connect what they see on the map to what they are reading. Only applies when locatorLayout is not listOnly or gridOnly.",
+    "type": "boolean"
+  },
+  "markerRepositionOnClick": {
+    "description": "Marker position. Moving the clicked pin toward the bottom leaves room for its popup above it, instead of the popup running off the top of the map. Only applies when locatorLayout is not listOnly or gridOnly. center = Centre of the map; bottom = Bottom of the map; none = Do not move the map.",
+    "enum": [
+      "center",
+      "bottom",
+      "none"
+    ],
+    "type": "string"
+  },
+  "markerStyle": {
+    "description": "Marker style. Choose a classic pin, a compact dot or an uploaded custom marker image. Only applies when locatorLayout is not listOnly or gridOnly. pin = Classic pin; dot = Dot; logo = Logo inside a pin; custom = Custom image.",
+    "enum": [
+      "pin",
+      "dot",
+      "logo",
+      "custom"
+    ],
+    "type": "string"
+  },
+  "maxZoomLevel": {
+    "description": "Maximum zoom. How far in a visitor can zoom. 22 is fully zoomed in. Only applies when locatorLayout is not listOnly or gridOnly.",
+    "maximum": 22,
+    "minimum": 0,
+    "type": "number"
+  },
+  "minZoomLevel": {
+    "description": "Minimum zoom. How far out a visitor can zoom. 0 is the whole world. Only applies when locatorLayout is not listOnly or gridOnly.",
+    "maximum": 22,
+    "minimum": 0,
+    "type": "number"
+  },
+  "mobileTouchPanning": {
+    "description": "Mobile panning. Two fingers lets a visitor scroll the page past the map with one finger. Only applies when locatorLayout is not listOnly or gridOnly. twoFingers = Two fingers; oneFinger = One finger.",
+    "enum": [
+      "twoFingers",
+      "oneFinger"
+    ],
+    "type": "string"
+  },
+  "mouseScrollZoom": {
+    "description": "Wheel zoom. Off stops the map from swallowing the page scroll when a visitor scrolls past the widget. Only applies when locatorLayout is not listOnly or gridOnly.",
+    "type": "boolean"
+  },
+  "nearestLocationSummary": {
+    "description": "Nearest-location summary. Show a compact summary of the nearest matching location after a visitor searches near a place. hidden = Hidden; afterSearch = Show after search.",
+    "enum": [
+      "hidden",
+      "afterSearch"
+    ],
+    "type": "string"
+  },
+  "noResultsBehaviour": {
+    "description": "No results. Showing everything avoids a dead end for the visitor. showAll = Show all locations with a note; empty = Show an empty state.",
+    "enum": [
+      "showAll",
+      "empty"
+    ],
+    "type": "string"
+  },
+  "openClosedFilter": {
+    "description": "Open-only filter. Adds an Open now toggle to the toolbar.",
+    "type": "boolean"
+  },
+  "phoneNumberFormatting": {
+    "description": "Phone format. Reformats imported US and Canadian numbers to (555) 555-0100. Off keeps exactly what was in your file.",
+    "type": "boolean"
+  },
+  "popupColumns": {
+    "description": "Popup columns. How a location's details are arranged in the popup that opens from a map pin. Two columns also widens the popup, since two narrow columns read worse than one. singleColumn = Single column; twoColumn = Two columns.",
+    "enum": [
+      "singleColumn",
+      "twoColumn"
+    ],
+    "type": "string"
+  },
+  "printDirectionsButton": {
+    "description": "Print directions. Adds a print control to the directions panel.",
+    "type": "boolean"
+  },
+  "priorityMaxRadius": {
+    "description": "Priority radius. Stops a featured location from being pinned to the top when it is unhelpfully far from the visitor. off = No limit; 25 = Within 25; 50 = Within 50; 100 = Within 100.",
+    "enum": [
+      "off",
+      "25",
+      "50",
+      "100"
+    ],
+    "type": "string"
+  },
+  "radiusChoices": {
+    "description": "Radius options. The distances a visitor can choose from, comma separated, in the units they see. Leave empty for the built-in list. Only applies when showRadiusSelector is true.",
+    "type": "string"
+  },
+  "resetButton": {
+    "description": "Reset control. Gives visitors one control that clears the search and every filter at once.",
+    "type": "boolean"
+  },
+  "resultColumnWidth": {
+    "description": "Result column width. How much of the width the result list takes when it sits beside the map. Only applies when locatorLayout is listLeft or listRight. In %.",
+    "maximum": 75,
+    "minimum": 25,
+    "type": "number"
+  },
+  "resultLoading": {
+    "description": "Loading. Immediate renders everything at once. immediate = Immediate; paged = Load more on scroll.",
+    "enum": [
+      "immediate",
+      "paged"
+    ],
+    "type": "string"
+  },
+  "scrollToStoreOnMarkerClick": {
+    "description": "Scroll to result. Clicking a pin scrolls the matching entry into view and highlights it, instead of only opening a popup. Only applies when locatorLayout is not listOnly or gridOnly.",
+    "type": "boolean"
+  },
+  "searchBehaviour": {
+    "description": "Search mode. Decides whether typing filters your existing list, or moves the map to a place the visitor names. filterText = Filter by text; nearLocation = Search near a place.",
+    "enum": [
+      "filterText",
+      "nearLocation"
+    ],
+    "type": "string"
+  },
+  "searchFields": {
+    "description": "Search fields. Address-only is the familiar store-locator behaviour. Only applies when searchBehaviour is filterText. address = Address only; details = Address plus location details.",
+    "enum": [
+      "address",
+      "details"
+    ],
+    "type": "string"
+  },
+  "searchIcon": {
+    "description": "Search icon. Puts a magnifying glass inside the search box. none = No icon; leading = Magnifying glass.",
+    "enum": [
+      "none",
+      "leading"
+    ],
+    "type": "string"
+  },
+  "searchPlacement": {
+    "description": "Search placement. Choose where visitors see the main search field in the locator. top = Top row; results = Above results; hidden = Hidden.",
+    "enum": [
+      "top",
+      "results",
+      "hidden"
+    ],
+    "type": "string"
+  },
+  "searchZoomBehaviour": {
+    "description": "Search zoom. Fitting all results keeps every match on screen. Only applies when locatorLayout is not listOnly or gridOnly. fitAll = Fit all results on screen; fixed = Use a fixed zoom level.",
+    "enum": [
+      "fitAll",
+      "fixed"
+    ],
+    "type": "string"
+  },
+  "selectedResultEmphasis": {
+    "description": "Selected result. How the result a visitor has chosen is marked out from the rest. Only applies when locatorLayout is not mapOnly. border = Accent border; stripe = Accent stripe; tint = Tinted background.",
+    "enum": [
+      "border",
+      "stripe",
+      "tint"
+    ],
+    "type": "string"
+  },
+  "showFilterCounts": {
+    "description": "Filter counts. Puts the number of matching locations next to each filter.",
+    "type": "boolean"
+  },
+  "showFilterGroupHeadings": {
+    "description": "Filter headings. Labels each filter group by name. Turn off when you only have one group and the heading is redundant.",
+    "type": "boolean"
+  },
+  "showMapByDefault": {
+    "description": "Initial map. Off starts with just the list and a Show map button, which loads faster and suits pages where the list matters more. Only applies when locatorLayout is not listOnly or gridOnly.",
+    "type": "boolean"
+  },
+  "showRadiusSelector": {
+    "description": "Radius filter. Adds a distance dropdown next to the search box. Only applies when searchBehaviour is nearLocation.",
+    "type": "boolean"
+  },
+  "showSearchLocationMarker": {
+    "description": "Search marker. Drops a distinct pin where the visitor searched, so they can see what the distances are measured from. Only applies when searchBehaviour is nearLocation.",
+    "type": "boolean"
+  },
+  "showUnassignedFilters": {
+    "description": "Ungrouped filters. Filters you have not put in a group still appear, under a general heading.",
+    "type": "boolean"
+  },
+  "sortDirection": {
+    "description": "Sort direction. Ascending puts the nearest, or the earliest alphabetically, first. asc = Ascending; desc = Descending.",
+    "enum": [
+      "asc",
+      "desc"
+    ],
+    "type": "string"
+  },
+  "sortField": {
+    "description": "Sort by. Distance needs a search or a visitor location to mean anything. distance = Distance; name = Name; priority = Priority, then name.",
+    "enum": [
+      "distance",
+      "name",
+      "priority"
+    ],
+    "type": "string"
+  },
+  "storeNameLinkBehaviour": {
+    "description": "Location name click. Showing it on the map keeps the visitor inside the widget. showOnMap = Show the location on the map; website = Open the location's website; none = Do nothing.",
+    "enum": [
+      "showOnMap",
+      "website",
+      "none"
+    ],
+    "type": "string"
+  },
+  "storeZoomLevel": {
+    "description": "Location zoom. How far in the map goes when a visitor clicks a single location. Higher is closer. 17 is roughly street level. Only applies when locatorLayout is not listOnly or gridOnly.",
+    "maximum": 22,
+    "minimum": 1,
+    "type": "number"
+  },
+  "updateListOnMapDrag": {
+    "description": "Map move updates. Re-sorts the list to match wherever the visitor has panned the map. Only applies when locatorLayout is not listOnly or gridOnly.",
+    "type": "boolean"
+  },
+  "urlState": {
+    "description": "URL state. Lets a visitor bookmark or share a filtered view, and lets you link straight to one from an ad or email.",
+    "type": "boolean"
+  },
+  "urlStateSearchText": {
+    "description": "Put the visitor's search in the URL. Also writes what a visitor typed into the address bar, so their exact search can be bookmarked or shared. Only applies when urlState is true.",
+    "type": "boolean"
+  },
+  "websiteLinkTarget": {
+    "description": "Website links. A new tab keeps the visitor on your page. Same tab sends them away from the locator entirely. newTab = In a new tab; sameTab = In the same tab.",
+    "enum": [
+      "newTab",
+      "sameTab"
+    ],
+    "type": "string"
+  },
+  "weekBeginsOn": {
+    "description": "Week begins on. Affects the order days are listed in the hours editor and in the widget's opening-hours table. Display only. Hours stay stored the same way, so switching it never changes a location. monday = Monday; sunday = Sunday.",
+    "enum": [
+      "monday",
+      "sunday"
+    ],
+    "type": "string"
+  },
+  "widgetWidth": {
+    "description": "Widget width. Use a percentage to fill the container it is embedded in, or a fixed value like 560px to cap it.",
+    "type": "string"
+  },
+  "wordCapitalization": {
+    "description": "Capitalization. Converts ALL CAPS or all lowercase names, addresses and cities to title case on import.",
+    "type": "boolean"
+  },
+  "zipCodePrefix": {
+    "description": "Postcode prefixes. Automatic restores the leading zeros spreadsheets strip from US ZIP codes, so 01234 does not import as 1234. auto = Automatic; none = Leave as imported.",
+    "enum": [
+      "auto",
+      "none"
+    ],
+    "type": "string"
+  },
+  "zoomMapOnFilterChange": {
+    "description": "Refit map. Zooms the map to the remaining results after a filter is applied, instead of leaving the visitor looking at empty space. Only applies when locatorLayout is not listOnly or gridOnly.",
+    "type": "boolean"
+  }
+}

Changedupdate_location2 fields changed

addedInput schema / properties / ids

Added value: +{
+  "description": "Several location ids, to apply the same change to all of them in one call (at most 200). Use either id or ids.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 200,
+  "type": "array"
+}

removedInput schema / required
```
Removed value: -[
-  "id"
-]
```

1 tool updateSep 16, 2026
- Addedset_tag_style
15 tool updatesSep 10, 2026
- First observedapply_configuration
- First observedcreate_location
- First observeddelete_location
- First observeddescribe_configuration
- First observedfind_nearest_locations
- First observedget_embed_code
- First observedget_location
- First observedlist_configuration_versions
- First observedlist_locations
- First observedlist_tags
- First observedpropose_configuration
- First observedrollback_configuration
- First observedset_custom_field
- First observedtag_locations
- First observedupdate_location

Related MCP Connectors

mcp-serverOAuth
io.github.SavantoAI
Manage your Savanto store from your AI: catalog, content, prompts, and analytics, by chat.
E-commerce & Retail Marketing Content Management Systems
2
muro - Live Chat & AI Support Inbox
chat.muro
Live chat + AI support inbox: list, triage, and reply to customer conversations; configure widgets.
Customer Support AI & Machine Learning
2
EasyWeek BusinessOAuth
io.easyweek
Manage an EasyWeek business from AI: bookings, availability, customers, services, orders, messaging.
Calendar Management CRM
1
Lnk.Bio Official MCP
bio.lnk
Manage your Lnk.Bio page through AI: links, pages, themes, social icons, and more.
Social Media Marketing
2

Related MCP Servers

mcp-google-business
Marketing Social Media
A1-x-Tech
A
license
A
quality
A
maintenance
Enables managing Google Business Profiles through natural language: list locations, reply to reviews, create local posts, and fetch performance metrics.
Updated 10 days ago (2026-09-20 22:36 UTC)
26
250 npm
2
MIT
Voice Logica MCP
AI & Machine Learning Communication App Automation
voicelogica
A
license
Not graded
quality
A
maintenance
Enables managing AI voice agents, phones, integrations, workflows, calls, and billing directly from chat, including editing agent settings, connecting CRMs, and reviewing call logs.
Updated a month ago (2026-08-23 08:00 UTC)
MIT
Google Business Profile MCP
CRM Marketing Customer Support
narkov
F
license
Not graded
quality
D
maintenance
Enables AI assistants to manage Google Business Profiles by creating posts, replying to reviews, listing locations, and more through natural language commands.
Updated 7 months ago (2026-03-13 17:32 UTC)
1
-
Maps MCP App
Location Services Search
russianryebread
F
license
Not graded
quality
C
maintenance
Enables users to search for locations, businesses, and points of interest on an interactive OpenStreetMap map within ChatGPT conversations.
Updated 3 months ago (2026-07-13 17:51 UTC)
-

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?