is the 300/24h limit for all workspace members, or is it per user authenticated to the server?

If the 300/24h limit applies to all workspace members, then our team still cannot use MCP.

I've been using the MCP server since it's initial rollout, and I am happy with all of the various features and how it has progressed.

The one issue, and it is a major one, is the rate limiting. 300 calls in 24 hours is not nearly sufficient- specifically when using it as a project management tool and managing a very large project.

I'd encourage you to raise the rate limits to something more reasonable, otherwise you risk AI-savvy customers creating their own tooling that uses the MUCH more reasonable API limits (1,000 requests PER MINUTE).

We'd want full CRUD access to the task URL links through the MCP. We have additional context from other apps here, which the agent can't see now. And I'd like for the agent to attach its GitHub PR to the task when it's done. Currently this can only be done through polluting the task description with the URL, whereas a human can cleanly add a URL link to the task via the task view sidebar.

Hello,

I believe there's a very high impact BUG on ChatGPT's MCP client.

While Claude works fine with the MCP as far as we use it, ChatGPT/Codex can't seem to work with custom fields. It can't read them, can't set values on them.

It seems that ChatGPT's MCP client doesn't have a way to get the custom fields schema when getting a task. Claude uses: include: ["custom_fields"] and gets the related schema, when I specifically instructed ChatGPT to use that it returned an error so this must be an MCP client bug.

It keeps compalining that all it can read is "custom_fields": 1 without any schema whatever it tried.

A silly workaround I figured out so far is that if I manually (or with Claude) find the custom field's UUID and instruct ChatGPT to update this custom field (it's a relationship field back to a clients list) using the specific UUID it succeeds in adding a correct value.

But then there is no way of ChatGPT reading this value back. The clickup_get_task still returns "custom_fields": 1 without any way to expand the schema.

Overall Claude reports 53 tools available, and ChatGPT 32 tools. That's quite a gap there. Comparing these tools it seems ChatGPT doesn't get tools for comments, reminders or task filtering! And that is apart from the actual tools that ChatGPT has but are poor in design (like the custom fields not working).

Are you actively working on improving the MCP client for ChatGPT/Codex?

Hey, thanks for working on the MCP, enjoying it a lot so far! However, we've noticed that ClickUp MCP connector doesn't reflect subfolder nesting.

clickup_get_workspace_hierarchy does not represent ClickUp's subfolder feature correctly. When a folder is created inside another folder, the hierarchy call returns it as a top-level folder directly under the Space, sibling to the parent folder - not as a child of it. The parent folder is reported with empty children, even though the subfolder visibly exists inside it in the ClickUp UI.

Reads/writes by direct ID (clickup_get_folder, clickup_create_document, etc.) work correctly against the actual subfolder - so the data itself is fine, it's specifically the hierarchy/tree endpoint that flattens subfolder relationships. This makes the tool unreliable for auditing or navigating any workspace that uses nested folders, since the reported structure doesn't match reality.

Love the functionality overall, great work! I recently filed a specific request for finer-grained Doc editing here: [https://feedback.clickup.com/public-api/p/mcp-server-append-partial-edit-operations-for-docs]

Context: We use the official ClickUp MCP server (public beta) in an automated workflow that posts release notes to a Docs page and manages task comments. Two missing operations force awkward, risk-prone workarounds. Both have direct REST API equivalents already, so this is about MCP tool coverage, not new platform capability.

The MCP exposes create_comment but no way to edit a comment. When an automated comment needs a correction or a status sync, the only option is to delete-and-recreate (losing the comment's thread position, ID, and reactions) or leave a stale comment and append a new one. The REST API already supports PUT /comment/{comment_id} — please surface it as an update_comment MCP tool.

update_document_page replaces the entire page body. To add one section to a long, multi-section page we must read the whole page and rewrite it verbatim. This is risky: any content added by another user between our read and write is silently overwritten, and any markdown round-trip drift silently mutates historical sections of the doc. Please add either an append mode (append content to the end of a page) or a content-edit/patch operation that targets a section without resending the full body. This makes the MCP safe for collaborative, append-only docs like changelogs and release notes.

Why it matters: Both are common automation patterns (changelogs, release notes, status updates, bots correcting their own output). Today the full-replace behavior makes the Docs tools unsafe to use unattended on any shared page, and the lack of comment-edit makes comment automation lossy.

Thanks - happy to share our concrete use case (automated release-notes posting) if useful.

Bug/request: expose threaded task comment replies via the ClickUp MCP server.

Currently, returns top-level task comments and includes , so the agent can see that a comment has threaded replies. However, in my MCP client there does not appear to be a way to fetch those replies, even when I have the parent comment ID.

Expected behavior: expose a / tool matching the ClickUp API endpoint , and document how agents should call it after seeing .

This matters because agents summarizing task context miss important decisions hidden in threaded replies.

Grok needs to be supported, for sure

I'd love to see setting sprint points supported.