A
licenseB
qualityC
maintenanceA Model Context Protocol (MCP) server that provides access to the Fastmail API, enabling AI assistants to interact with email, contacts, and calendar data.
38
MIT
DAV MCP Server
by jahfer
The DAV MCP Server allows you to interact with CalDAV, CardDAV, and WebDAV services (such as Fastmail or iCloud) via the Model Context Protocol (MCP) to manage:
Calendars (CalDAV):
List available calendars with
get_my_calendarsFetch events from specific calendars with optional date/time filtering
Contacts (CardDAV):
List address books with
get_my_contact_listsRetrieve contacts from specific address books
Files (WebDAV):
List files and folders from specified paths with
list_my_files_and_foldersGet metadata for specific files or folders
Provides WebDAV file operations for services like Fastmail, allowing users to list files and folders, view file metadata, and navigate through their file storage hierarchy.
Enables access to Apple iCloud calendars (CalDAV), contacts (CardDAV), and potentially files, allowing users to list calendars, fetch events, manage contact address books, and retrieve contacts.
Click on "Install 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., "@DAV MCP Servershow my calendar events for this week"
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.
DAV MCP Server
Access your calendars, contacts, and files via MCP!
Introduction
This project is a Model Context Protocol (MCP) server that allows you to interact with your CalDAV, CardDAV, and WebDAV services. It supports both Fastmail and Apple iCloud accounts, configured via environment variables.
Related MCP server: iCloud CalDAV MCP Connector
Setup
Prerequisites: Ensure you have Node.js installed.
Clone the repository: Clone this repository to your local machine.
Install dependencies: Navigate to the project directory and run:
npm installIf you intend to publish or use this as a global command, you might also run
npm linkafter installation, or install it globally vianpm install -g .(oncepackage.jsonis configured for global installation if desired).
Environment Variable Configuration
To connect to your DAV services, you need to set the following environment variables when running the application:
DAV_PROVIDER: Specifies your DAV service provider. Set tofastmailoricloud(case-insensitive).DAV_USERNAME: Your username for the service (e.g., your Fastmail email address or Apple ID).DAV_PASSWORD: An app-specific password for the service. It is highly recommended to use app-specific passwords for security.
MCP Configuration
To use this server, you need to configure it as an mcpServer in your MCP configuration file. Here is an example:
{
"mcpServers": {
"myDavServices": {
// You can name this anything you like
"command": "npx", // Or simply "node" if it's in your PATH
"args": ["-y", "@jahfer/dav-mcp-server"], // Path to the main script
"env": {
"DAV_PROVIDER": "icloud", // or "fastmail"
"DAV_USERNAME": "your-username",
"DAV_PASSWORD": "your-app-specific-password"
}
}
}
}Available Tools
Once configured, this MCP server provides the following tools:
Calendar (CalDAV)
get_my_calendars: Lists all your available calendars.get_calendar_events: Fetches events from a specified calendar. You can optionally provide a start and end date/time to filter events within a specific range.
Contacts (CardDAV)
get_my_contact_lists: Lists all your contact address books.get_contacts_from_list: Fetches contacts from a specified address book.
Files (WebDAV - primarily for Fastmail)
list_my_files_and_folders: Lists files and folders within a specified path in your WebDAV storage (defaults to the root).get_file_or_folder_details: Fetches metadata for a given file or folder URL.
Usage
After setting up the MCP server in your configuration, you can use commands or features within your MCP client that interact with the server definition to manage your calendars, contacts, and files.
Available Tools
6 toolsget_calendar_eventsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| calendarUrl | Yes | The unique identifier (URL) of the calendar from which to fetch events. You can get this from 'get_my_calendars'. | |
| timeRangeEnd | No | ISO 8601 datetime for end of range | |
| timeRangeStart | No | ISO 8601 datetime for start of range |
TDQS
D1/5.0
Behavior1/5
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.
Conciseness1/5
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.
Completeness1/5
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.
Parameters1/5
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.
Purpose1/5
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.
Usage Guidelines1/5
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.
get_contacts_from_listD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| addressBookUrl | Yes | The unique identifier (URL) of the contact list from which to fetch contacts. You can get this from 'get_my_contact_lists'. |
TDQS
D1/5.0
Behavior1/5
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.
Conciseness1/5
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.
Completeness1/5
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.
Parameters1/5
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.
Purpose1/5
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.
Usage Guidelines1/5
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.
get_file_or_folder_detailsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| fileUrl | Yes | The unique identifier (URL) of the file or folder to get details for. You can get this from 'list_my_files_and_folders'. |
TDQS
D1/5.0
Behavior1/5
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.
Conciseness1/5
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.
Completeness1/5
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.
Parameters1/5
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.
Purpose1/5
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.
Usage Guidelines1/5
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.
get_my_calendarsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
D1/5.0
Behavior1/5
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.
Conciseness1/5
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.
Completeness1/5
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.
Parameters1/5
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.
Purpose1/5
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.
Usage Guidelines1/5
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.
get_my_contact_listsD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
D1/5.0
Behavior1/5
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.
Conciseness1/5
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.
Completeness1/5
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.
Parameters1/5
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.
Purpose1/5
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.
Usage Guidelines1/5
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.
list_my_files_and_foldersD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | The specific folder path to list. For example, 'Documents/Work'. If empty, lists files and folders in the main (root) directory. |
TDQS
D1/5.0
Behavior1/5
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.
Conciseness1/5
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.
Completeness1/5
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.
Parameters1/5
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.
Purpose1/5
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.
Usage Guidelines1/5
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
6 tool updates
v1.0.0- First observed
get_calendar_events - First observed
get_contacts_from_list - First observed
get_file_or_folder_details - First observed
get_my_calendars - First observed
get_my_contact_lists - First observed
list_my_files_and_folders
TDQS
D1.9/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting different resources: calendar events, contacts, files/folders, calendars, contact lists, and file listings. There is no overlap in functionality, making it easy for an agent to select the correct tool.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with 'get_' or 'list_' prefixes, using snake_case throughout. This predictability enhances readability and usability for agents.
Tool Count4/5
Six tools is reasonable for a DAV server covering calendars, contacts, and files, but it feels slightly thin as it lacks update/delete operations. The count is appropriate for basic read-only access, though not fully comprehensive.
Completeness2/5
The toolset is severely incomplete for a DAV server, covering only read operations (get/list) with no create, update, or delete tools. This will cause agent failures when full CRUD functionality is needed, as the surface lacks essential lifecycle coverage.
Maintenance
ActivityInactive
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
MCP server for Nylas — read email, calendars, events and contacts, and send email or create events.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceAn HTTP Model Context Protocol (MCP) server exposing iCloud Calendar (CalDAV) tools so MCP-aware clients can list calendars, read events, and create/update/delete events using an iCloud app-specific password.3MIT
- AlicenseNot gradedqualityBmaintenanceMCP server for Apple Calendar, Mail, Reminders, and Files on macOS using native frameworks.4218MIT
- AlicenseNot gradedqualityBmaintenanceUnified MCP server for Fastmail email (JMAP), calendar (CalDAV), and contacts (CardDAV). Enables sending emails, managing events, and syncing contacts through natural language.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jahfer/dav-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server