Hostkit MCPofficial
A
licenseB
qualityB
maintenanceMCP server for the Hostkit API, enabling management of properties, reservations, guests, invoices, and other property operations.
36
MIT
speeron-next
Server Details
Speeron NEXT Digital Guest Journey MCP server (remote HTTP endpoint).
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 99.9% over 36 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-06-18
- URL
TDQS
D1.6/5.0
Scored across 4 tools
Disambiguation3/5
Two search tools (search_room_options and search_rooms_by_area) overlap significantly without descriptions to clarify their difference. check_in_user and confirm_booking both relate to booking status but likely represent distinct steps, leaving moderate ambiguity overall.
Naming Consistency4/5
All tool names follow a snake_case verb_noun pattern (check_in_user, confirm_booking, search_room_options, search_rooms_by_area). Minor deviation in search_rooms_by_area's prepositional phrase, but still readable and consistent.
Tool Count3/5
With only 4 tools, the set is thin for a room booking domain, especially since two tools both search for rooms. Core operations like creating or canceling a booking are absent, suggesting under-scoping.
Completeness2/5
The surface lacks essential booking lifecycle operations such as create_booking, cancel_booking, check_out, or list_bookings. Only search, confirm, and check-in exist, leaving significant gaps that would cause agent failures in common workflows.
Available Tools
4 toolscheck_in_userDRead-onlyInspect
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| country | No | ||
| tenantId | No | ||
| bookingId | Yes | ||
| hotelName | No | ||
| guestLastName | Yes |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
confirm_bookingDInspect
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| optionId | Yes | ||
| guestName | Yes | ||
| hotelName | No | ||
| checkInDate | Yes | ||
| numberOfAdults | Yes | ||
| numberOfNights | Yes | ||
| numberOfChildren | No |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_room_optionsDInspect
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | ||
| country | No | ||
| tenantId | No | ||
| hotelName | Yes | ||
| checkInDate | Yes | ||
| numberOfAdults | Yes | ||
| numberOfNights | Yes | ||
| numberOfChildren | No |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_rooms_by_areaDInspect
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | ||
| country | No | ||
| checkInDate | Yes | ||
| numberOfAdults | Yes | ||
| numberOfNights | Yes | ||
| numberOfChildren | No |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
- First observed
check_in_user - First observed
confirm_booking - First observed
search_room_options - First observed
search_rooms_by_area
Related MCP Connectors
Remote MCP server for hotel rate monitoring, parity checks, and pricing intelligence via Apify.
Hotel booking MCP server. Search, book, and manage reservations across 250K+ properties worldwide.
REST-to-MCP for UK hospitality. Safety proxy: circuit-breakers, rate limits, whitelists. Apache 2.0.
Unofficial read-only MCP server for VeryChic hotel offers
Related MCP Servers
- FlicenseNot gradedqualityBmaintenanceMCP server that exposes the Vikey API for reservation management, property listing, and payment information retrieval.-
- AlicenseBqualityDmaintenanceThis MCP server provides comprehensive access to the Mews hospitality platform API, covering customer and company management, reservation operations, financial transactions, account management, configuration settings, and services inventory. It implements the core functionality needed for hospitalit536 npmMIT
- FlicenseNot gradedqualityBmaintenanceRemote MCP server for verifying API key authentication header propagation and debugging inbound HTTP headers.-
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.