Latchbell

Top up AI credits

receptionist_top_up

Owners only (needs sign-in): When the owner asks for more AI credits, or receptionist_service shows ai.can_spend false: tell them the packs and prices in ai.top_ups first. With owner_approved true, returns a Stripe-hosted checkout link to pay once; creating it charges nothing. Never ask for or type card details. Credits count once Stripe confirms (receptionist_refresh). For call minutes only, receptionist_buy_minutes. Details: https://latchbell.com/docs/billing.md.

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

Input Schema

Name	Required	Description	Default
`credits`	Yes
`owner_approved`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations (non-read-only, open-world, non-destructive), it discloses that the call creates a Stripe-hosted checkout link, charges nothing at creation, that credits post only after Stripe confirms, and that card details must never be typed. That is exactly the extra context the annotations cannot convey.

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-loaded with the access constraint, then triggers, then behavior, then safety warning, then alternatives. Every sentence adds a distinct operational fact; nothing is redundant.

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 two-parameter mutation with no output schema, the description covers return value (checkout link), cost behavior, confirmation flow, and safety rules. The remaining gap is the meaning/units of the credits integer and any edge cases, which keeps it from top marks.

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

Parameters3/5

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

Schema coverage is 0%, so the description must carry both parameters. It explains owner_approved well ('With owner_approved true, returns a Stripe-hosted checkout link') but leaves 'credits' underspecified — no units, whether the value comes from a named pack in ai.top_ups, or allowable ranges. Partial compensation only.

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 states a specific verb ('top up'), an explicit resource ('AI credits'), and an access constraint ('Owners only'). It also names the sibling it is not ('For call minutes only, receptionist_buy_minutes'), so an agent can route without opening other schemas.

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 two explicit trigger conditions (owner asks for credits, or receptionist_service shows ai.can_spend false), a required prerequisite (owner sign-in), a recommended pre-step (tell them packs/prices from ai.top_ups), and the alternative for a different need (receptionist_buy_minutes). Little is left 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?