Bota — car rental availability and bookings

Provide driver details

provide_customer_details

Submits the driver's details for the booking in progress and returns the booking summary with its confirmation_token. terms_accepted records that the customer accepted the company's terms and must be true.

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": {
      "company_id": "<company_id>",
      "session_id": "<session_id>",
      "first_name": "<first_name>",
      "last_name": "<last_name>",
      "email": "<email>",
      "terms_accepted": "<terms_accepted>"
    },
    "name": "provide_customer_details"
  }
}

Input Schema

Name	Required	Description
`email`	Yes
`notes`	No
`phone`	No	With country code (+1…). Required by most companies.
`language`	No	Language of the conversation, BCP-47 (es, en, pt-BR, fr, de, it…). Defaults to 'en'. Bota also answers in the language the customer writes.
`last_name`	Yes
`company_id`	Yes	Rental company id.
`first_name`	Yes
`references`	No	Only for a company where the person has a negotiated agreement and that asks for booking references: the claim or file number, cost center or purchase order and agency reference the customer gives, exactly as given. If one it requires is missing, this tool fails with references_required naming it.
`session_id`	Yes	Booking session id returned by a previous call for this company (offers, selection, customer details). Omitted, a new session starts.
`flight_number`	No
`terms_accepted`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 4, 2026

addedInput schema / properties / references

Added value: +{
+  "additionalProperties": false,
+  "description": "Only for a company where the person has a negotiated agreement and that asks for booking references: the claim or file number, cost center or purchase order and agency reference the customer gives, exactly as given. If one it requires is missing, this tool fails with references_required naming it.",
+  "properties": {
+    "agency_ref": {
+      "maxLength": 60,
+      "type": "string"
+    },
+    "claim": {
+      "maxLength": 60,
+      "type": "string"
+    },
+    "cost_center": {
+      "maxLength": 60,
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changed3 schema fields changedOct 22, 2026

changedInput schema / properties / company_id / description

Previous value: -"Company id from list_rental_companies."New value: +"Rental company id."

changedInput schema / properties / phone / description

Previous value: -"With country code (+1…). Most companies require it: ask the customer for it before calling, never make one up."New value: +"With country code (+1…). Required by most companies."

changedInput schema / properties / session_id / description

Previous value: -"Session id returned by a previous call for this company. Omit on the first call; ALWAYS pass it back on the next ones so Bota keeps the conversation (offers, selection, customer details)."New value: +"Booking session id returned by a previous call for this company (offers, selection, customer details). Omitted, a new session starts."

Changed1 schema field changedOct 21, 2026

addedInput schema / properties / phone / description

Added value: +"With country code (+1…). Most companies require it: ask the customer for it before calling, never make one up."

First observedSep 11, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare this is a non-read-only, non-destructive, open-world write. The description adds useful behavior beyond them: it returns a booking summary containing a confirmation_token, and it flags that terms_accepted is a mandatory true value. It says nothing about failure modes or side effects (the references_required failure lives only in the schema), so there is real room left.

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?

Two sentences, front-loaded with the action and outcome, with no filler. The precondition sentence could have been folded in more tightly, but nothing is wasted.

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?

For a mutation tool with no output schema, the description does the important work of stating the return value and the confirmation_token. But it omits the failure behavior (notably the references_required case) and any placement in the booking flow, which an agent needs to sequence this call correctly against confirm_booking.

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?

With 45% schema coverage across 11 parameters, the description carries only a small part of the burden: it explains terms_accepted, which has no schema description and is a non-obvious mandatory boolean. The other undescribed fields (first_name, last_name, email, notes, flight_number) are largely self-evident, and the tricky ones (session_id, references, phone, language) are documented in the schema, so the gap is modest.

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: submits the driver's details for the booking in progress, and states what comes back (booking summary with confirmation_token). It implicitly separates itself from confirm_booking by describing the booking as still 'in progress', but it never names or contrasts a sibling, so the differentiation is left to inference.

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance, no ordering relative to select_offer or confirm_booking, and no statement of when not to call it. The only usage constraint given is that terms_accepted must be true, which is a precondition rather than routing guidance.

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

All Bota — car rental availability and bookings 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?