Model Context Protocol (MCP) server for the Hostaway PMS — connect Claude to your vacation rental ops.
@prosperkartik/hostaway-mcp connects Claude (in Claude Code, Claude Desktop, or any MCP-compatible client) to your Hostaway account — listings, reservations, calendar availability, guest messaging, and financials. Authored by an engineer who has integrated Hostaway, Ciirus, and major OTA APIs (Airbnb, VRBO, Booking.com, Expedia, Marriott) in production for short-term rental operators since 2022.
Hostaway is a trademark of Hostaway Inc. This project is community-built and not affiliated with or endorsed by Hostaway.
Three reasons:
Tool coverage. 10 read-only tools across listings, reservations, calendar, conversations, financials, and a health-check — broader surface than other community MCP servers in this space.
Cleaner auth UX. Takes the two credentials Hostaway gives you on the API settings page — Account ID + API Key — and handles the OAuth token exchange internally. No "go generate a bearer token elsewhere first" step.
Built by someone who works the API. The author has 3+ years of production Hostaway / Ciirus integration work behind the design decisions. Tools map to real operator workflows, not just REST endpoints.
Related MCP server: Lodgify MCP Server
All v0.1 tools are read-only. Write operations are coming in later versions, gated behind explicit confirmation.
Tool | Description |
| Health-check — returns connected account counts (listings, reservations, conversations, owner statements, users). Run this first to confirm setup works. |
| List properties on the account |
| Full detail for a single listing — location, capacity, pricing, reputation, channel URLs |
| List reservations, with optional filters by arrival date range and status |
| Full detail for a single reservation — guest, dates, pricing, channel |
| Per-day availability for a listing across a date range — answers "is property X free between A and B?" |
| List guest message threads with unread state and last activity |
| Only conversations with unread guest messages — answers "who's waiting on a reply?" |
| Full message history of a single conversation |
| List owner financial statements |
In your Hostaway operator account → Settings → Hostaway API. Generate API credentials. You'll get an Account ID and an API Key.
claude mcp add hostaway \
--scope user \
-e HOSTAWAY_ACCOUNT_ID=your-account-id \
-e HOSTAWAY_API_KEY=your-api-key \
-- npx -y @prosperkartik/hostaway-mcp(Or use --scope local to install for the current project only.)
Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) and add:
{
"mcpServers": {
"hostaway": {
"command": "npx",
"args": ["-y", "@prosperkartik/hostaway-mcp"],
"env": {
"HOSTAWAY_ACCOUNT_ID": "your-account-id",
"HOSTAWAY_API_KEY": "your-api-key"
}
}
}
}Restart Claude Desktop. The Hostaway tools appear in the tools picker.
Ask Claude things like:
"Run whoami to confirm Hostaway is connected."
"List my Hostaway listings."
"What reservations are checking in next week?"
"Is listing 12345 available May 10–17?"
"Do I have any unread guest messages?"
"Show me the conversation with [guest]."
> List my Hostaway listings.
Found 3 listings:
| ID | Name | Location | Beds | Baths | Capacity | Status |
|-------|-------------------|-------------------|------|-------|----------|--------|
| 10001 | Sample Apt 2BR | Sample City, US | 2 | 2 | 4 | active |
| 10002 | Sample Loft | Sample City, US | 1 | 1 | 2 | active |
| 10003 | Sample Beachfront | Sample Beach, US | 3 | 2 | 6 | active |> Is listing 10001 available May 10–17?
# Calendar for listing 10001
8 days returned (2026-05-10 → 2026-05-17) · 6 available, 2 reserved, 0 blocked
| Date | Available | Status | Price | Min stay | Reserved | Blocked | Note |
|------------|-----------|----------|-------|----------|----------|---------|------|
| 2026-05-10 | ✓ | available| 220 | 2 | 0 | 0 | |
| 2026-05-11 | ✓ | available| 220 | 2 | 0 | 0 | |
| 2026-05-12 | ✗ | reserved | 220 | 2 | 1 | 0 | |
| ... |Env var | Required | Description |
| yes | Your Hostaway account ID (acts as OAuth |
| yes | Your Hostaway API secret (acts as OAuth |
The server exchanges those for a bearer token at startup and caches it in memory for the lifetime of the process.
git clone https://github.com/prosperkartik/hostaway-mcp.git
cd hostaway-mcp
npm install
cp .env.example .env # fill in credentials
npm run build
npm startHot-reload via tsx:
npm run devv0.1 — 10 read-only tools across listings, reservations, calendar, conversations, financials, and health-check
v0.2 — Tasks (list_tasks, get_task); Cancellation policies; Custom fields read
v0.3 — Guest payments read; Webhooks read
v0.4+ — Write operations (send guest messages, update calendar blocks, create tasks) gated behind explicit confirm: true
Have a request? Open an issue or start a discussion.
Credentials live in environment variables only — never written to disk by this server
The bearer token lives in process memory; no persistent storage
v0.1 is read-only end-to-end; nothing in this codebase can mutate Hostaway data
For multi-property operators: the Hostaway API returns data scoped to the account whose credentials you supply, so cross-account access is not possible
Issues and PRs welcome. The codebase is small and easy to read; start at src/index.ts.
MIT — see LICENSE.
Built by Kartik Vats (@prosperkartik) — AI engineer at Kodeit. Three years of production work on PMS / OTA integrations and LLM tooling.
If you're a vacation rental operator or hospitality tech team and want help wiring AI into your ops, get in touch via kodeit.io or email prosperkartik@gmail.com.
Fetch the full message history of a single conversation by id. Returns each message with direction (incoming/outgoing), timestamp, and body.
| Name | Required | Description | Default |
|---|---|---|---|
| conversation_id | Yes | The numeric Hostaway conversation id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the tool returns messages with direction, timestamp, and body, but lacks details on potential pagination, ordering, or limits. Since no annotations are provided, the description partially fulfills the behavioral disclosure burden but is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no extraneous information. It front-loads the action and resource, making it efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single required parameter and lack of output schema, the description adequately explains the return fields. However, it misses behavioral details such as pagination, maximum message count, or error scenarios, which reduces completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, and the description does not add meaning beyond the schema's description of conversation_id. The schema already adequately describes the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches the full message history of a single conversation by ID, specifying the return fields (direction, timestamp, body). This distinguishes it from sibling tools like list_conversations and list_unread_conversations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving detailed conversation messages, but does not explicitly state when to use this tool versus alternatives like list_conversations or list_unread_conversations. There are no exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full details for a single Hostaway listing by id. Returns location, capacity, pricing, reputation, and channel URLs as Markdown sections.
| Name | Required | Description | Default |
|---|---|---|---|
| listing_id | Yes | The numeric Hostaway listing id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses a key behavioral trait: returns data as Markdown sections. It does not state read-only nature or auth needs, but for a GET operation this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences cover purpose, resource, and return format with no redundancy. Efficiently front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 param, no output schema), the description adequately conveys what the tool does and returns. Lacks only minimal extras like output format details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter, which already explains it. The description does not add new semantic value beyond the schema, earning baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Fetch full details for a single Hostaway listing by id', providing a clear verb and resource. It distinguishes from siblings like list_listings by specifying 'full details' and listing specific fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by detailing the returned data (location, capacity, etc.), but lacks explicit when-to-use vs alternatives or exclusions. The sibling list_listings suggests this is for a single detailed view.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full details for a single Hostaway reservation by id. Returns guest info, dates, pricing breakdown, and channel details.
| Name | Required | Description | Default |
|---|---|---|---|
| reservation_id | Yes | The numeric Hostaway reservation id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description should disclose read-only nature, error handling, or required permissions. It only mentions returns, not side effects or failure modes. Minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, directly states purpose and key return attributes. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch tool with no output schema, it lists return fields. Missing error handling or edge case notes, but sufficiently complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter, including a clear description. The description adds no extra meaning beyond 'by id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it fetches full details for a single reservation by id, and specifies exact components returned (guest info, dates, pricing, channel details). Distinct from sibling listing tools like list_reservations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage: use when you need full detail for a specific reservation. No explicit when-not or alternative tools mentioned, despite siblings like list_reservations providing contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the availability calendar for a single listing across a date range. Returns per-day availability, status, price, minimum stay, and reserved/blocked counts. Use this to answer 'is property X available between dates A and B?'
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | Yes | Calendar end date in YYYY-MM-DD format. | |
| listing_id | Yes | The numeric Hostaway listing id. | |
| start_date | Yes | Calendar start date in YYYY-MM-DD format. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies read-only through 'Get' and 'Returns' and describes output, but does not explicitly state safety or behavioral traits like rate limits or authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states action and output, second gives usage context. No extraneous words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return values (per-day availability, status, price, etc.) and the use case, making it complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline is 3. The description reinforces the use of listing_id and date range but adds no new parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves availability calendar for a single listing across a date range, listing return fields and providing a concrete use case, distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to answer is property X available between dates A and B?', giving clear context for when to use. It does not specify alternatives or exclusions, but the sibling tools are sufficiently distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List guest message threads (conversations) on the connected Hostaway account. Returns a compact Markdown table with conversation id, guest, linked listing/reservation, unread state, and last activity time.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of conversations to return (1–50, default 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description discloses the output format (Markdown table) but does not mention any side effects, rate limits, or concurrency behavior. It is a read operation, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and contains no redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter schema and no output schema, the description is mostly complete. It explains what is returned and the output format. However, it lacks details on pagination or default ordering, which are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the limit parameter fully described in the schema. The description does not add additional meaning beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists guest message threads (conversations) from Hostaway and specifies the output format (Markdown table with conversation id, guest, linked listing/reservation, unread state, last activity time). It distinguishes from siblings like list_unread_conversations by implying it returns all conversations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives such as list_unread_conversations or get_conversation_messages. The purpose is clear but context for selection is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List properties (listings) on the connected Hostaway account. Returns a compact Markdown table with id, name, location, bedrooms/bathrooms, person capacity, and status.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of listings to return (1–50, default 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses output format (Markdown table with specific fields) but lacks details on auth requirements, rate limits, or read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose and output detail, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, description covers purpose and output format adequately. Could mention default sorting or filtering scope (e.g., active only).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes the single parameter 'limit' fully; description adds no extra meaning beyond schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'List' and resource 'properties (listings)', clearly distinguishing from sibling 'get_listing' which returns a single listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for listing multiple properties, but no explicit when-to-use or when-not-to-use guidance, and no mention of alternatives like 'get_listing'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List owner financial statements on the connected Hostaway account. Returns a compact table of statement id, name, and status. Useful for revenue and payout reporting.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of statements to return (1–50, default 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description adds value by stating output fields (id, name, status) but does not mention side effects, pagination, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, description adequately covers purpose and output, though missing potential filters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only parameter 'limit' is fully documented in schema (100% coverage), so baseline applies; description adds no additional semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb (list) and resource (owner financial statements) and distinguishes from sibling tools that list other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage via 'useful for revenue and payout reporting' but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List reservations on the connected Hostaway account. Optional filters by arrival date range and reservation status. Returns a Markdown table with the most useful operational fields.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of reservations to return (1–50, default 20). | |
| status | No | Filter by reservation status (e.g. 'new', 'modified', 'cancelled', 'ownerStay', 'pending', 'awaitingPayment', 'declined', 'expired', 'inquiry', 'inquiryPreapproved', 'inquiryDenied', 'inquiryTimedout', 'inquiryNotPossible'). | |
| arrival_end_date | No | Filter reservations with arrival date on or before this YYYY-MM-DD. | |
| arrival_start_date | No | Filter reservations with arrival date on or after this YYYY-MM-DD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears the full burden. It discloses the return format (Markdown table) and scope (most useful operational fields), but omits details like pagination behavior, default ordering, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences: purpose, filters, return format. It is front-loaded and wastes no words, though a bulleted structure could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 optional params, no output schema), the description covers core functionality and output format. However, it lacks details on pagination, default behavior when no filters are applied, and sort order.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well documented. The description adds context by labeling them as optional filters, but does not add meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists reservations on the connected Hostaway account, with optional filters. It distinguishes from siblings like get_reservation by being a list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description mentions optional filters, it does not explicitly state when to use this tool versus alternatives like get_reservation for individual details. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List only guest message threads that have unread messages. The most useful tool for answering 'do I have any guests waiting on a reply?'
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of conversations to scan (1–50, default 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool filters by unread status and guest threads, but it does not confirm whether the operation is read-only or if it has any side effects (like marking messages as read). With no annotations, more explicit behavioral disclosure would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The description efficiently conveys the tool's core function and the primary use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description explains what is returned (unread guest threads) but does not detail the format or fields. Given the simplicity and sibling context, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full coverage (100%) for the single 'limit' parameter with a clear description, so the description's lack of additional parameter detail is acceptable. The description does not add extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it lists only guest message threads with unread messages, and provides a concrete use case (answering 'do I have any guests waiting on a reply?'). This clearly differentiates it from siblings like list_conversations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage guidance by stating it's the most useful tool for checking for guests waiting on a reply. It does not explicitly mention when not to use it, but the naming and sibling context (list_conversations) make the distinction evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Health-check tool — confirms credentials work and returns a quick summary of the connected Hostaway account: counts of listings, reservations, conversations, owner statements, and users. Use this first when setting up to verify the connection.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the return values and purpose, but without annotations, could be more explicit about safety (non-destructive nature) and error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences include purpose, return summary, and usage guidance with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains return values sufficiently for a simple health check, though lacks output schema and error details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Description adds no parameter info, but baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a health-check for credentials and returns a summary of account counts, distinguishing it from data-retrieval siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using this tool first when setting up to verify the connection, providing clear context on when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct resource or action: single item retrieval, list views, filtered lists, calendar, and health check. No two tools overlap in purpose.
All tools follow a consistent verb_noun pattern with underscores: 'get_' for single items, 'list_' for listings, and 'whoami' for health check. The naming is predictable and clear.
With 10 tools, the server covers the essential data domains (listings, reservations, conversations, calendar, owner statements) without being overwhelming or sparse. Each tool serves a clear purpose.
The tool set provides comprehensive read access to key Hostaway data, but lacks any write operations (e.g., updating reservations, sending messages, modifying listings). This may limit agents that need to take actions.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only AI access to HAVN properties, leads, tasks, files, media, and analytics.
Vacation rental discovery, direct booking, and property protection for AI agents.
Read-only property facts, indicative availability, authorised booking links and guest-safe support.
Manage your Hostex vacation rentals—properties, reservations, availability, listings, and guest me…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/prosperkartik/hostaway-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
