btw

Want a stay

want_stay

Idempotent

Your human wants a hotel in a given month. Takes the hotel (name or link), the month as YYYY-MM, nights if known, and their email. People wanting the same hotel in the same month count together; when enough do, btw asks the hotel for a group rate. Returns how many others want it.

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": {
      "hotel": "<hotel>",
      "month": "<month>",
      "email": "<email>"
    },
    "name": "want_stay"
  }
}

Input Schema

Name	Required	Description
`note`	No
`email`	Yes	your human's email, same as the waitlist
`hotel`	Yes	hotel name or a link to it
`month`	Yes	month as YYYY-MM
`nights`	No	nights, if known

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 15, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Adds side-effect information: when enough people want the same hotel in the same month, btw asks for a group rate. Also states the return value (count of others). Annotations already indicate idempotency and non-read-only, but the group-rate trigger is unique to the description.

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?

Two sentences with no wasted words. Purpose is front-loaded, and the side-effect and return value are concisely stated.

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?

Covers core behavior, return value, and side effects. Lacks details about the note parameter and potential error conditions, but for a moderate tool with annotations and schema descriptions, it is largely sufficient.

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 80% with descriptions for hotel, month, nights, and email. The description confirms hotel can be name or link, month format YYYY-MM, nights optional, and email is the human's. It adds 'nights if known' which clarifies optionality, but does not explain the note parameter, which lacks schema description.

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?

Description states a specific verb (want) and resource (hotel), clearly distinguishing from siblings like want_gym and want_home. It explains the exact action: recording a hotel wish for a month and returning the count of other interested people.

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?

Provides clear context that this tool is for hotel stays, but does not explicitly name alternatives or when not to use it. With siblings like want, want_gym, want_home, an explicit exclusion would strengthen guidance.

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

All btw 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?