DiSH MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TEAM_ID | Yes | Your DiSH team ID | |
| MEMBER_ID | Yes | Your DiSH member ID | |
| DISH_COOKIE | Yes | Your DiSH connect.sid session cookie (e.g., connect.sid=s%3A...) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_availability_and_list_bookingsC | Check room availability for the DiSH API and list bookings for a room and date range. Args: datetime_range: Datetime range for the query resource_ids: Optional list of room resource IDs to query. cookie: Authentication cookie. If not provided, looks for DISH_COOKIE env var. ctx: Context object. Returns: str: The availability summary. |
| book_roomB | Book a room using the Dish Manchester API. Args: datetime_range: Datetime range for the booking meeting_room_name: Name of the meeting room user_info: User information. If not provided, looks for TEAM_ID and MEMBER_ID env vars. cookie: Authentication cookie. If not provided, looks for DISH_COOKIE env var. summary: Title of the booking: default to "meeting" |
| cancel_bookingA | Cancel a room booking using the DiSH API. To cancel a booking, you need to know the booking ID. You can get the booking ID by using the
Args: booking_id: The ID of the booking to cancel (e.g., "692192791c60f69c20311db3") cookie: Authentication cookie. If not provided, looks for DISH_COOKIE env var. skip_cancellation_policy: Whether to skip cancellation policy (default: False) |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose with no overlap: book_room creates bookings, cancel_booking removes them, and check_availability_and_list_bookings queries availability and existing bookings. The descriptions explicitly differentiate their functions, and the cancel_booking tool even references check_availability_and_list_bookings as a way to find booking IDs, showing complementary rather than overlapping roles.
The tool names follow a consistent verb_noun pattern (book_room, cancel_booking, check_availability_and_list_bookings), all using snake_case. However, check_availability_and_list_bookings is longer and combines two actions, which slightly deviates from the simpler verb_noun style of the others, but the overall pattern remains clear and readable.
With 3 tools, this server is well-scoped for its purpose of managing room bookings via the DiSH API. Each tool earns its place by covering essential operations: booking, canceling, and checking availability/listings. This count is appropriate for a focused domain without being too thin or bloated.
The tool set provides complete CRUD/lifecycle coverage for room bookings: create (book_room), read (check_availability_and_list_bookings), and delete (cancel_booking). A minor gap is the lack of an update tool for modifying existing bookings, but agents can work around this by canceling and rebooking. The domain is clearly covered for core workflows.