Botpass Labs

Book Meeting Tool

book_meeting

Request a meeting with this company. First call with the user's details: you get a summary and a privacy notice to show them. Only after they confirm, call again with confirm_token to send it.

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": "book_meeting"
  }
}

Input Schema

Name	Required	Description
`name`	No	Full name of the user. Required.
`email`	No	Email to reply to. Required.
`phone`	No	Phone number, with country code if possible.
`company`	No	The user's company.
`message`	No	What the user wants, in their words.
`offer_id`	No	Optional. Id of the catalogue item the request is about (a flat to visit, a car to test drive, a product), as returned by search_offers. Omit for general requests.
`confirm_token`	No	Only on the second call, after the user confirmed the summary.
`preferred_time`	No	When the user would like the meeting, in their words.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations carry only a title, so the description does the behavioral work: it discloses that the first call does not send anything but instead returns a summary and privacy notice to show the user, and that transmission happens only on the confirmed second call. It stops short of stating permissions, failure modes, or whether a request can be cancelled or amended.

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?

Three short sentences with the action front-loaded and the protocol in execution order. Nothing is repeated from the schema and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With eight parameters, no annotations, and no output schema, the description covers the critical draft-then-confirm protocol but leaves the outcome of the second call unstated, so an agent does not know whether it returns a booking reference, a status, or nothing. Adequate for calling the tool correctly, incomplete for understanding the result.

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 100%, so the baseline is 3, but the description earns a step up by assigning parameters to phases, making clear that confirm_token is the switch between draft and send. It still does not clarify which details are mandatory in practice, notably that required_parameters is empty despite name and email being labeled required in the schema.

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?

Names a specific verb and resource ("Request a meeting with this company") and frames a two-call protocol that no sibling shares. It does not explicitly distinguish itself from the similarly named request_contact or request_audit, so the sibling differentiation is only implied.

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

Usage Guidelines4/5

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

Gives an unusually explicit sequencing rule: first call with the user's details, then a second call with confirm_token only after the user confirms. That is strong when-to-call guidance for the two phases, though it never states which of the neighboring request/* tools to prefer over this one.

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

All Botpass Labs 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?