Skip to main content
Glama
Sign In
posterly-mcp-server

posterly-mcp-server

by awpthorp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

manage_google_business_service_area

Idempotent

Replace a Google Business location's service areas with a 1–20 place list, using a preview and confirmation flow to review and save changes.

Instructions

Replace the service areas on a Google Business location. action=update sends the full list (1 to 20 places, each with place_id and place_name from list_google_business_service_areas view=places or a known region Place ID). business_type is CUSTOMER_AND_BUSINESS_LOCATION (customers can visit, and you also travel) or CUSTOMER_LOCATION_ONLY (you only travel to customers). CUSTOMER_LOCATION_ONLY needs region_code when Google has not set one, and clear_storefront_address=true when a street address is still on the listing. The country cannot be changed once set. Preview then confirm: call without confirm to get a preview and preview_id, show it, then call again with confirm=true and that preview_id. Saving the same list again is safe.

Input Schema

NameRequiredDescriptionDefault
actionYesupdate: replace the service area list.
placesNoThe full replacement list, 1 to 20 areas. Each item needs place_id and place_name.
confirmNoLeave out to get a preview; true only with the preview_id after the user approved it.
account_idNoGoogle Business account ID from list_accounts.
preview_idNoThe preview_id from the preview call. Required with confirm: true.
location_idNoGoogle Business numeric location id (the location_id/platform_user_id from list_accounts, e.g. "197940849675145390"). NOT the ChIJ... Place ID from list_google_business_reviews view=review_link. Prefer account_id.
region_codeNoTwo-letter country code. Required for customer-only listings that do not already have one. Immutable once set.
workspace_idNo
business_typeNoCUSTOMER_LOCATION_ONLY travels to customers. CUSTOMER_AND_BUSINESS_LOCATION also has a storefront.
clear_storefront_addressNoSet true only when switching to customer-only. Google requires the street address to be removed from the listing in the same update; it is not kept, so adding it back means entering it again.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.55.1

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations (which only flag non-read-only, idempotent, non-destructive, open-world) by disclosing full-replacement semantics, the 1-20 item cap, that the country is immutable once set, that clear_storefront_address deletes the street address so it must be re-entered, and the two-step preview/confirm safety flow. It even restates why repeated saves are safe, which contextualizes the idempotentHint.

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?

Front-loaded with the action and scope, then conditions, then the safety flow; nearly every clause carries operational information. It is dense and slightly long, but no sentence is redundant with the schema.

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 10-parameter mutation with no output schema, it covers the risky parts well: replacement semantics, immutable country, required region_code, address clearing, and the preview/confirm loop. Minor gaps remain, such as what the preview actually shows and how conflicts with existing areas are resolved.

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 already 90%, so the baseline is 3; the description adds real meaning on top by translating business_type into plain business consequences (travel-only vs. also having a storefront) and explaining when region_code and clear_storefront_address are mandatory. It does not add anything for account_id/workspace_id/location_id, but the schema already disambiguates those.

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?

Opens with a specific verb+resource+scope: 'Replace the service areas on a Google Business location.' It also implicitly distinguishes itself from the sibling list_google_business_service_areas, which it names as the source of place_id/place_name values.

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?

Gives a clear when-to-use path: action=update, preview first without confirm, then re-call with confirm=true and the preview_id. It also states the conditions that require region_code and clear_storefront_address. It stops short of explicitly naming the neighboring manage_google_business_location tool or stating when this tool should not be used.

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

Deploy Server

Other Tools