Kalendis MCP Tool

MCP (Model Context Protocol) server and client generator for Kalendis scheduling API integration.

Features

• 🔧 MCP Server: Exposes Kalendis API tools for use with Claude, Cursor, etc
• 🚀 Client Generator: Generates TypeScript clients for backend and frontend applications
• 🛣️ Route Generator: Creates API route handlers for Next.js, Fastify, NestJS and Express
• 🔐 Secure: Uses environment variables for API key management
• 📝 Type-safe: Full TypeScript support; the package ships the model/request types you'll need (see "Types module" below)

Installation

npm install @kalendis/mcp

Quick Start

1. Get Your API Key

Before using the Kalendis MCP tool, you'll need an API key. Create a free account at kalendis.dev to get started. Your API key will be available in your account dashboard and is required for authenticating requests to the Kalendis scheduling API.

2. Configure MCP Server

Quick Install (Cursor IDE)

Click the button below to automatically add Kalendis to your Cursor IDE:

Manual Configuration

Alternatively, add this to your MCP settings:

{
  "mcpServers": {
    "kalendis": {
      "command": "npx",
      "args": ["-y", "@kalendis/mcp"]
    }
  }
}

3. Available MCP Tools

Once configured, the AI agent can use these tools:

• generate-backend-client: Generate a TypeScript client for direct API calls
• generate-frontend-client: Generate a TypeScript client for frontend applications
• generate-api-routes: Generate API route handlers for Next.js, Express, Fastify, or NestJS
• list-endpoints: List all available Kalendis API endpoints

Client Generation

Types Module

Every generated client and route file imports its types from a module path (../types by default, or whatever you pass as typesImportPath) - but no generator tool emits that file for you. Point it at the types this package already ships:

// e.g. when generating: { typesImportPath: '@kalendis/mcp/dist/types' }
import * as Types from '@kalendis/mcp/dist/types';

Or copy node_modules/@kalendis/mcp/dist/types.d.ts (or src/types.ts from this repo) into your project and pass its path as typesImportPath instead.

Backend Client

Generate a client that calls the Kalendis API directly:

// Generated client usage
import KalendisClient from './generated/kalendis-client';

// Initialize with your API key (from environment variable, config, etc.)
const client = new KalendisClient({
  apiKey: process.env.MY_API_KEY!, // You choose the env var name; assert/validate it's set
});

const users = await client.getUsersByAccountId();
const user = await client.addUser({ name: 'John Doe' });

Frontend Client

Generate a client that calls your backend API endpoints:

// Generated frontend client usage
import api from './generated/frontend-client';

// Calls your backend endpoints (e.g., /api/users)
const users = await api.getUsers();

API Routes

Next.js Routes

Generates App Router API routes:

// app/api/users/route.ts
export async function GET(request: Request) {
  // Implementation using backend client
}

Express Routes

Generates Express router handlers:

// routes/api.ts
router.get('/api/users', async (req, res) => {
  // Implementation using backend client
});

Fastify Routes

Generates Fastify plugin with route handlers:

// routes/kalendis.ts
export default async function routes(fastify: FastifyInstance) {
  fastify.get('/api/users', async (request, reply) => {
    // Implementation using backend client
    return users;
  });
}

NestJS Module

Generates complete NestJS module with controller, service, and module files:

// kalendis.controller.ts
@Controller('api')
export class KalendisController {
  @Get('users')
  async getUsers() {
    return this.kalendisService.getUsersByAccountId();
  }
}

// kalendis.service.ts - Wraps the backend client
// kalendis.module.ts - Wire everything together

API Endpoints Coverage

The tool supports all 35 Kalendis API endpoints:

Users

• GET /v1/user/getUsersByAccountId - Fetch all users for the account
• POST /v1/user/addUser - Create user
• PUT /v1/user/updateUser - Update user
• DELETE /v1/user/deleteUser - Delete user (query param id)

Availability

• GET /v1/availability/getAvailability - Calculated availability for a user
• GET /v1/availability/getAllAvailability - Base availability for all users
• POST /v1/availability/getMultiUserCalculatedAvailability - Calculated availability for multiple users
• POST /v1/availability/getRecurringAvailabilityByDate - Availability by recurring cadence
• POST /v1/availability/getMatchingAvailabilityByDate - Overlapping availability across users
• POST /v1/availability/addAvailability - Add availability
• PUT /v1/availability/updateAvailability - Update availability
• DELETE /v1/availability/deleteAvailability - Delete availability (query param id)

