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., "@Schedulia MCP show me my meeting schedule for today"
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.
Related MCP server: MCP Calendar Assistant
✅ Git
✅ Python
✅ UV (Python Package Manager) - UV Installation Guide
Get Your API Key
Get your API key from schedulia.org 🔑
Clone Repository
git clone https://github.com/watanka/schedulia-mcp.git
cd schedulia-mcpRun Server
uv run server.py --api-key={your-api-key} # Replace with your API key!Configure MCP Server
{
"mcpServers": {
"schedulia-mcp": {
"command": "uv",
"args": [
"--directory",
"/path/to/mcp/server",
"run",
"server.py",
"--api-key",
"{your-api-key}"
]
}
}
}Register MCP Server on your host(Claude Desktop, Cursor)
For Claude Desktop users: Configuration Guide
For Cursor users: Configuration Guide
view_meeting_schedules(date): Check all scheduled meetings for a specific date
Ask to see your meetings using the view_meeting_schedules tool. You can specify a date or view all schedules.
Prompt Examples:
"Please show me my meeting schedules"
"Can you check my meetings for today using view_meeting_schedules?"
"Use view_meeting_schedules to show my upcoming meetings"
Example Response:
{
"id": 1,
"host": {"name": "John Doe", "email": "john@example.com"},
"participants": [
{"name": "Alice Smith", "email": "alice@example.com"}
],
"time": {
"start_time": "2024-03-20T14:00:00",
"end_time": "2024-03-20T15:00:00"
},
"title": "Project Review",
"description": "Weekly sync meeting"
}view_meeting_requests(): Check all incoming meeting requests
Use the view_meeting_requests tool to check any pending meeting invitations.
Prompt Examples:
"Use view_meeting_requests to show my pending invitations"
"Check my meeting requests using view_meeting_requests tool"
"Show me all meeting requests in the system"
Example Response:
{
"request_id": 1,
"sender": {"name": "Alice Smith", "email": "alice@example.com"},
"receiver_email": "john@example.com",
"available_times": [
{
"start_time": "2024-03-21T15:00:00",
"end_time": "2024-03-21T16:00:00"
}
],
"status": "PENDING",
"title": "Product Discussion"
}respond_to_meeting_request(request_id, accept, selected_time): Accept or decline meeting requests
This is a two-step process using both view_meeting_requests and respond_to_meeting_request tools.
Step 1 - View Requests:
"First, use view_meeting_requests to show me pending invitations"
"Let me check the meeting requests using view_meeting_requests tool"
Step 2 - Respond:
"Use respond_to_meeting_request to accept request ID 1 with the proposed time slot"
"Please use respond_to_meeting_request to decline meeting request #2"
Example Conversation:
User: "First, show me my meeting requests using view_meeting_requests"
Assistant: "Here are your pending meeting requests: [shows requests]"
User: "Great, I want to accept request ID 1 using respond_to_meeting_request for the March 21st 15:00-16:00 slot"request_meeting(receiver_email, available_times, title, description): Create and send new meeting requests
Use the request_meeting tool to create new meeting requests. You'll need to provide receiver's email, available times, title, and description.
Prompt Examples:
"Use request_meeting to schedule a meeting with alice@example.com"
"I need to send a meeting request using request_meeting tool for tomorrow"
"Create a new meeting request with request_meeting for the team sync"
Example Request:
"Please use request_meeting to set up a meeting with following details:
- Receiver: alice@example.com
- Title: Project Kickoff
- Description: Initial project planning meeting
- Available times:
- March 25th, 2024 14:00-15:00
- March 26th, 2024 11:00-12:00"Example Response:
{
"request_id": 3,
"sender": {"name": "John Doe", "email": "john@example.com"},
"receiver_email": "alice@example.com",
"available_times": [
{
"start_time": "2024-03-25T14:00:00",
"end_time": "2024-03-25T15:00:00"
},
{
"start_time": "2024-03-26T11:00:00",
"end_time": "2024-03-26T12:00:00"
}
],
"status": "PENDING",
"title": "Project Kickoff",
"description": "Initial project planning meeting"
}Need help? Check out demo videos! 🎥
| Name | Required | Description | Default |
|---|---|---|---|
| receiver_email | Yes | ||
| available_times | Yes | ||
| title | Yes | ||
| description | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | ||
| accept | Yes | ||
| selected_time | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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.
v0.1.0request_meetingrespond_to_meeting_requestview_meeting_requestsview_meeting_schedulesScored across 4 tools
Each tool has a clearly distinct purpose with no overlap: requesting meetings, responding to requests, viewing requests, and viewing schedules. The actions (request, respond, view) and targets (meeting_requests, meeting_schedules) are well-defined, making it easy for an agent to select the correct tool.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., request_meeting, respond_to_meeting_request). The naming is predictable and readable throughout the set, with no deviations in style or convention.
With 4 tools, the count is reasonable for a scheduling/meeting domain, covering core actions like request, respond, and view. It might be slightly thin if advanced features (e.g., cancel_meeting, update_schedule) are expected, but it's well-scoped for basic functionality.
The tools cover key aspects of meeting management (requesting, responding, viewing), but there are notable gaps. For example, there's no tool to cancel or modify meetings, and no direct scheduling creation tool, which could limit agent workflows in a full meeting lifecycle.
AI-native scheduling and booking: check availability, book meetings, share links.
AI-native scheduling: check availability, book meetings, cancel and reschedule via MCP
AI-native scheduler that lives in Claude. Describe meetings in plain English; Heldly does the rest.
Scheduling for AI assistants: bookings, availability, meeting polls and routing forms.