Loading ToolBench
MCP server for interaction with the lesson and event schedule at Home of Zen.
HoZ MCP exhibits significant quality gaps across multiple dimensions. While tools are clearly named with action verbs (getSchedule, registerLesson, cancelBookedLesson), descriptions lack critical LLM-optimization details. Input schemas are present but malformed: the 'required' array is stringified as a single value (e.g., 'required: ["email, date, time"]' instead of proper array syntax). Parameters have descriptions but many lack specificity about format, constraints, and error cases. Output schemas are documented only in narrative form, not as structured JSON Schema. Error handling is minimal, tools return generic success/failure messages without actionable recovery guidance. The server uses a custom @geniusagents/mcp wrapper rather than the official MCP SDK, which introduces uncertainty about spec compliance.
Make a room reservation at Home of Zen. The tool returns the following data: - Success, when the cancellation was succesful; - An error, when the cancellation was not succesful; Room reservations are always in day parts. The day parts are from 09:00 - 13:00, 13:30 - 17:30 and 18:00 - 22:00, every day of the week.
Cancel the reservation for a customer of an event at Home of Zen.The tool returns the following data:- Success, when the cancellation was succesful- An error, when the cancellation was not succesful
Cancel the reservation of a booked lesson at Home of Zen.The tool returns the following data:- Success, when the cancellation was succesful- An error, when the cancellation was not succesful
Cancel the reservation of a booked room at Home of Zen. The tool returns the following data: - Success, when the cancellation was succesful; - An error, when the cancellation was not succesful; Room reservations are always in day parts. The day parts are from 09:00 - 13:00, 13:30 - 17:30 and 18:00 - 22:00, every day of the week.
Return the availability of rooms between the given start date (startDate, yyyy-MM-dd) and the given end date (endDate, yyyy-MM-dd). The tool returns a collection of rooms with the aiablability for each daypart per date. Dayparts are from 09:00 - 13:00 (morning), 13:30 - 17:30 (afternoon), 18:00 - 22:00 (evening). The following data will be returned: - The identifier of the room (roomId); - The name of the room (name); - The price of the room in Euro (price); - The date availability (date, in yyyy-MM-dd format); - The day of the availability (day); - A list of available dayparts (i.e. [09:00 - 13:00, 18:00 - 22:00]);
Input schemas have malformed 'required' arrays: stringified as single string instead of proper JSON array. Example in bookRoom.function.ts: 'required: ["email, date, timeFrom, timeTo, roomId"]' should be 'required: ["email", "date", "timeFrom", "timeTo", "roomId"]'. This breaks schema validation in compliant MCP clients.
Input schemas lack proper JSON Schema structure. Tools use a custom object format (email: {type: string, description: ...}) rather than standard JSON Schema with properties object. Example: should be {"type": "object", "properties": {"email": {"type": "string", ...}}, "required": [...]}. This non-standard format may not be recognized by MCP validators.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 0 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 34 | - | v1 |
Return the schedule of lessons between the given start date (startDate, yyyy-MM-dd) and the given end date (endDate, yyyy-MM-dd).The tool returns a collection of lessons in the schedule, with the following data:- The identifier of the lesson (lessonId);- The date of the lessen (date, in yyyy-MM-dd format);- The day of the week of the lesson (day);- The start time of the lesson (start time, in hh:mm format);- The end time of the lesson (end time, in hh:mm formaat);- The name of the lesson (lesson name);- The name of the therapist or teacher that teaches the lesson (therapist);- The price of the lessen in internal currency Zen (price in Zen);- The price of the lesson in Euro (price in Euro);- The type of lesson (type). if type is Lesson then it's a regular lesson, if type is Event it's a irregular event;- The capacity of the lesson. How many customers can attend the lesson (capacity)- The amount of available spots in the lesson (available spots)
Return if the person with the given email address is a customer at Home of Zen.The tool returns the following data:- Is the given email address a customer (isCustomer);- The first name of the customer, if the email address is a customer (firstName);- The last name of the customer, if the email address is a customer (lastName);- The email of the customer, if the email address is a customer (email);- The phone number of the customer, if the email address is a customer (phone);- Does the person has a subscription, if the email address is a customer (subscription);- The amount of credits the customer has (credits)A Zen is an internal digital payment method to pay for lessons, eventa and sessions. When a customer does not have a credit in Zen, it is possible to pay the therapist/teacher cash or by payment request by bank.
Return if the person with the given email address is a therapist at Home of Zen. The tool returns the following data: - Is the given email address from a therapist (isTherapist); - The full name of the therapist, if the given email address is from a therapist (name); - The email of the therapist, if the given email address is from a therapist (email); - The phone number of the therapist, if the given email address is from a therapist (phone); - The address of the therapist, if the given email address is from a therapist (address); - The zipcode of the therapist, if the given email address is from a therapist (zip); - The city of the therapist, if the given email address is from a therapist (city);
Register a customer for one of the events given at Home of Zen.The tool returns the following data:- Success, when the registration was succesful- An error, when the registration was not succesfulThe reservation system of Home of Zen will confirm the reservation by e-mail.
Register a customer for one of the lessons given at Home of Zen.The tool returns the following data:- Success, when the registration was succesful.- An error, when the registration was not succesful.The reservation system of Home of Zen will confirm the reservation by e-mail.
Output schemas are documented only in narrative descriptions (e.g., 'The tool returns the following data: - lessonId; - date; - day; ...'). No structured JSON Schema provided for tool responses. LLMs cannot reliably extract or validate response fields without explicit schema. Missing pagination schema for getSchedule and getAvailableRooms, which likely return collections.
Descriptions lack LLM-optimization guidance. Example: registerLesson returns 'Success, when the registration was succesful.' Does not explain when LLM should call this vs other registration tools, what happens on error, or what the user sees next. Descriptions should be 50-200 chars and include WHEN and WHY to use the tool, not just WHAT it does.
No parameter format constraints documented. registerLesson accepts lessonDate in 'yyyy-MM-dd format' but parameter schema has no format field (e.g., 'format': 'date'). No regex patterns for email validation. No min/max for numeric parameters. LLMs cannot enforce constraints without explicit schema declarations.
Error handling is minimal and non-actionable. Functions catch errors and call ResponseFormatter.formatError(error) but do not provide recovery guidance. Example: if API key is missing, error says 'No HOZ_API_KEY provided' but does not guide LLM on whether to retry, ask user, or escalate. No distinction between retryable, user-fixable, and fatal errors.
registerLesson and registerEvent have conflicting parameter descriptions. Both tools have a 'phone' parameter with description 'The email address of the customer that will be registered.' This is a copy-paste error, phone should describe a phone number, not email. Such mistakes confuse LLMs about what data to pass.
cancelBookedRoom description has typo: 'tghe ropom reservation' instead of 'the room reservation'. Multiple tools have grammatical errors ('succesful' instead of 'successful') that reduce credibility and clarity for LLM parsing.
No pagination support documented for list-like tools (getSchedule, getAvailableRooms). If these return >50 items, context window could be exhausted. No limit, offset, or cursor parameters visible in schema. Production tools should accept page_size, offset, or limit and return total count or next_cursor.
API calls use hardcoded endpoint URLs (e.g., 'https://bookroomv2-illi72bbyq-uc.a.run.app') in tool implementations. No environment variable override visible for other endpoints. Makes server brittle if backend URLs change. Consider parameterizing all backend URLs.