Recurring Availability

• GET /v1/recurringAvailability/getRecurringAvailability - All recurring rules for a user
• POST /v1/recurringAvailability/addRecurringAvailability - Add recurring availability
• PUT /v1/recurringAvailability/updateRecurringAvailability - Update recurring availability
• DELETE /v1/recurringAvailability/deleteRecurringAvailability - Delete recurring availability (query params id, optional userId)

Availability Exceptions

• GET /v1/availabilityException/getAvailabilityException - Merged exception blocks for a user
• POST /v1/availabilityException/addAvailabilityException - Add exception
• POST /v1/availabilityException/addRecurringAvailabilityException - Add weekly-repeating exceptions
• PUT /v1/availabilityException/updateAvailabilityException - Update exception
• DELETE /v1/availabilityException/deleteAvailabilityException - Delete exception (query params id, optional userId)

Bookings

• GET /v1/booking/getBooking - Bookings for a user in a date range
• POST /v1/booking/getBookingsByIds - Fetch bookings by IDs
• POST /v1/booking/addBooking - Create booking (supports allowDoubleBooking and allowBookingOverException)
• PUT /v1/booking/updateBooking - Update booking (supports allowBookingOverException)
• DELETE /v1/booking/deleteBooking - Delete booking (query param id)

Account

• GET /v1/account/getAccount - Get account info
• PUT /v1/account/updateAccount - Update account name

Recommendation

• POST /v1/recommendation/rankFits - Rank candidate users for one slot. Read-only.

Webhooks

Webhook management is backend-client only — it is intentionally not exposed on the generated frontend client, since webhook configuration (including the signing secret) is account/server-side data.

• GET /v1/webhooks - List all webhooks for the account
• POST /v1/webhooks - Create a webhook (the signing secret is returned only on creation)
• PUT /v1/webhooks/:id - Update a webhook
• DELETE /v1/webhooks/:id - Delete a webhook and its delivery records
• POST /v1/webhooks/:id/test - Queue a test delivery to a webhook
• GET /v1/webhooks/:id/deliveries - Get paginated webhook delivery history

Each delivery includes an X-Kalendis-Signature: sha256=<hex> HMAC header (computed from the endpoint's signing secret), alongside X-Kalendis-Event and X-Kalendis-Delivery headers.

Environment Configuration

The tool supports two environments, which set the fallback URL baked into the generated client:

• production: https://api.kalendis.dev
• development: https://sandbox.api.kalendis.dev

At runtime, the generated client always checks process.env.KALENDIS_API_URL first and falls back to the environment's URL above if it's unset — this override applies regardless of which environment you generated for, not just development.

Authentication

All API calls to the Kalendis scheduling service require authentication via the x-api-key header.

The generated clients require you to provide an API key when instantiating:

// You control how to manage your API key
const client = new KalendisClient({
  apiKey: process.env.KALENDIS_API_KEY, // or from config, secrets manager, etc.
});

The generated API route handlers use environment variables by default, but you can customize this:

# Example: Set in your application's environment
export KALENDIS_API_KEY="your-api-key-here"

Note: The MCP tool itself doesn't need or use the API key - it only generates code. The API key is used by the generated clients in your application.

Error Handling

The generated clients provide clear error messages:

• 400 (with an API-key message): Authentication failed - the API returns 400, not 401, for a missing/invalid API key
• 401: Authentication failed - Invalid or missing API key
• 403: Permission denied - API key lacks required permissions
• Network errors: Clear connection failure messages
• API errors: Detailed error messages from the API

Booking Conflicts

addBooking and updateBooking accept an allowBookingOverException flag (in addition to allowDoubleBooking, which addBooking only). When a conflict is detected, both endpoints return a 400 with one of two shapes:

// Double-booking conflict
{ message: 'conflict', conflictingBookingIds: string[], doubleBookedUserIds: string[] }

// Availability exception conflict
{ message: 'conflict', conflictingExceptionIds: string[], usersWithConflictingExceptions: string[] }

Development

To build the MCP tool locally:

cd packages/mcp-tool
npm install
npm run build

Support

For issues or questions, please contact: [email protected]