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
DAV MCP 服务器
通过 MCP 访问您的日历、联系人和文件！
介绍
该项目是一个模型上下文协议 (MCP) 服务器，允许您与 CalDAV、CardDAV 和 WebDAV 服务进行交互。它支持 Fastmail 和 Apple iCloud 帐户，可通过环境变量进行配置。
Related MCP server: iCloud CalDAV MCP Connector
设置
先决条件：确保您已安装 Node.js。
克隆存储库：将此存储库克隆到本地计算机。
安装依赖项：导航到项目目录并运行：
npm install如果您打算发布或使用它作为全局命令，您也可以在安装后运行
npm link，或者通过npm install -g .（如果需要，一旦package.json配置为全局安装）。
环境变量配置
要连接到您的 DAV 服务，您需要在运行应用程序时设置以下环境变量：
DAV_PROVIDER：指定您的 DAV 服务提供商。设置为fastmail或icloud（不区分大小写）。DAV_USERNAME：您在该服务中的用户名（例如，您的 Fastmail 电子邮件地址或 Apple ID）。DAV_PASSWORD：服务的应用专用密码。出于安全考虑，强烈建议使用应用专用密码。
MCP 配置
要使用此服务器，您需要在 MCP 配置文件中将其配置为mcpServer 。以下是示例：
{
"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"
}
}
}
}可用工具
配置完成后，该 MCP 服务器将提供以下工具：
日历（CalDAV）
get_my_calendars：列出所有可用的日历。get_calendar_events：从指定日历中获取事件。您可以选择提供开始和结束日期/时间，以过滤特定范围内的事件。
联系人（CardDAV）
get_my_contact_lists：列出您的所有联系人地址簿。get_contacts_from_list：从指定的地址簿中获取联系人。
文件（WebDAV - 主要用于 Fastmail）
list_my_files_and_folders：列出 WebDAV 存储中指定路径内的文件和文件夹（默认为根目录）。get_file_or_folder_details：获取给定文件或文件夹 URL 的元数据。
用法
在您的配置中设置 MCP 服务器后，您可以使用 MCP 客户端中与服务器定义交互的命令或功能来管理您的日历、联系人和文件。
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.
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
Scored across 6 tools
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
ResponsivenessNo issues
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 gradedqualityDmaintenanceMCP server for Apple Calendar, Mail, Reminders, and Files on macOS using native frameworks.15 npm21MIT
- 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