Skip to main content
Glama

Latchbell

Update my business details

update_business

Owners only (needs sign-in): Change the business’s name, the owner’s name, the owner’s mobile (where Latchbell reaches the owner; customers never see it), the business’s ZIP code or its service_area (the cities or areas it works in, in the owner’s words, e.g. "San Francisco, San Jose and Austin": what its AI receptionist tells customers who ask where it works). For an account an AI agent registered, listed sets whether find_businesses lists it. Only the fields given change, at once, except a new mobile: it waits for the owner’s OK in their dashboard (waiting_for_owner), since Latchbell reaches the owner there. The sign-in email changes only through support. Read my_business first.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "update_business"
  }
}

Input Schema

NameRequiredDescriptionDefault
zipNo
ownerNoThe owner’s name
phoneNoThe owner’s mobile, with area code
listedNoOnly for an account an AI agent signed up itself: true lists it in find_businesses once live, false takes it out
businessNo
service_areaNoThe cities or areas the business serves, in the owner’s words

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The annotations only give a vague safety profile (not read-only, non-destructive). The description reveals what they do not: it is a partial update ('Only the fields given change, at once'), and a new mobile is not applied immediately but enters a pending waiting_for_owner state that requires the owner's approval in the dashboard. It also flags the auth requirement and an immutable field.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The critical constraints are front-loaded (owners only, read first), but the body is one dense paragraph of stacked parentheticals that takes effort to parse. Nearly every clause carries unique information, so nothing is padding, but the structure could use a clear listing of per-field rules instead of the run-on sentence.

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?

Though all six parameters are optional, the description covers authorization, partial-update semantics, the asynchronous mobile-verification side effect, an immutable field, and a conditional field's scope. With no output schema and non-destructive annotations, these are exactly the gaps the description needs to fill, and it does.

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 67%, and the description adds real meaning for the ambiguous fields: 'phone' is the owner's private mobile that customers never see, 'service_area' is free-text in the owner's own words and is what the AI receptionist tells customers, and 'listed' applies only to agent-registered accounts and feeds find_businesses. It does not clarify the zip/business constraints (maxLength 5/100) beyond the schema, but the non-obvious parameters are well served.

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?

Names a specific verb and resource (update the business) and enumerates exactly which fields it can change: business name, owner name, owner mobile, ZIP, service_area, and listed. It also separates itself from the read sibling by ending with 'Read my_business first.'

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?

States who may call it ('Owners only (needs sign-in)'), the prerequisite ordering ('Read my_business first'), and an explicit exclusion with a routing alternative ('The sign-in email changes only through support'). It also bounds the 'listed' parameter to agent-registered accounts, so the agent knows when not to use it.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources