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

posterly-mcp-server

by awpthorp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

manage_google_business_location

DestructiveIdempotent

Update a Google Business location's regular opening hours or attributes using a preview-then-confirm flow; changes apply only after confirmation and when location edits are enabled.

Instructions

Change regular opening hours or attributes on a Google Business location. action=update_hours sends regular_hours.periods with open_day, close_day, open_time, and close_time as HH:MM. action=update_attributes sends attributes with a name like attributes/has_wifi and value_type BOOL, URL, or ENUM. Both use 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. Stays off until location edits are switched on. A confirm while it is off changes nothing and does not call Google. This uses the same business management connection as posting. It does not change the business name, address, phone, or website.

Input Schema

NameRequiredDescriptionDefault
actionYesupdate_hours or update_attributes.
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.
attributesNoupdate_attributes: attributes to set. URL values must be https. Names look like attributes/has_wifi.
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.
workspace_idNoFilter to a workspace ID from whoami.
regular_hoursNoupdate_hours: opening periods. Days are MONDAY-SUNDAY. Times are HH:MM.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.55.1

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare destructive, non-read-only, idempotent and open-world, but the description carries far more: a mandatory preview-then-confirm gate, the fact that confirming while the feature is off is a silent no-op that never calls Google, and that the same business management connection used for posting is reused. That is exactly the behavior an agent cannot infer from the annotation flags.

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 purpose, then per-action payload formats, then the preview/confirm workflow, then the gating condition and scope exclusions. Every sentence carries operational information; none restates the tool name or the annotations.

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 an 8-parameter, nested-object, destructive mutation with no output schema, the description covers the workflow, preconditions, side effects, and the boundaries of what is mutated. An agent has enough to call both actions correctly and to know when a call will be inert.

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, but the description adds real semantic detail: HH:MM time format, MONDAY-SUNDAY day names, and attribute naming/value_type conventions (attributes/has_wifi, BOOL/URL/ENUM). It does not clarify account_id versus location_id precedence or the workspace_id filter, leaving those to the schema text.

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 ("Change regular opening hours or attributes on a Google Business location") and enumerates the two supported actions by name. It also closes the scope explicitly ("does not change the business name, address, phone, or website"), which separates it from broader location-management siblings.

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?

Gives per-action routing (update_hours sends regular_hours.periods, update_attributes sends attributes), an explicit two-step procedure (call without confirm for a preview_id, show it, then confirm), and a hard precondition ("Stays off until location edits are switched on"). It also states what happens when the precondition is unmet, so an agent knows the failure mode in advance.

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