π What's the bug?
twprojects-list_tasks and twprojects-get_task fail whenever the Teamwork API response contains a date-only value (e.g. a task due date like 2026-10-13). The server decodes timestamps with the RFC3339 layout only, so any YYYY-MM-DD field aborts the entire response.
Error: MCP error 0: failed to list tasks: failed to handle response:
failed to decode list tasks response: parsing time "2026-10-13" as
"2006-01-02T15:04:05Z07:00": cannot parse "" as "T"
Because one bad record poisons the whole page, list_tasks and get_task are unusable for any project where at least one task has a due date β which in practice is nearly every active project.
β
What should happen?
Date-only values in API responses (e.g. a task due date of 2026-10-13) should decode successfully β the decoder should accept both 2006-01-02 and RFC3339 layouts. Ideally a single malformed record should not fail the entire response.
β What actually happens?
The response decoder only accepts full RFC3339 timestamps, so any date-only field aborts the whole call. Because one bad record poisons the entire page, list_tasks and get_task are unusable for any project where at least one task has a due date β in practice, nearly every active project. Our only workaround was reconstructing task state from list_activities and comment threads.
π How to reproduce
- Have a project with at least one task that has a due date (ours: project
909851).
twprojects-list_tasks(project_id=909851) β decode error (see error output).
- Also fails scoped to a tasklist (
tasklist_id=2672970) and with completed_after filters β the failing value changes (2025-10-20, 2025-12-22) but the error is identical.
twprojects-get_task(id=<task with due date>) fails the same way.
Unaffected in our testing: list_tasklists, list_activities, list_notebooks, list_comments.
π» Code sample
twprojects-list_tasks(project_id=909851)
π¨ Error message/output
Error: MCP error 0: failed to list tasks: failed to handle response:
failed to decode list tasks response: parsing time "2026-10-13" as
"2006-01-02T15:04:05Z07:00": cannot parse "" as "T"
πΉ Go version
Unknown (hosted connector)
π¦ Server version
tbd
π» Operating System
macOS
π Authentication method
OAuth2
π Environment
π Additional context
Observed via Claude/Cowork's MCP tool-calling interface. This is a response-side decoding failure, distinct from request-side parameter validation issues.
π§ Troubleshooting checklist
π What's the bug?
twprojects-list_tasksandtwprojects-get_taskfail whenever the Teamwork API response contains a date-only value (e.g. a task due date like2026-10-13). The server decodes timestamps with the RFC3339 layout only, so anyYYYY-MM-DDfield aborts the entire response.Because one bad record poisons the whole page,
list_tasksandget_taskare unusable for any project where at least one task has a due date β which in practice is nearly every active project.β What should happen?
Date-only values in API responses (e.g. a task due date of
2026-10-13) should decode successfully β the decoder should accept both2006-01-02and RFC3339 layouts. Ideally a single malformed record should not fail the entire response.β What actually happens?
The response decoder only accepts full RFC3339 timestamps, so any date-only field aborts the whole call. Because one bad record poisons the entire page,
list_tasksandget_taskare unusable for any project where at least one task has a due date β in practice, nearly every active project. Our only workaround was reconstructing task state fromlist_activitiesand comment threads.π How to reproduce
909851).twprojects-list_tasks(project_id=909851)β decode error (see error output).tasklist_id=2672970) and withcompleted_afterfilters β the failing value changes (2025-10-20,2025-12-22) but the error is identical.twprojects-get_task(id=<task with due date>)fails the same way.Unaffected in our testing:
list_tasklists,list_activities,list_notebooks,list_comments.π» Code sample
π¨ Error message/output
πΉ Go version
Unknown (hosted connector)
π¦ Server version
tbd
π» Operating System
macOS
π Authentication method
OAuth2
π Environment
π Additional context
Observed via Claude/Cowork's MCP tool-calling interface. This is a response-side decoding failure, distinct from request-side parameter validation issues.
π§ Troubleshooting checklist