# 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](/mcp/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:
```javascript
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](https://github.com/PhilflowIO/dav-mcp/issues/27) · 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](https://github.com/PhilflowIO/dav-mcp/issues/23) · 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](https://github.com/PhilflowIO/dav-mcp/issues/41) · 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:
```javascript
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](https://github.com/PhilflowIO/dav-mcp/issues/33) · 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:
```json
{
  "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](https://github.com/PhilflowIO/dav-mcp/issues/32) · 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](https://github.com/PhilflowIO/dav-mcp/issues/24) · 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](https://github.com/PhilflowIO/dav-mcp/issues/21) · 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](https://github.com/PhilflowIO/dav-mcp/issues/19) · 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](https://github.com/PhilflowIO/dav-mcp/issues/56) · 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](https://github.com/PhilflowIO/dav-mcp/issues/48) · 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](https://github.com/PhilflowIO/dav-mcp/issues/47) · 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](https://github.com/PhilflowIO/dav-mcp/issues/46) · 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](https://github.com/PhilflowIO/dav-mcp/issues/45) · 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](https://github.com/PhilflowIO/dav-mcp/issues/44) · 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:
   ```json
   {
     

[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).