Reported issues for dav-mcp

Pod holds 21 of 31 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to dav-mcp.

Most discussed

🐛 Critical: All TODO tools crash - client.fetchTodos is not a function

Summary

All TODO-related tools crash at runtime with . This affects every TODO operation in the system.

Root Cause

The code calls client.fetchTodos(), which does not exist in tsdav's DAVClient API.

tsdav's Actual API:

DAVClient.prototype = [
  'fetchCalendars',
  'fetchCalendarUserAddresses', 
  'fetchCalendarObjects',  // ← This is what we should use
  'fetchAddressBooks',
  'fetchVCards'
]

There is no fetchTodos method.

Affected Files (5 locatio

Read the thread · 2025-10-27 · closed · 3 comments

addressbook_query requires URL while calendar_query/todo_query support multi-search

Currently there's an inconsistency in how query tools handle multi-resource search:

✅ calendar_query & todo_query: Search ALL calendars when calendar_url is omitted
❌ addressbook_query: REQUIRES addressbook_url (cannot search across all addressbooks)

This is inconsistent and should be unified.

Proposed Solution

Make addressbook_url optional in addressbook_query to enable multi-addressbook search (like calendar_query)

Code References

`src/tools/calendar/calendar-query

Read the thread · 2025-10-27 · closed · 3 comments

client.fetchTodos is not a function — tsdav 2.3.0 doesn't export fetchTodos

Bug: `client.fetchTodos is not a function` — tsdav 2.3.0 doesn't export `fetchTodos`

Environment

dav-mcp version: 3.0.7 (latest on npm)
tsdav version (bundled): 2.3.0 (git-pinned to PhilflowIO/tsdav#master)
Node: 24.15.0
macOS 26.4.1 (arm64)
iCloud Reminders via CalDAV

Symptom

Every call to list_todos or todo_query tools fails with:

client.fetchTodos is not a function

Verified by grep "exports.fetchTodos" tsdav.cjs → 0 matches in the bundled

Read the thread · 2026-04-27 · closed · external user · 2 comments

Bug: Contact photos (PHOTO field) cause LLM context overflow

🐛 Problem

When contacts contain photos in the PHOTO field, the Base64-encoded image data is included in the LLM response, causing massive context overflow.

Location

src/formatters.js:372-377 in formatContactList()

Root Cause

The raw vCard data is included in the output for debugging:

output += JSON.stringify(contacts.map(c => ({
  url: c.url,
  etag: c.etag,
  data: c.data  // ← Contains full vCard with Base64 PHOTO!
})), null, 2);

A single contact photo can

Read the thread · 2025-11-13 · closed · 1 comment

LLM generates absurd time ranges in calendar_query despite required fields (120k token overflow)

Problem

Despite fixing #24 by making both time_range_start and time_range_end required fields, LLMs still generate absurd time ranges that cause token overflow.

Example Query

User asks: "When is my next appointment?"

LLM generates:

{
  "tool": "calendar_query",
  "query": {
    "time_range_start": "2025-10-31T10:35:42.459+01:00",
    "time_range_end": "2099-12-31T23:59:59.000Z"
  }
}

Result: 120k tokens consumed (just from holidays!) 💸

Root Cause

The LLM inter

Read the thread · 2025-10-31 · closed · 1 comment

Query tools can be called without filters, defeating their purpose

All query tools have required: [] which allows them to be called without any parameters. This defeats the entire purpose of query tools (filtering).

Problem

calendar_query({}) - fetches ALL events from ALL calendars
todo_query({}) - fetches ALL todos from ALL calendars
addressbook_query({addressbook_url: "..."}) - fetches ALL contacts (no filter)

Why This Is Bad

Loads thousands of entries (token explosion)
Defeats the purpose of query tools (they become inefficient list

Read the thread · 2025-10-27 · closed · 1 comment

Missing tsdav-utils dependency causing Docker container crash

Bug Description

The Docker container crashes on startup with ERR_MODULE_NOT_FOUND error when trying to import tsdav-utils package.

Error Message

Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'tsdav-utils' imported from /app/src/tools/calendar/update-event-fields.js
    at Object.getPackageJSONURL (node:internal/modules/package_json_reader:314:9)
    at packageResolve (node:internal/modules/esm/resolve:767:81)
    ...

Root Cause

The tsdav-utils package is imported

Read the thread · 2025-10-27 · closed · 1 comment

LLM chooses update_event instead of update_event_fields despite PREFERRED label

Problem

Testing shows that the LLM still chooses update_event (old iCal-based tool) instead of update_event_fields (new field-based tool) in ~100% of test cases, despite:

⚠️ WARNING label on update_event
⭐ PREFERRED label on update_event_fields
Clear description stating "NOT recommended for LLM/AI use"

Test Results

Test: update-fields-001 - Update event summary only
Query: "I need to change the title of my event at [URL] to 'New Meeting Title'"
**Expect

Read the thread · 2025-10-25 · closed · 1 comment

Most recent

fields.DTEND on a DURATION-based event produces an illegal object

Split out of #43 rather than widening that PR.

update_event now has dedicated start_date/end_date/all_day parameters, and those correctly drop a stale DURATION when they write DTEND (RFC 5545 §3.6.1: dtend and duration MUST NOT occur in the same eventprop).

The older fields path does not. fields: { DTEND: "..." } on an event stored as DTSTART + DURATION goes through tsdav-utils' updateFields → updatePropertyWithValue('dtend', ...), which knows nothing about DURATI

Read the thread · 2026-08-14 · closed · 0 comments

tool-call-logger writes to stdout under stdio transport, corrupting the JSON-RPC stream

Symptom

Under the stdio transport, setting TOOL_CALL_LOG_MODE=console (or both) writes non-JSON-RPC lines onto stdout and corrupts the protocol stream.

Root cause

src/tool-call-logger.js:32-34 does an unconditional console.log(line.trim()) for those modes, and initializeToolCallLogger reads the mode from TOOL_CALL_LOG_MODE. src/server-stdio.js never redirects console and calls this logger on every tool call.

src/logger.js:62-64 already solves exactly this — `const

Read the thread · 2026-08-14 · closed · 0 comments

create_event and create_contact emit LF line endings; sanitizeICalString does not escape CR

Symptom

Two of the three iCal/vCard builders emit documents with bare LF line endings, and sanitizeICalString lets a raw CR through into property values. RFC 5545 §3.1 and RFC 6350 require CRLF.

sanitize("a\r\nX-EVIL:1") = "a\r\\nX-EVIL:1"   ← LF escaped, CR survives raw
sanitize("a\rX-EVIL:1")   = "a\rX-EVIL:1"

Builder	Line endings
`src/tools/calendar/create-event.js:55-65`	bare LF
`src/tools/contacts/create-contact.js:65-70`	bare LF
`src/tools/todo

Read the thread · 2026-08-14 · closed · 0 comments

formatDateTime renders times in the server's timezone; Exchange TZIDs blank the date entirely

Symptom

formatDateTime renders event times in the server host's timezone rather than the event's, and in one case the rendered instant itself moves with the host's TZ.

Event	Rendered under `TZ=UTC`	under `TZ=Europe/Berlin`	Verdict
`DTSTART:...Z` (UTC)	`02:00 PM UTC`	`04:00 PM GMT+2`	misleading — instant right, the `=== 'UTC'` branch never actually fires
`TZID=Europe/Berlin` + VTIMEZONE	`12:00 PM UTC`	`02:00 PM GMT+2`	misleading — a user

Read the thread · 2026-08-14 · closed · 0 comments

Recurring events display the master DTSTART, not the occurrence in the queried range

Symptom

Asking "what's on my calendar next week" returns each recurring series exactly once, dated at its original series start — potentially years in the past — while the occurrence actually inside the queried window appears nowhere.

Probe, a FREQ=WEEKLY series with DTSTART:20260105T090000Z, queried for August 2026:

Found events: 1
### 1. Weekly standup
- **When**: January 5, 2026, 09:00 AM UTC to January 5, 2026, 10:00 AM UTC
- **Recurring**: FREQ=WEEKLY;BYDAY=MO

This is

Read the thread · 2026-08-14 · closed · 0 comments

Security: unvalidated `fields` map allows iCal/vCard property and component injection

Symptom

update_event, update_todo and update_contact accept a fields map that is validated only as z.record(z.string()) — no constraint on the key, none on the value. The map is passed to tsdav-utils' updateFields, which does updatePropertyWithValue(key.toLowerCase(), value) per entry, and the result is PUT to the server.

Because the caller of an MCP tool is an LLM that routinely handles untrusted text (a forwarded invite, a pasted email), "the caller wouldn't send that" is

Read the thread · 2026-08-14 · closed · 0 comments

All-day events not supported in `dav_create_event` and `dav_update_event`

The dav_create_event and dav_update_event tools cannot create or update all-day calendar events. They only support timed events, and fail if you try to anyway.

Expected Behavior

All-day events should be creatable (dav_create_event with date-only strings (e.g., 2026-08-12)), and editable ( dav_update_event with any parameter)

Actual Behavior

`dav_create_event`

Date-only input rejected: Passing date-only strings like 2026-08-12 fails validation:

{
  

[Read the thread](https://github.com/PhilflowIO/dav-mcp/issues/43) · 2026-08-11 · closed · external user · 0 comments

### addressbook_query returns "[object Object]" - type mismatch in formatContactList

## Bug Description

`addressbook_query` returns `"[object Object]"` instead of formatted contact results. The issue is a type mismatch when passing data to the `formatContactList` function.

## Steps to Reproduce

1. Configure dav-mcp with a CardDAV server (tested with Infomaniak)
2. Call `addressbook_query` with a valid `addressbook_url` and `filter`
3. The response contains `"[object Object]"` instead of contact data

## Root Cause

In the addressbook query handler, the addressbook object is p

[Read the thread](https://github.com/PhilflowIO/dav-mcp/issues/38) · 2026-02-24 · closed · external user · 0 comments

### Bug: update_todo, update_todo_raw, and delete_todo broken — wrong parameter name

## Bug

I discovered that `update_todo`, `update_todo_raw`, and `delete_todo` are all broken because they pass `{ todo: {...} }` to tsdav, but our PhilflowIO/tsdav fork expects `{ calendarObject: {...} }`.

This causes:

TypeError: Cannot read properties of undefined (reading 'etag')


## Affected files

1. **`src/tools/todos/update-todo-fields.js`** (line 102) — `todo:` → `calendarObject:`
2. **`src/tools/todos/update-todo-raw.js`** (line 34) — `todo:` → `calendarObject:`
3. **`src/tools/

[Read the thread](https://github.com/PhilflowIO/dav-mcp/issues/37) · 2026-02-13 · closed · 0 comments

### feat: Add freebusy_query tool (client-side implementation)

## Motivation
FreeBusy queries are useful for "When am I free?" queries.

## Problem with native CalDAV free-busy-query
The native CalDAV `free-busy-query` REPORT (RFC 4791) has **poor server support**:

| Server | Native FreeBusy Support |
|--------|------------------------|
| Google CalDAV | ❌ Not supported |
| iCloud | ❌ 500 Internal Server Error |
| Radicale | ❌ Not implemented (Issue #34 open since 2013) |
| Nextcloud | ⚠️ Bugs (Issue #50239, #6740) |
| Baikal | ⚠️ Users report problems |
|

[Read the thread](https://github.com/PhilflowIO/dav-mcp/issues/36) · 2026-01-20 · closed · 0 comments

### Upgrade Transport Layer: Migrate from deprecated HTTP+SSE to STDIO + Streamable HTTP

## Summary

The current MCP transport implementation uses **HTTP+SSE**, which has been **deprecated since protocol version 2024-11-05**. According to the [official MCP specification](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports), the recommended transports are now:

1. **STDIO** - For local integrations (Claude Desktop, Cursor, VS Code, npx usage)
2. **Streamable HTTP** - For remote/network integrations (n8n, cloud deployments, multi-client)

This issue tracks the mo

[Read the thread](https://github.com/PhilflowIO/dav-mcp/issues/35) · 2026-01-20 · closed · 0 comments

### Add `limit` parameter to query tools for token efficiency

## Problem

When users ask queries like "when is my next appointment?", LLMs tend to create very large time ranges (e.g., 2020-2030) which returns hundreds of events and wastes tokens.

**Example:**

User: "When is my next meeting?" LLM calls: calendar_query(time_range_start: "2020-01-01", time_range_end: "2030-12-31") Result: 500+ events returned → token explosion


## Proposed Solution

Add a `limit` parameter to all query tools:

### Affected Tools
- `calendar_query`
- `addressbook_quer

[Read the thread](https://github.com/PhilflowIO/dav-mcp/issues/34) · 2025-11-21 · closed · 0 comments

### SSE heartbeats break MCP client JSON-RPC parser

## Bug Description

SSE heartbeat messages are sent as JSON data events, which causes MCP clients to fail when trying to parse them as JSON-RPC 2.0 messages.

## Error in MCP Clients

LiveKit Agents (Python) and other MCP clients log continuous parsing errors:

ERROR mcp.client.sse - Error parsing server message ValidationError: 11 validation errors for JSONRPCMessage JSONRPCRequest.method: Field required JSONRPCRequest.jsonrpc: Field required JSONRPCRequest.id: Field required ...


## Ro

[Read the thread](https://github.com/PhilflowIO/dav-mcp/issues/31) · 2025-10-31 · closed · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/PhilflowIO/dav-mcp/issues).

Reported issues for dav-mcp

Most discussed

🐛 Critical: All TODO tools crash - client.fetchTodos is not a function

Summary

Root Cause

tsdav's Actual API:

Affected Files (5 locatio

addressbook_query requires URL while calendar_query/todo_query support multi-search

Proposed Solution

Code References

client.fetchTodos is not a function — tsdav 2.3.0 doesn't export fetchTodos

Bug: client.fetchTodos is not a function — tsdav 2.3.0 doesn't export fetchTodos

Environment

Symptom

Bug: Contact photos (PHOTO field) cause LLM context overflow

🐛 Problem

Location

Root Cause

LLM generates absurd time ranges in calendar_query despite required fields (120k token overflow)

Problem

Example Query

Root Cause

Query tools can be called without filters, defeating their purpose

Problem

Why This Is Bad

Missing tsdav-utils dependency causing Docker container crash

Bug Description

Error Message

Root Cause

LLM chooses update_event instead of update_event_fields despite PREFERRED label

Problem

Test Results

Most recent

fields.DTEND on a DURATION-based event produces an illegal object

tool-call-logger writes to stdout under stdio transport, corrupting the JSON-RPC stream

Symptom

Root cause

create_event and create_contact emit LF line endings; sanitizeICalString does not escape CR

Symptom

formatDateTime renders times in the server's timezone; Exchange TZIDs blank the date entirely

Symptom

Recurring events display the master DTSTART, not the occurrence in the queried range

Symptom

Security: unvalidated fields map allows iCal/vCard property and component injection

Symptom

All-day events not supported in dav_create_event and dav_update_event

Expected Behavior

Actual Behavior

dav_create_event

Bug: `client.fetchTodos is not a function` — tsdav 2.3.0 doesn't export `fetchTodos`

Security: unvalidated `fields` map allows iCal/vCard property and component injection

All-day events not supported in `dav_create_event` and `dav_update_event`

`dav_create_event`