A Model Context Protocol (MCP) server for the Meet.bot Booking Page API, enabling AI assistants to interact with scheduling and booking functionality.
This MCP server connects AI assistants (like Claude, ChatGPT, and others that support MCP) to your Meet.bot account, allowing them to schedule meetings on your behalf. Instead of manually copying booking links or checking your calendar, you can simply ask your AI assistant to "schedule a 30-minute meeting with John next week" and it will handle the booking through your MeetBot scheduling pages.
How it works:
Connect your MeetBot API token to the MCP server
Configure your AI assistant to use this MCP server
Ask your AI assistant to schedule meetings - it can check your availability, find time slots, and book meetings directly through your MeetBot account
This is particularly useful for busy professionals who want to automate meeting scheduling and let their AI assistant manage their calendar intelligently.
If you don't have an account, you can get one for free at https://meet.bot
Related MCP server: mcp-meetsync
Complete API Coverage: Implements all endpoints from the Meet.bot Booking Page API v1
Type Safety: Full TypeScript support with comprehensive type definitions
Runtime Validation: Zod schemas for input validation and data integrity
Authentication Support: Bearer token authentication
Error Handling: Robust error handling with detailed error messages
Health Checks: Built-in health monitoring using the /v1/pages endpoint
MCP Protocol Compliance: Full Model Context Protocol server implementation
Dual Mode Support: Run locally (stdio) or remotely (HTTP/SSE)
Production Deployed: Live at https://mcp.meet.bot
Production Ready: Thoroughly tested and validated for production use
npm install @meetbot/mcp# Install the package
npm install @meetbot/mcp
# Or install globally for CLI usage
npm install -g @meetbot/mcpAuthentication is not a tool—it is connection-based:
HTTP/SSE (remote, e.g. https://mcp.meet.bot): Send Authorization: Bearer <your_api_token> in the request headers when connecting. The server uses this token for all API calls in that session.
Stdio (local): Set the MEETBOT_AUTH_TOKEN environment variable when starting the server (e.g. MEETBOT_AUTH_TOKEN=your_token npx @meetbot/mcp).
There is no configure_meetbot or similar tool; the AI uses the tools below and auth is handled by the connection.
The MCP server provides the following tools:
await get_scheduling_pages();
// Returns all scheduling pages for the authenticated userawait get_page_info({
page: "https://meet.bot/user/30min"
});
// Returns detailed information about a specific scheduling pageawait get_available_slots({
page: "https://meet.bot/user/30min",
count: 10,
start: "2025-01-01",
end: "2025-01-31",
timezone: "America/New_York",
booking_link: true
});
// Returns available booking slots with optional filtersawait book_meeting({
page: "https://meet.bot/user/30min",
guest_email: "guest@example.com",
guest_name: "Jane Doe",
notes: "Meeting to discuss project requirements",
start: "2025-01-15T14:00:00Z"
});
// Books a new meeting slotawait health_check();
// Verifies API connectivity using the /v1/pages endpointGet notified the moment a meeting is booked, rescheduled, or cancelled. Meet.bot POSTs a JWT-signed (HS256) JSON payload — the same contract as the partner webhook — to your URL for each event (booking_received, booking_rescheduled, booking_cancelled).
// List your webhooks
await list_webhooks();
// Create (omit id) or update (pass id) a webhook
await set_webhook({
webhook_url: "https://your-app.example.com/meetbot-hook",
description: "CRM sync",
coverage: "all", // or "selected" with pages: [<page id>, ...]
scope: "self" // team admins can use "team" to also receive teammates' bookings
});
// Returns the webhook including the shared secret used to verify the signature.
// Delete a webhook
await delete_webhook({ id: 123 });The MCP server can be run in two modes:
For local integration with AI assistants like Claude Desktop. Uses stdio transport for communication.
# Run locally
npx @meetbot/mcp
# Or with environment variable
MEETBOT_AUTH_TOKEN="your_token" npx @meetbot/mcpFor remote deployment with HTTP/SSE transport. This allows the MCP server to be accessed over the network.
# Build and start the HTTP server
npm run build
npm run start:http
# Or with custom port
PORT=8080 npm run start:http
# Or run directly with npx
npx meetbot-mcp-httpSSE Endpoint: GET /sse - Establishes an SSE connection for MCP communication
Messages Endpoint: POST /messages?sessionId=<id> - Receives client messages
Health Check: GET /health - Server health status
All requests require a Bearer token in the Authorization header:
Authorization: Bearer <your-meetbot-api-token>The same token is used to authenticate with the Meet.bot API.
Local Testing:
# Health check (should fail without auth)
curl http://localhost:3000/health
# Health check with authentication
curl -H "Authorization: Bearer YOUR_TOKEN" http://localhost:3000/health
# Connect to SSE endpoint
curl -N -H "Authorization: Bearer YOUR_TOKEN" http://localhost:3000/sse
# Or use the test script
./test-http-server.sh YOUR_TOKENProduction Testing:
# Test the live deployment
curl -H "Authorization: Bearer YOUR_TOKEN" \
https://mcp.meet.bot/health
# Expected response:
# {"status":"ok","service":"meetbot-mcp"}The HTTP server can be deployed to various platforms:
Railway: railway up ✅ Live at https://mcp.meet.bot
Fly.io: fly launch && fly deploy
Google Cloud Run: Container-based deployment
AWS App Runner: Container-based deployment
Any VPS: Run with Node.js directly
Example: Connecting to Production
# Your MCP client should connect to:
# https://mcp.meet.bot/sse
# With Authorization header:
# Authorization: Bearer <your-meetbot-api-token>Example Dockerfile:
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY dist ./dist
EXPOSE 3000
CMD ["node", "dist/cli-http.js"]This MCP server can be integrated with AI assistants like Claude, ChatGPT, and others that support the Model Context Protocol.
{
"mcpServers": {
"meetbot": {
"command": "npx",
"args": ["@meetbot/mcp"],
"env": {
"MEETBOT_AUTH_TOKEN": "your_bearer_token_here"
}
}
}
}The server exposes 8 tools for AI assistants:
get_scheduling_pages - List all scheduling pages
get_page_info - Get page details
get_available_slots - Find available time slots
book_meeting - Book a meeting
health_check - Verify API connectivity using /v1/pages endpoint
list_webhooks - List your outbound booking webhooks
set_webhook - Create or update a webhook (booking_received / booking_rescheduled / booking_cancelled)
delete_webhook - Delete a webhook
Authentication is provided by the connection (Bearer token in HTTP header for remote, or MEETBOT_AUTH_TOKEN for local stdio)—there is no separate configure tool.
The package has been thoroughly tested and validated:
✅ MCP Protocol Compliance: Full JSON-RPC 2.0 support ✅ Tool Discovery: All 5 tools properly exposed ✅ Error Handling: Graceful error responses ✅ Type Safety: Complete TypeScript support ✅ Schema Validation: Input validation with Zod ✅ Production Ready: Tested with real MCP clients
Package Size: 12.8 kB (58.0 kB unpacked)
Test Coverage: 21 passing tests
Dependencies: 3 production dependencies
TypeScript: 100% type coverage
Build Status: ✅ Passing
npm Registry: Published and available
import { MeetbotClient, MeetbotMCPServer } from '@meetbot/mcp';
// Use as a direct API client
const client = new MeetbotClient({
authToken: 'your_token'
});
// Use as an MCP server
const server = new MeetbotMCPServer();
await server.run();# Run the MCP server
npx @meetbot/mcp
# Or install globally
npm install -g @meetbot/mcp
meetbot-mcpThe core API client for direct integration:
import { MeetbotClient } from '@meetbot/mcp';
const client = new MeetbotClient({
authToken: 'your_token'
});
// Get all scheduling pages
const pages = await client.getPages();
// Get page information
const pageInfo = await client.getPageInfo({
page: 'https://meet.bot/user/30min'
});
// Get available slots
const slots = await client.getSlots({
page: 'https://meet.bot/user/30min',
count: 20
});
// Book a meeting
const booking = await client.bookSlot({
page: 'https://meet.bot/user/30min',
guest_email: 'guest@example.com',
guest_name: 'Jane Doe',
start: '2025-01-15T14:00:00Z'
});All API responses are fully typed:
interface BookSlot {
success: boolean;
page: string;
guest_email: string;
guest_name: string;
notes?: string;
start: string;
ical_uid: string;
}
interface PageInfo {
title: string;
duration: number;
url: string;
owner_name: string;
max_days_into_the_future: number;
}
interface Slots {
count: number;
duration: number;
slots: SlotDetails[];
}You can configure the MCP server using environment variables:
export MEETBOT_AUTH_TOKEN="your_bearer_token"
# Then run the server
meetbot-mcpAuth is connection-based, not a tool:
HTTP/SSE: Send Authorization: Bearer <token> in request headers when connecting to the MCP server.
Stdio: Set MEETBOT_AUTH_TOKEN when running the server (e.g. MEETBOT_AUTH_TOKEN=your_token meetbot-mcp).
npm test
npm run test:watchnpm run lint
npm run lint:fixThe package includes a command-line interface for running the MCP server:
# Install globally
npm install -g @meetbot/mcp
# Run the MCP server
meetbot-mcp
# Or run directly with npx (no installation required)
npx @meetbot/mcpYou can configure the server using environment variables:
export MEETBOT_AUTH_TOKEN="your_bearer_token"
# Then run the server
meetbot-mcpThe MCP server provides detailed error messages for common issues:
Configuration Errors: Missing or invalid configuration parameters
Authentication Errors: Invalid tokens
API Errors: Detailed error messages from the Meet.bot API
Validation Errors: Input validation failures with specific field errors
Fork the repository
Create a feature branch
Make your changes
Add tests for new functionality
Submit a pull request
MIT License - see LICENSE file for details.
Documentation: https://docs.meet.bot
Issues: GitHub Issues
Discussions: GitHub Discussions
Fix (stdio startup crash): the stdio server (npx @meetbot/mcp) declared a tools handler without advertising the tools capability, so the MCP SDK threw "Server does not support tools" and the process exited on launch. Now declares capabilities.tools; the server boots and answers initialize + tools/list (no token needed for introspection).
Server card: Added /.well-known/mcp/server-card.json for discovery and manual metadata (tools, prompts, authentication)
Smithery quality: Tool annotations (audience, priority), richer parameter descriptions, and prompts capability for quality scoring
Prompts (skills): Six MCP prompts for Smithery and clients: schedule_meeting, check_availability, book_for_guest, share_booking_link, list_my_pages, suggest_times with full prompts/list and prompts/get support
Example Config Update: Removed obsolete MEETBOT_BASE_URL from example configuration (base URL is hardcoded to https://meet.bot)
Documentation Updates: Updated production URL from Railway to https://mcp.meet.bot
Enhanced README: Added "What is this?" section explaining the MCP's purpose and how to use it for scheduling meetings through MeetBot accounts
User Onboarding: Added link to sign up for a free Meet.bot account
Jest Configuration: Updated Jest configuration for ES module support
Build Improvements: Excluded test files from TypeScript compilation
Publishing: Refined publishing checklist and documentation
ES Module Fix: Fixed ES module compatibility for Railway and other Node.js deployments
Import Extensions: Added proper .js extensions to all relative imports
Live Deployment: Successfully deployed to https://mcp.meet.bot
Production Validated: Confirmed working in production environment
HTTP/SSE Transport: Added HTTP server with SSE transport for remote deployment
Bearer Token Authentication: Implemented authentication for HTTP endpoints
Multi-mode Support: Can run as local stdio server or remote HTTP server
Deployment Ready: Added Dockerfile and deployment configurations for Railway, Fly.io, etc.
Health Check Endpoint: Added /health endpoint for monitoring
Session Management: Proper session handling with transport cleanup
Production Ready: Complete HTTP implementation with authentication and error handling
Fixed Health Check: Now uses the real /v1/pages endpoint instead of a fake health endpoint
Updated Documentation: Clarified health check implementation details
Improved Reliability: Health check now properly validates API connectivity
Simplified Configuration: Removed baseUrl requirement - now hardcoded to https://meet.bot
Updated Documentation: Simplified configuration examples
Improved UX: Users only need to provide authToken
Fixed Authentication: Removed unsupported sessionId parameter
Corrected API URL: Updated from api.meet.bot to meet.bot
Updated Documentation: Accurate authentication examples
Enhanced Documentation: Comprehensive README with usage examples
MCP Integration Guide: Added AI assistant configuration examples
Testing Results: Added validation and testing information
Initial release - Production-ready MCP server for Meet.bot API
Complete API coverage - All Meet.bot Booking Page API v1 endpoints
TypeScript support - Full type safety with comprehensive definitions
Runtime validation - Zod schemas for input validation and data integrity
MCP server implementation - Full Model Context Protocol compliance
CLI tool - Command-line interface for running the MCP server
Error handling - Robust error handling with detailed messages
Authentication - Support for bearer token authentication
Health checks - Built-in API connectivity monitoring using /v1/pages endpoint
Testing - Comprehensive test suite with 21 passing tests
Documentation - Complete API documentation and usage examples
Functional Testing - Verified with real MCP client requests
npm Publishing - Successfully published to npm registry
Book a new meeting slot
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | The URL of the scheduling page | |
| guest_email | Yes | Email address of the guest | |
| guest_name | Yes | Name of the guest | |
| notes | No | Additional notes for the meeting | |
| start | Yes | Start time in ISO 8601 format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose any behavioral traits (e.g., side effects, idempotency, permissions required, error conditions). For a mutating operation, this is critically insufficient.
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?
Extremely short (5 words) but at the expense of necessary information. It is not well-structured or front-loaded with key details; it merely states the verb and resource.
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?
Given the complexity (5 parameters, required 4, no output schema, no annotations), the description is grossly incomplete. It does not cover return values, error handling, or workflow context like checking slots beforehand.
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 baseline is 3. The description adds no extra meaning beyond what the schema already provides for each parameter, so it neither improves nor harms understanding.
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 description clearly states the verb 'Book' and resource 'meeting slot', which is distinct from sibling tools like get_available_slots (read) or list_webhooks. However, it lacks specificity about the booking context (e.g., on a scheduling page) but is sufficient to differentiate.
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 guidance provided on when to use this tool versus alternatives. There is no mention of prerequisites like checking availability via get_available_slots, nor any restrictions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete one of the authenticated user's webhooks by id
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The webhook id to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only says 'Delete' with no details on permanence, authorization needs, or side effects. Minimal behavioral disclosure for a mutation 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?
Single sentence, no wasted words. Appropriate length for a simple tool, though could be slightly more structured.
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?
Sufficient for a simple single-parameter delete operation with no output schema. Lacks details on return value or confirmation, but adequate.
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% with description 'The webhook id to delete'. Description adds no additional meaning beyond schema, so baseline of 3 is appropriate.
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?
Clearly states verb 'Delete', resource 'webhooks', scope 'authenticated user's', and identifier 'by id'. Distinguishes from siblings like list_webhooks and set_webhook.
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 explicit guidance on when to use this tool vs alternatives. Does not mention scenarios for deletion or contrast with set_webhook.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get available booking slots for a scheduling page
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | The URL of the scheduling page | |
| count | No | Maximum number of slots to return | |
| start | No | Start date in YYYY-MM-DD format | |
| end | No | End date in YYYY-MM-DD format | |
| timezone | No | Timezone in IANA format (e.g., America/New_York) | |
| booking_link | No | Include shareable booking links |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as read-only nature, rate limits, or any side effects. The tool likely performs a read operation, but it is not explicitly 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?
The description is very concise but lacks substance. While it is front-loaded, it omits important context that could fit in a slightly longer sentence.
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 6 parameters, no annotations, and no output schema, the description is too minimal to fully inform an AI agent about the tool's behavior, return format, or complete usage.
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 covers 100% of parameters with descriptions, so baseline is 3. The tool description adds no additional meaning beyond what the schema already provides.
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 description clearly states the verb 'Get', the resource 'available booking slots', and the context 'for a scheduling page', distinguishing it from sibling tools like book_meeting and get_scheduling_pages.
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 guidance on when to use this tool versus alternatives; no mention of prerequisites, exclusions, or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a specific scheduling page
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | The URL of the scheduling page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It only states 'Get information' without specifying what information is returned, authentication needs, rate limits, or side effects. This is insufficient for the agent to understand the tool's impact.
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?
The description is succinct (one sentence) but too minimal. It sacrifices informative content for brevity, leaving the agent without enough detail to confidently invoke the tool.
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?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description should at least hint at the type of information returned. Its omission makes the tool contextually incomplete for the agent's decision-making.
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?
The input schema has 100% description coverage for the single parameter, and the description adds no additional meaning. Baseline 3 is appropriate as the description does not detract but also does not enhance understanding.
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 description clearly states the action ('Get information') and the resource ('a specific scheduling page'). It distinguishes from the sibling tool get_scheduling_pages by focusing on a single page, though it could be more explicit about the uniqueness.
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 usage guidance is provided. The description does not indicate when to choose this tool over alternatives like get_scheduling_pages or book_meeting. The agent must infer 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.
Get all scheduling pages for the authenticated user
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must disclose behavior. It only states the basic action without revealing details such as pagination, rate limits, or what constitutes a scheduling page. Minimal behavioral context is provided.
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?
The description is a single concise sentence that directly communicates the tool's purpose without any extraneous 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?
Given the simplicity of the tool (no parameters, no output schema), the description is adequate but lacks any mention of output format or expected behavior, such as returning a list or handling empty results.
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?
There are no parameters, so the description cannot add value beyond the schema. The baseline for 0 parameters is 4, as the schema coverage is trivially 100%.
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 description clearly states the action (get), the resource (scheduling pages), and the scope (for the authenticated user). It is specific but does not explicitly differentiate from the sibling tool get_page_info, though 'all' implies a distinction.
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 guidance is provided on when to use this tool versus alternatives like get_page_info. There is no mention of context, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if the Meet.bot API client is properly configured and can connect
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adequately describes the purpose but does not detail behavior such as what happens on success/failure, side effects (likely none), or response format. Additional transparency would be beneficial.
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?
The description is a single, clear sentence with no wasted words. It is appropriately sized and front-loaded.
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 health check with no parameters and no output schema, the description is sufficiently complete. It covers the essential purpose, though could optionally mention the return value (e.g., boolean or status).
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 zero parameters, the baseline is 4. The description does not need to add parameter info, and no further explanation is required.
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 description clearly states the tool checks if the Meet.bot API client is properly configured and can connect. It uses a specific verb ('Check') and identifies the resource ('Meet.bot API client'), effectively distinguishing from sibling tools that deal with meetings, webhooks, or scheduling.
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 verifying API connectivity and configuration, but it does not explicitly provide when-to-use or when-not-to-use guidance. No alternatives are mentioned, though the context is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the authenticated user's outbound booking webhooks (fired on booking_received, booking_rescheduled and booking_cancelled)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation by using 'list', and specifies the event types. However, it does not disclose limitations like pagination, rate limits, or the structure of the returned data, which could affect agent behavior.
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?
The description is a single, concise sentence that is front-loaded with the key action and resource. No unnecessary words or 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?
Given the tool has no parameters and no output schema, the description could provide more context about the list result, such as typical fields or limitations. It is minimally adequate but incomplete.
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?
The tool has no parameters, so the description does not need to add parameter semantics. The baseline score of 4 applies as there are no parameters to document.
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 description clearly states it lists the authenticated user's outbound booking webhooks and specifies the three event types (booking_received, booking_rescheduled, booking_cancelled). This distinguishes it from sibling tools like set_webhook and delete_webhook.
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 explicit guidance on when to use this tool versus alternatives. While it's implied for viewing existing webhooks before setting or deleting, the description lacks direct usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update an outbound booking webhook. Omit id to create (webhook_url required); pass id to update. Meet.bot POSTs a JWT-signed (HS256) JSON payload to the URL on each booking event.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Webhook id to update; omit to create a new one | |
| webhook_url | No | HTTPS URL we POST booking events to (required when creating) | |
| description | No | Optional label for the webhook | |
| coverage | No | 'all' (default) fires for every page including ones created later; 'selected' only for the pages in `pages` | |
| scope | No | 'self' (default) your own pages; 'team' (team admins only) also fires for teammates' bookings | |
| pages | No | Page ids to cover when coverage='selected' | |
| is_active | No | Whether the webhook is active (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It discloses that Meet.bot POSTs a JWT-signed JSON payload to the URL on each booking event, but does not detail update behavior (e.g., partial vs full replacement), side effects, or authentication requirements beyond JWT. Adequate but not thorough.
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 sentences, each well-structured and front-loaded. The first sentence covers the primary purpose and create/update distinction, the second adds key behavioral detail. No wasted words.
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 7 parameters and no output schema, the description omits return values (e.g., what the tool returns on success) and does not explain default behaviors for coverage, scope, or is_active. For a moderately complex tool, this leaves gaps for the agent.
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 covers all 7 parameters with descriptions (100% coverage). The description adds context about create vs update logic and JWT posting, but does not enhance individual parameter meaning beyond what the schema already provides. Baseline 3 is appropriate.
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?
Clearly states 'Create or update an outbound booking webhook', distinguishing between create (omit id) and update (pass id). Also describes the POST behavior, making it distinct from sibling tools like delete_webhook and list_webhooks.
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?
Explicitly specifies when to omit or include the id parameter, and notes that webhook_url is required when creating. Provides clear guidance for the two main use cases, though does not mention when not to use the tool or alternatives.
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. Dates show when Glama detected each change.
v0.1.0book_meetingdelete_webhookget_available_slotsget_page_infoget_scheduling_pageshealth_checklist_webhooksset_webhookEach tool targets a distinct area: scheduling pages (list, details, slots), booking, webhooks (list, set, delete), and a health check. No overlapping purposes; agents can easily distinguish.
All tools follow snake_case and a consistent verb_noun pattern (e.g., book_meeting, delete_webhook, get_available_slots). Even health_check fits the pattern as a common compound noun.
8 tools cover the core functionality of scheduling and webhook management. The count is well-scoped for the server's purpose—neither too few nor excessive.
The tool set lacks any post-booking management: there are no tools to update, cancel, or list bookings. While webhooks handle events, agents cannot interact with existing bookings, which is a notable gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-native scheduling and booking: check availability, book meetings, share links.
Send AI bots to attend meetings on your behalf. Get recordings, transcripts, and summaries.
AI-native scheduling: check availability, book meetings, cancel and reschedule via MCP
Agent-first meeting schedule polls for humans and agents. Create polls, vote, find times.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/poolside-ventures/meetbot-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
