Latchbell

Save notes for customers

set_customer_notes

Owners only (needs sign-in): Use when the owner wants to tell their AI agent and AI assistants what to say to customers, for example closed days, policies or what's included. Replace the business's notes for customers: policies and what's included (supplies, pets, access, parking, what isn't done). Assistants answer customers' questions before booking from these notes, and the owner edits them in the Latchbell dashboard. Pass the whole new text (up to 2000 characters): read the current notes in my_business first and keep what still applies. Save only what the owner told you, and show them the new notes before saving.

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": {
      "notes": "<notes>"
    },
    "name": "set_customer_notes"
  }
}

Input Schema

Name	Required	Description	Default
`notes`	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 it discloses that this is owner-only and requires sign-in, that the operation replaces the entire notes text rather than appending, the 2000-character ceiling, and a data-provenance constraint ('Save only what the owner told you'). It also explains the downstream effect that assistants answer customer questions from these notes, which is not inferable from destructiveHint=false.

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 access constraint is correctly front-loaded, but the middle repeats itself ('closed days, policies or what's included' then 'policies and what's included (supplies, pets, access, parking...)'), and 'AI agent and AI assistants' is redundant. Tighter phrasing would preserve all the substance.

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 one-parameter write tool with no output schema, the definition covers authorization, replacement semantics, length limits, and the read-then-write workflow. It does not say what is returned on success or how errors (e.g. over-length text) surface, a minor gap given no output schema exists.

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 0%, so the description carries the burden and does: it defines the single parameter as the whole new text, restates the 2000-character limit, and adds the crucial semantics that the value overwrites prior content. It does not specify formatting expectations (plain text vs markdown), which keeps it short of a 5.

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 ('Replace the business's notes for customers') and enumerates the content domain (policies, what's included, supplies, pets, access, parking). It also contrasts implicitly with the sibling my_business, which is named as the read path for the current notes.

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 an explicit trigger ('Use when the owner wants to tell their AI agent and AI assistants what to say to customers'), names the alternative read tool my_business, and prescribes the sequence: read current notes first, keep what still applies, show the owner the new notes before saving.

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?