Skip to main content
Glama

Latchbell

Activate my receptionist plan

receptionist_checkout

Owners only (needs sign-in): Only when the owner explicitly asks to activate the plan: show its monthly price, included usage, overage rates and spending limit from receptionist_service first. With owner_approved true, return a Stripe-hosted checkout URL for the owner to complete. Creating a link does not complete payment, activate phone service or change the spending cap: once the plan is paid, the monthly limit becomes the plan's price (spending_cap_on_payment), so nothing past the price is charged until the owner tops up or raises the cap: tell the owner. plan is the id of one of receptionist_service plans (its name, like pro, works too), or agent for agent_plan (only for a business an AI agent signed up itself with register_business); without it, the plan marked default. An unpaid checkout is dropped with cancel_receptionist_checkout. With a plan already paid, naming another plan switches to it now and returns switched: true (no link): Stripe charges the difference today, or credits it to the next bill for a cheaper plan, and the switch happens only once paid; the cap keeps any room the owner added above the old price, and a plan without a phone line (phone_line false) stops call answering and gives back the number Latchbell provided (released_number; phone.included says whether there is one): tell the owner first. Without a plan named, a paid plan gets the Stripe billing portal link.

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": {
      "owner_approved": "<owner_approved>"
    },
    "name": "receptionist_checkout"
  }
}

Input Schema

NameRequiredDescriptionDefault
planNo
owner_approvedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior1/5

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

The description richly discloses side effects: creating a link does not complete payment or activate service, a paid-plan switch charges or credits the difference, and the cap behavior is explained. However, it also states that switching to a plan with phone_line false stops call answering and releases the Latchbell-provided number, which is a destructive update, while annotations declare destructiveHint=false. This is an annotation contradiction under the rubric.

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 access condition is front-loaded and nearly every clause carries operational meaning, including pricing prerequisites, switching rules, and alternatives. The main weakness is scanability: it is a dense run-on paragraph with many semicolon-separated rules that an agent must parse carefully.

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 two-parameter billing tool with no output schema and only minimal annotations, the description covers the important behavioral context: authentication, the pricing precheck, checkout-link semantics, paid-plan switching, spending-cap effects, and number release. Nothing essential for correct invocation appears to be missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden and does so well. It explains that plan accepts a receptionist_service plan id or name such as pro, or agent for agent_plan in the register_business case, and that omitting plan selects the default; it also explains owner_approved as the gate for returning a checkout URL.

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 specific verbs and resources: it returns a Stripe-hosted checkout URL to activate a receptionist plan, and it explains the immediate-switch behavior when a plan is already paid. It distinguishes itself from cancel_receptionist_checkout and receptionist_billing_portal by naming those alternatives in context.

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 gives explicit usage conditions: owners only, sign-in required, only when the owner explicitly asks to activate the plan, and it says to show price and usage from receptionist_service first. It also names alternatives: cancel_receptionist_checkout for unpaid checkouts and the billing portal when no plan is named.

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