Latchbell

Register a business an agent runs

register_business

For an AI agent creating a business it runs, its own or its user's, to get a phone line for calls on the Agent plan, with an email inbox it or its user reads. The business can be a simple individual account: just a name, for calls. The Agent plan is mainly for simple calling and texting: a business that answers its customers through Latchbell gets more for its money on a regular plan, chosen at checkout (receptionist_checkout with a plan from receptionist_service). Not for a business that already has a Latchbell account: it switches its own account to a plan with calls (receptionist_checkout). Steps: https://latchbell.com/agent_plan_skill.md. Emails a 6-digit code to email; nothing is created until confirm_business_email gets it. agree_terms true accepts Latchbell's Terms and Privacy Policy for the business. One business per email.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "business": "<business>",
      "owner": "<owner>",
      "email": "<email>",
      "zip": "<zip>",
      "agree_terms": "<agree_terms>"
    },
    "name": "register_business"
  }
}

Input Schema

Name	Required	Description
`tz`	No	IANA time zone; from the ZIP when not given
`zip`	Yes	5-digit US ZIP code
`kind`	No	What kind of business (services when not given)
`email`	Yes	An inbox this agent reads, or its user’s (they tell it the code): the code goes here, and later Latchbell’s mail
`owner`	Yes	Who runs it: a person’s name or the agent’s own
`phone`	No	Optional mobile where Latchbell can reach whoever runs it
`listed`	No	true to list the business in find_businesses, where other assistants look for businesses, once it is live. Off by default: leave it off for a phone line for you or your user. Change it later with update_business listed.
`business`	Yes	Business name, or a person’s own name for an individual account
`agree_terms`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Beyond the annotations (which only declare non-read-only, non-destructive, open-world), the description discloses the deferred-creation flow: a 6-digit code is emailed and nothing is created until confirm_business_email receives it, plus the 'one business per email' constraint and that agree_terms=true accepts the Terms and Privacy Policy. It stops short of saying what the call returns on success or what happens when the email is already registered.

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 content is dense and mostly load-bearing, but the opening sentence is convoluted and hard to parse, and the individual-account case ('just a name, for calls') is stated twice in slightly different words. The step-link and constraints are useful, yet the piece reads as a compressed paragraph rather than front-loaded, scannable guidance.

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 9-parameter mutation tool with no output schema, the description covers the critical lifecycle (code email, confirm step, terms acceptance, one-per-email) and routes the agent to the right sibling tools. It does not describe the response of a successful call or error conditions such as a duplicate email, which an agent would want before invoking.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 89%, so the baseline is 3, but the description adds meaning the schema does not: agree_terms has no schema description and the text explains that true accepts Latchbell's Terms and Privacy Policy, and 'one business per email' clarifies the email parameter's uniqueness constraint. The listed/plan tradeoff is largely duplicated from the schema, limiting it to a 4.

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 identifies the action (creating/registering a business run by an agent) and its purpose (a phone line on the Agent plan plus an email inbox), and it distinguishes the case from a business that already has an account or wants a fuller plan. The opening 'For an AI agent creating a business it runs, its own or its user's, to get a phone line...' is grammatically tangled and never states the verb directly, so an agent must parse a purpose clause rather than read a clean statement of what the tool does.

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

Usage Guidelines5/5

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

It names explicit alternatives and the conditions that select them: a business answering customers through Latchbell should use receptionist_checkout with a plan from receptionist_service, and a business that already has a Latchbell account should switch its own account via receptionist_checkout rather than registering here. It also scopes the tool to simple calling/texting and points to the step-by-step doc URL, leaving little to inference.

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

All Latchbell tools Inspect

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?