Loading ToolBench
MCP server for hotel property management system with room availability checking and email capabilities
The server defines 2 tools with Zod schemas and reasonable descriptions, but has significant gaps in parameter documentation, output schema clarity, and error handling. Both tools have descriptions (10-20 chars baseline met), but parameter descriptions are sparse and inconsistent. Schemas are present but lack detailed per-parameter descriptions in several cases. No output schemas are documented, making it difficult for LLMs to understand what fields to expect in responses. Error handling is minimal, no recovery guidance, no classification of error types, and no actionable error messages. Security concerns exist around the send_email tool: no visible credential injection pattern (Gmail API keys likely hardcoded), and no permission gates. The tool names follow verb_noun convention (positive), but parameter naming could be more explicit (e.g., 'to' should be 'recipient_email'). Overall, this is a functional but underdeveloped toolset that would benefit from fuller descriptions, output documentation, and error handling.
Check room availability for a hotel
Send an email using Gmail API for a specific hotel property. Requires orgId and propertyId to identify the Gmail connection, plus to, subject, and body.
No output schemas documented. LLMs cannot infer what fields the tools return or how to chain results to downstream operations. check_availability returns database rows (structure unclear), send_email returns result (format undocumented).
Parameter 'to' in send_email is ambiguous, the description says 'Recipient email address' but lacks format constraints. Should be 'recipient_email' with pattern description 'Valid email address (RFC 5322 format)' and validation.
Minimal error handling and no recovery guidance. If check_availability returns zero rows, the LLM gets an empty array with no indication of whether availability is genuinely zero or the query failed. If send_email fails (e.g., invalid Gmail credentials, network error), no error message tells the LLM what to retry or if it's a permission issue.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 55 | - | v1 |
Security: send_email tool accepts orgId and propertyId to identify the Gmail connection, but there is no visible permission gate or audit logging. The index.js does not validate that the caller has authority to send emails from the specified property. Additionally, Gmail API credentials likely live in environment variables (.env), but the tool exposes no clear secret injection pattern, credentials could leak if result is logged.
Parameter descriptions are too brief and lack constraints. Examples: 'Organization ID' (12 chars, should explain what this is used for), 'Property ID' (11 chars), 'Check-in date' (13 chars, no format hint, should specify ISO 8601 or natural language format).
Dates in check_availability (checkIn, checkOut) are passed as strings with no format validation or description of expected format. Should document: 'ISO 8601 date string (YYYY-MM-DD) or natural language (e.g., "2024-12-25")' and validate server-side. Ambiguity forces LLMs to guess format, risking API errors.
check_availability's optional roomType parameter has no enum or documentation of valid room types. Returns depend on what the hotel system defines, but LLMs have no way to discover valid options. Should include: 'Optional. Must match a room class in the hotel system (e.g., "standard", "deluxe", "suite"). Call a list_room_types tool first if unknown.'
send_email tool response format is undocumented. The tool executes but the handler wraps results inconsistently: if result has a 'content' array, it returns as-is; otherwise, it wraps in { content: [{ type: 'text', text: JSON.stringify(result) }], structuredContent }. This is confusing, LLMs cannot rely on a consistent schema.
No idempotency or confirmation pattern for send_email. This is a destructive operation (sends an actual email) with no dry-run, confirmation step, or retry guidance. If the agent retries due to a transient error, the recipient may receive duplicate emails. Should implement a confirmation_request pattern or at least document idempotency guarantees.