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를 통해 캘린더, 연락처, 파일에 접근하세요!
소개
이 프로젝트는 CalDAV, CardDAV, WebDAV 서비스와 연동할 수 있는 모델 컨텍스트 프로토콜(MCP) 서버입니다. 환경 변수를 통해 설정된 Fastmail 및 Apple iCloud 계정을 모두 지원합니다.
Related MCP server: iCloud CalDAV MCP Connector
설정
필수 조건 : Node.js가 설치되어 있는지 확인하세요.
저장소 복제 : 이 저장소를 로컬 머신에 복제합니다.
종속성 설치 : 프로젝트 디렉토리로 이동하여 다음을 실행합니다.
지엑스피1
이것을 글로벌 명령으로 게시하거나 사용하려는 경우 설치 후
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.
Hosted email MCP for your own Gmail, Outlook.com, Microsoft 365, iCloud or IMAP inbox: read, search, draft, reply in thread, forward and file mail. It moves or flags up to 500 messages in one call, and a send leaves exactly one copy in Sent. A calendar is a separate connection, and connecting one adds diary and scheduling tools.
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
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceAn 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.33 npm21MIT
- AlicenseNot gradedqualityCmaintenanceUnified MCP server for Fastmail email (JMAP), calendar (CalDAV), and contacts (CardDAV). Enables sending emails, managing events, and syncing contacts through natural language.MIT