Fuse rooms

Search Fuse rooms

search_rooms

Read-onlyIdempotent

Find furnished, all inclusive Fuse student rooms in Budapest or Riga by city, move in date, highest monthly budget, room type, home type and contract length. Reads the live listing and returns the cheapest matching rooms first, each with its monthly price, when it is free, a photo and its page URL. Read only: it never books, holds, pays, uploads or signs; the booking link is the room's page on fusestays.com, where the student books.

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": {
      "city": "<city>"
    },
    "name": "search_rooms"
  }
}

Input Schema

Name	Required	Description
`city`	Yes	City to search: budapest, riga, or both.
`limit`	No	Most rooms to return, 1 to 25. Default 10.
`move_in`	No	Move in date as yyyy-mm-dd, or yyyy-mm for any start that month. Rooms free now or free by that day match.
`home_type`	No	Kind of home: Flatshare (a shared flat), Coliving (a larger shared house) or Private apartment.
`room_type`	No	Room type as the site names it.
`contract_months`	No	Contract length in months. Shorter contracts cost more a month; without it the 12 month price is used.
`max_monthly_budget_eur`	No	Highest monthly price in EUR, all inclusive (rent, utilities and Wi-Fi).

Output Schema

Name	Required	Description
`more`	Yes	More rooms match than are shown.
`rooms`	Yes	Matching rooms, cheapest first, then the soonest free.
`booking`	Yes	Who can book and how.
`filters`	Yes	The filters the search used.
`message`	Yes	Why the list is empty, or what to do next.
`rooms_url`	Yes	Every room on fusestays.com.
`times_note`	No	How the door to door times are worked out, and the credits their sources ask for.
`data_read_at`	Yes	When this answer was built (ISO time), not when the listing was read: a city in saved_cities comes from the last good read, up to a day old.
`saved_cities`	Yes	Cities whose rooms, or some of their details, come from the last good read, up to a day old, because the live listing did not fully answer just now: whether a room is free, or a detail, may have changed.
`failed_cities`	Yes	Cities whose room list could not be read just now: they may well have rooms. Try again in a few minutes.

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 already declare readOnlyHint, idempotentHint and destructiveHint=false, so the "Read only" sentence is largely redundant. The description does add genuinely new behavior: results are sorted cheapest-first, and each result carries price, availability date, photo and URL, plus an explicit statement that it never books, holds or pays.

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?

Three sentences, search scope front-loaded, then result shape, then safety/booking boundary. Efficient, though the read-only clause partly repeats what the annotations already assert and could be trimmed.

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 filtered read-only search with a full output schema, this covers everything an agent needs: what is searched, what filters exist, what comes back, ordering, and that no write or booking action occurs. No material gap remains.

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%, so all seven parameters are already documented with enums, ranges and the contract-length pricing note. The description enumerates the same filter dimensions and adds only the "all inclusive" framing, which is already in the budget parameter's schema text. Baseline 3 applies.

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 ("Find ... Fuse student rooms") plus the exact filter dimensions and the two supported cities, so an agent can distinguish it from get_room_details or get_prices_and_availability without opening a schema.

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

Usage Guidelines3/5

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

The description makes the search intent explicit and redirects booking intent ("the booking link is the room's page on fusestays.com"), but it never names a sibling tool or states a condition for preferring get_room_details or get_prices_and_availability. Usage is implied rather than routed.

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

All Fuse rooms 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?