Feature Requests

Please search first before posting to help others find and vote for your idea!
MCP custom fields cap limitations
My Claude is frequently running into errors using the clickup_get_custom_fields tool: one of our custom fields is >40KB (lots of really specific epic names) and the server is truncating that field at column 41,769. Would you consider increasing that limit? Alternatively, could you add an include_options: true|false param on the clickup_get_custom_fields tool so we can exclude if needed? Option lists are ~90% of that payload and the overwhelmingly common need is just the field ID. More details from Claude: Bug: clickup_get_custom_fields (with list_id or folder_id) and clickup_get_task (with include: ["custom_fields"]) return an SSE frame whose JSON payload is truncated mid-string. The client fails with: Failed to parse SSE message: Invalid JSON: EOF while parsing a string at line 1 column 41769 Deterministic — the identical call truncates at the identical column on every retry, across sessions and days. Different calls truncate at different offsets (41769 and 53706 observed), so it is not a fixed size cap. There is no partial result and no error object; the tool is simply unusable for these scopes. Smaller calls on the same connector succeed (space-scoped custom fields ~15KB, 100-task filter_tasks ~36KB, get_workspace_members ~25KB). Other remote MCP connectors in the same client return 290KB+ responses without issue, so this looks connector-side rather than a client or transport limit. Contributing factor: this space has large dropdowns — one Epic field with 93 options, Area with 32. List/folder scope stacks space-level fields plus list-level ones, which is where it tips over. Feature request: add a way to fetch field _identity_ without the option payloads — e.g. include_options: false, or a fields name filter on clickup_get_custom_fields. Dropdown options are the overwhelming majority of the bytes and most callers only need the field ID to write a value. This would sidestep the truncation entirely and cut response size by ~90% for the common case. Secondary: even with that, oversized responses should fail with a structured MCP error rather than a truncated JSON string, so clients can retry or degrade instead of hard-crashing on a parse error.
0
·
ClickUp AI
Load More