Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@nexudus-mcp Book me a conference room tomorrow at 2pm for 6 people"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that lets Claude Code book and manage rooms in Nexudus coworking spaces using natural language.
"Book me a conference room tomorrow at 2pm for 6 people"
List rooms with capacity and amenities
Check availability for a time window
Book rooms by name (fuzzy matching)
View your upcoming bookings
Cancel bookings
View a room's schedule for a given day
Related MCP server: DiSH MCP Server
Claude Code installed
A Nexudus member account with login credentials
Your portal URL (e.g., yourspace.spaces.nexudus.com)
Node.js 18+
Tell Claude Code:
Clone github.com/jude-stiel/nexudus-mcp and set it up as an MCP server for Nexudus room booking
Claude will walk you through the rest. Or do it manually:
Clone and build
git clone https://github.com/jude-stiel/nexudus-mcp.git
cd nexudus-mcp
npm install
npm run buildCreate .env
cat > .env << 'EOF'
NEXUDUS_EMAIL=your-email@example.com
NEXUDUS_PASSWORD=your-password
NEXUDUS_PORTAL=yourspace.spaces.nexudus.com
NEXUDUS_COWORKER_ID=your-coworker-id
EOFNEXUDUS_EMAIL / NEXUDUS_PASSWORD — your Nexudus login credentials
NEXUDUS_PORTAL — your space's portal hostname (check your browser URL bar when logged in)
NEXUDUS_COWORKER_ID — (optional) your member ID in Nexudus. If omitted, the server extracts it from your existing bookings. To find it manually: open DevTools on the portal, book a room, and look for CoworkerId in the network request body.
Test your credentials
read -rs 'pass?Password: ' && echo && curl -s -X POST https://spaces.nexudus.com/api/token \
--data-urlencode 'grant_type=password' \
--data-urlencode "username=YOUR_EMAIL" \
--data-urlencode "password=$pass" | python3 -c "import sys,json; d=json.load(sys.stdin); print('Token OK' if 'access_token' in d else f'Auth failed: {d}')"Register with Claude Code
Add to .mcp.json in your working directory (create the file if it doesn't exist):
{
"mcpServers": {
"nexudus-rooms": {
"command": "/absolute/path/to/nexudus-mcp/start.sh"
}
}
}Restart Claude Code — the server will connect automatically on startup.
Just talk to Claude naturally:
You say | What happens |
"What rooms are available at 2pm tomorrow?" | Searches availability for conference rooms |
"Book the main conference room Thursday 10-11am" | Books the room via the checkout flow |
"What do I have booked this week?" | Lists your upcoming bookings |
"Cancel my 3pm booking" | Looks up the booking ID and cancels it |
"What's the schedule for the small meeting room today?" | Shows all bookings for that room |
"I need a room for 8 people tomorrow at noon" | Searches, filters by capacity, suggests options |
The server authenticates with Nexudus using your member credentials (OAuth bearer token) and calls the same portal API endpoints that the Nexudus web portal uses. It does not require admin API access.
See WALKTHROUGH.md for a detailed technical explanation of the architecture, API reverse-engineering process, and obstacles overcome.
Member-level access only — uses the portal API, not the admin REST API. This works for booking and cancelling your own rooms but can't perform admin operations.
Availability data — the portal returns bookings for the current month. Availability checks for dates far in the future may be incomplete.
No recurring bookings yet — each booking is a one-off. The Nexudus data model supports repeating bookings but the creation flow hasn't been implemented.
Token refresh — tokens are cached and refreshed automatically, but if your password changes you'll need to update .env and restart.
MIT
Book a room for a specific time slot
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date in YYYY-MM-DD format | |
| room | Yes | Room name (partial match OK) or numeric room ID | |
| notes | No | Optional booking notes | |
| end_time | Yes | End time in HH:MM 24-hour format | |
| start_time | Yes | Start time in HH:MM 24-hour format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and delivers almost none of it. It does not say what happens on a time-slot conflict, whether the booking is confirmed immediately, whether notes are persisted, or whether the operation is reversible (cancel_booking exists, implying reversibility, but this is not 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?
A single short sentence with the action front-loaded and no wasted words. It is efficiently structured, though its brevity reflects under-specification rather than disciplined economy.
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 4-required-parameter mutation tool with no annotations and no output schema, the description omits conflict handling, confirmation semantics, and error behavior. The agent has the required inputs but no picture of what the call does behaviorally or what it returns.
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%, so every parameter including date/time formats, partial room-name matching, and optional notes is already documented in the schema. The description adds nothing beyond it, which is the expected baseline when the schema does the heavy lifting.
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?
States a specific verb and resource ('Book a room') plus the scoping constraint ('for a specific time slot'), so the agent knows this is a write operation creating a booking. It does not distinguish itself from siblings like search_available_rooms or get_room_schedule, but the booking vs. searching distinction is largely self-evident from the verb.
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?
No when-to-use guidance, no exclusions, and no mention of the obvious prerequisite workflow (e.g., checking availability first with search_available_rooms). The agent is left to infer that this is the terminal step of an availability-check-then-book flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a booking by its ID
| Name | Required | Description | Default |
|---|---|---|---|
| booking_id | Yes | The booking ID to cancel |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it delivers almost nothing: it does not say whether cancellation is irreversible, whether it requires authorization, whether fees/refunds apply, or whether it is idempotent. Only the implicit destructiveness of 'cancel' conveys any behavioral signal.
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?
One short, front-loaded sentence with zero wasted words. It is efficient, though the brevity is the same sparseness that leaves behavioral and usage gaps.
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 trivial one-parameter destructive tool with no annotations and no output schema, the description is minimally viable but leaves the agent without irreversibility, authorization, or post-cancel state information that matters for a mutation.
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?
With a single required parameter at 100% schema description coverage, the schema already fully documents booking_id. The description adds no format, range, or lookup detail beyond what the schema states, so baseline 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?
States a specific verb+resource ('Cancel a booking') and the identifier it operates on, which lets an agent separate it from book_room and my_bookings without opening the schema. It stops short of any sibling differentiation or scope statement, so it is clear but not exemplary.
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?
There is no guidance on when to cancel versus rebooking, no prerequisite such as ownership or booking state, and no mention of an alternative tool. The agent must infer the entire usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View all bookings for a specific room on a given date
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date in YYYY-MM-DD format | |
| room | Yes | Room name (partial match OK) or numeric room ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'View' weakly implies a read-only operation, but nothing is said about permissions, sorting, or pagination of the resulting booking list, and there is no output schema to fall back on.
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?
A single front-loaded sentence with no filler; every word contributes to identifying the operation and its scope.
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?
With only two fully documented parameters, no annotations, and no output schema, the callable surface is adequately covered. However, the description never indicates what a booking entry contains or how results are ordered/limited, which leaves a gap for a listing tool.
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%, so the format ('YYYY-MM-DD') and the partial-match/room-ID semantics are already fully documented in the schema. The description adds nothing beyond it, which is the baseline 3 case.
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?
States a specific verb and resource ('View all bookings') with the scoping dimensions (specific room, given date), which lets an agent separate it from siblings like my_bookings or search_available_rooms. It does not explicitly name those siblings, so it stops short of a 5.
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?
There is no explicit when-to-use or when-not-to-use guidance and no alternatives are named. The agent must infer from the sibling list that this is the per-room-by-date view rather than the availability search or the personal bookings list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all bookable rooms with capacity and amenities. Can filter by type (Conference Room, Lab Equipment, Wellness Room).
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter by resource type, e.g. 'Conference Room', 'Lab Equipment', 'Wellness Room' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it establishes that this is a read operation and discloses the returned fields (capacity, amenities), which is genuine behavioral context. It omits any mention of pagination, result limits, or whether unavailable rooms are excluded, which matters for a listing tool with no output schema.
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 short sentences, front-loaded with the core action and scope, with no filler or repetition. Slightly tight given that it spends words repeating schema-documented type examples rather than adding new 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?
For a simple one-parameter listing tool this is close to adequate: the return contents are summarized and the filter is covered by the schema. But with no annotations and no output schema, the description should say more about result shape or pagination to be fully self-sufficient.
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%, so the baseline is 3, and the description's parenthetical type examples simply mirror the enum-less string parameter already documented in the schema. It adds no matching rules, case-sensitivity, or default behavior beyond what the schema states.
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 first sentence names a specific verb and resource ('List all bookable rooms') and states the payload fields returned (capacity, amenities), so the tool's function is unambiguous. It implies the full-inventory scope that separates it from search_available_rooms, but never names or contrasts that sibling explicitly.
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 word 'all' hints this is the browse-everything tool versus an availability-based search, and 'Can filter by type' suggests the optional narrowing path. However, there is no explicit when-to-use statement, no when-not-to-use, and no sibling named, so the routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your upcoming (or recent past) bookings
| Name | Required | Description | Default |
|---|---|---|---|
| include_past | No | Include past bookings (default: false, shows future only) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It doesn't clarify authentication requirements (implied 'your'), result limits, ordering, pagination, or how 'upcoming' is defined, leaving significant behavioral gaps for a list tool.
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?
A single short sentence that front-loads the core action and enumerates the temporal scope. No waste.
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?
With no annotations and no output schema, the description should do more to describe ordering, limits, and what a booking entry contains. It covers the essential scope but leaves return format and behavior unspecified.
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%, documenting include_past and its default fully. The description adds the '(or recent past)' hint but no syntax or edge cases 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?
States a specific verb (List) and resource (your bookings) with temporal scope clarified in parentheses. Differentiates implicitly from siblings like get_room_schedule or search_available_rooms, though it doesn't explicitly name an alternative to check for conflicts.
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?
Usage is implied by the tool name and 'your bookings' phrasing (for the calling user's own reservations), but there is no explicit statement of when to use this vs. list_rooms or get_room_schedule, and no prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find which rooms are free during a specific time window
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date in YYYY-MM-DD format | |
| type | No | Filter by resource type, e.g. 'Conference Room' | |
| end_time | Yes | End time in HH:MM 24-hour format | |
| start_time | Yes | Start time in HH:MM 24-hour format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It implies a read-only search but does not state whether results are filtered, sorted, paginated, or bounded by a result limit, nor anything about permissions. It adds only the bare notion of a time window.
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?
A single efficient sentence with no waste and the key constraint (specific time window) front-loaded. It is perhaps too terse for the tool's complexity, but nothing is padded.
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 4-parameter read tool with full schema coverage, the description is minimally adequate: it conveys that availability is returned. With no output schema, it does not state the shape of the result (room list vs. boolean availability) or handle the optional type filter, leaving a modest gap.
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 the schema already documents date, start_time, end_time and the type filter. The description adds only the implicit link between 'time window' and the start/end pair, contributing nothing beyond the structured fields. Baseline 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?
States a specific verb-resource pair ('find which rooms are free') and scopes it to a time window, so the agent knows this returns room availability rather than a schedule or a booking action. It is distinguishable from get_room_schedule and list_rooms, though it never names those siblings explicitly.
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 the tool is for availability checks but gives no conditions for choosing it over list_rooms or get_room_schedule, nor any prerequisites about when a query is appropriate. All guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0book_roomcancel_bookingget_room_schedulelist_roomsmy_bookingssearch_available_roomsScored across 6 tools
Each tool targets a distinct aspect of room booking: inventory (list_rooms), availability search (search_available_rooms), schedule viewing (get_room_schedule), booking action (book_room), personal bookings (my_bookings), and cancellation (cancel_booking). No two tools overlap in purpose, and descriptions clearly delineate their scope.
Five of six tools follow a consistent verb_noun snake_case pattern (list_rooms, search_available_rooms, get_room_schedule, book_room, cancel_booking). 'my_bookings' deviates as a possessive noun phrase, but the overall convention remains readable and predictable.
Six tools provide a well-scoped set for a room booking domain, covering discovery, availability, scheduling, booking, and cancellation without redundancy. The count is typical for a focused MCP server.
Core lifecycle operations are present: list rooms, check availability, view schedules, book, list personal bookings, and cancel. The only notable gap is a dedicated update/reschedule operation, but this can be worked around by canceling and rebooking.
AI-native scheduling and booking: check availability, book meetings, share links.
Manage YouCanBook.me bookings, booking pages, appointment types, team members and locations.
Schedule and manage Google Calendar events directly from your workspace. Check availability, view…
Manage Novacal event types, availability, and bookings.
