Car Rental Brain

Build search link

build_search_link

Read-onlyIdempotent

A link for the PERSON to open: live prices for their exact dates and needs, ranked by the total they will actually pay, where they can book. Use whenever the person has dates and wants to see or book cars. Works for any place; coverage says whether Car Rental Brain has measured it (not_measured: no figures of ours exist there - say so, quote none).

Input Schema

Name	Required	Description
`age`	No	Main driver's age in years (default 35). Under 25 or over 70 often costs more.
`place`	No	Any city/place if not a measured airport
`airport`	No	Airport id, IATA code or name, e.g. 'faro', 'FAO', 'Faro Airport'
`car_type`	No	Car size; omit for every size.
`currency`	No	EUR, GBP, USD...
`automatic`	No	True for automatic gearbox only.
`residence`	No	Two-letter country of residence, e.g. GB
`debit_card`	No	True if the driver has no credit card - only cars whose desk takes a debit card for the deposit.
`pickup_date`	No	YYYY-MM-DD
`pickup_time`	No	HH:MM
`dropoff_date`	No	YYYY-MM-DD
`dropoff_time`	No	HH:MM
`extra_driver`	No	True if a second driver will drive - their fee is then in every total.

Output Schema

Name	Required	Description	Default
`url`	No
`note`	No
`error`	No
`coverage`	No
`disclosure`	No
`attribution`	No
`search_link`	No
`coverage_note`	No
`about_the_link`	No
`measured_as_of`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 3, 2026

addedOutput schema / properties / coverage

Added value: +{
+  "enum": [
+    "measured",
+    "not_measured"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / coverage_note
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / properties / measured_as_of / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

Changed4 schema fields changedOct 24, 2026
- addedOutput schema / properties / attribution
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / disclosure
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / measured_as_of
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / url
```
Added value: +{
+  "type": "string"
+}
```

Changed7 schema fields changedOct 22, 2026

addedInput schema / properties / age / description

Added value: +"Main driver's age in years (default 35). Under 25 or over 70 often costs more."

addedInput schema / properties / age / maximum
```
Added value: +99
```
addedInput schema / properties / age / minimum
```
Added value: +18
```
addedInput schema / properties / automatic / description
```
Added value: +"True for automatic gearbox only."
```
addedInput schema / properties / car_type / description
```
Added value: +"Car size; omit for every size."
```

addedInput schema / properties / debit_card / description

Added value: +"True if the driver has no credit card - only cars whose desk takes a debit card for the deposit."

addedInput schema / properties / extra_driver / description

Added value: +"True if a second driver will drive - their fee is then in every total."

First observedOct 19, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behavioral context: results are ranked by total payable price, the link is for the end user rather than the agent, and coverage can be not_measured with an explicit instruction to withhold figures. It stops short of describing what the link or response object contains, though the output schema covers that.

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 core purpose is front-loaded in the first clause, and the coverage caveat is placed last where it belongs. It is a dense, slightly run-on sentence or two, but every clause carries information and none repeats the annotations or schema.

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 13-parameter tool with full schema coverage, an output schema, and complete annotations, the description supplies the missing pieces an agent needs: who the link is for, how results are ranked, and how to handle unmeasured places. Nothing required to call it correctly is absent.

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 description coverage is 100%, including the age surcharge note, the debit_card deposit rule, and the extra_driver fee inclusion, so the schema already carries the parameter meaning. The description only gestures at "their exact dates and needs" without adding anything the schema does not already say; baseline 3 applies when the schema does the heavy lifting.

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?

The description names the concrete artifact ("A link for the PERSON to open") and the ranking rule behind it ("ranked by the total they will actually pay, where they can book"), which is far more specific than the title. It implicitly distinguishes itself from informational siblings like airport_costs and compare_airports by producing a bookable link, but it never names or contrasts those siblings explicitly.

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?

"Use whenever the person has dates and wants to see or book cars" gives a clear triggering condition, and the coverage clause tells the agent what to do when data is missing (not_measured: say so, quote none). There is no explicit when-not-to-use or named alternative for cases where the person has no dates or only wants cost figures.

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

All Car Rental Brain 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.