# ClickUp in ChatGPT for a customer success team

> Two decisions put ClickUp in ChatGPT for a customer success team: whose account each call runs on, and which ClickUp tools the model never sees.

**TL;DR** Putting ClickUp in ChatGPT for a customer success team comes down to two decisions in Elaichi. First, identity: each CSM connects their own ClickUp account, so ClickUp's own sharing decides what each call can see. Second, scope: block the ClickUp delete tools and the guest and user tools on the team's role, then share a template at use so every person stamps a toolbox bound to their own connection.

## How do you set up ClickUp in ChatGPT for a team?

Two decisions, then menu paths. Whose ClickUp account each call runs on, and which ClickUp tools the model can reach at all. Both are instances of a general MCP governance problem, not something specific to ClickUp. Any time you connect a chat client to a multi-user app through MCP, you have to decide two things. First, identity resolution: which backend credential a given call executes under. Second, tool surface: which of the connector's available operations are reachable at all. Setting up ClickUp in ChatGPT for a whole team is a governance question before it is a configuration one.

The situation is familiar. A customer success team runs client onboarding in ClickUp, one space or folder per account. The CSMs want to ask ChatGPT what is overdue on the Acme rollout. They also want it to update a task status, and to draft the weekly summary from the list. One person can do that today by signing in to ClickUp's own hosted server. Doing it for eight CSMs, with client data sitting in those spaces, is where the shape changes. Identity resolution and tool surface now have to hold across eight people instead of one.

This playbook uses Elaichi, a governed MCP control plane, as the worked example. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi serves every connected account through one organization-wide endpoint, `POST https://api.elaichi.ai/mcp`, behind OAuth. OAuth is the browser sign-in flow that issues a client a standing, revocable permission to call on a person's behalf. A static API key, by contrast, has no per-person revocation and no expiry tied to a session. [ClickUp](/connectors/clickup/) is one of the 600+ connectors in the catalog.

The order of work: write the restriction first, build and share a template second. Then let each CSM connect ClickUp, and add the endpoint in ChatGPT last. Skipping ahead and connecting accounts before the restriction exists leaves an unrestricted delete tool live in production before anyone notices.

## Whose ClickUp account does each call run on?

Whichever connection the call resolves to. A connection shared with the team runs on its owner's credential, so every grantee's call reaches ClickUp as that one account. Get it wrong and permissions widen for everyone downstream of the share.

That matters more in ClickUp than in most apps, because ClickUp spaces are usually where client separation lives. If one ops lead connects ClickUp and shares the connection with the customer success team, ClickUp evaluates the ops lead's permissions on every call. A CSM who cannot open the Acme space in ClickUp can read it through that connection, in ChatGPT, with nothing misconfigured. The share is working as designed. The failure is in the sharing decision, not the software.

For a customer success team, pick the other shape:

- **Per-person connection (recommended for this case).** Each CSM connects ClickUp in Elaichi with their own ClickUp account. The Member role already holds `connection:create`, so nobody waits on an admin. ClickUp's own sharing then decides what each call can see, per person, with no second permission model to keep in step.
- **Shared connection (correct only for a deliberate single view).** A single reporting account that sees every client space, shared at `use` for a weekly rollup, is a reasonable thing to own. It should be a named decision with a named owner, not the default because it was the first thing someone set up.

Rule of thumb: some apps already enforce per-record access control, such as ClickUp spaces, Zendesk ticket permissions and [Salesforce sharing rules per rep](/blog/sales-team-chatgpt-salesforce-accounts/). Default to per-person connections there, and let that app's permission model do the work. Only use a shared connection when you want a view that deliberately ignores those boundaries.

## Which ClickUp tools should a customer success role never reach?

The destructive ones and the access-granting ones. Block ClickUp's delete tools for tasks, lists, folders and spaces, plus the tools that create, update or remove guests and users.

| Tool category | Example ClickUp operations | Why block for CSM role |
|---|---|---|
| Deletes | delete task, delete list, delete folder, delete space | Irreversible; a misread instruction ("clear out the old onboarding list") becomes data loss, not a conversation to correct |
| Guest/user management | add guest, remove guest, create user, change user role | Looks like a routine task update in a transcript but is actually an access-control decision: it shares client work outside the company |
| Reads (task, list, comment) | get task, list tasks, get comments | Needed for the core use case; leave open |
| Task/comment writes | update task status, create comment, update due date | Needed for the core use case; leave open |

The deletes are the obvious half of the table. The guest tools are the half teams forget. "Add a guest to this task" reads exactly like "update this task", in both the UI and in a model's tool-call log. There is no visual or semantic marker that distinguishes a data operation from an access-grant operation unless you block it explicitly.

A restriction is the rule for which connectors and tools a target may reach. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. Write the block against the role the customer success team holds, which on the Gold plan can be a custom role. Blocks beat allows inside the winning layer. A block matches the tool's advertised name, or the operation pinned against the catalog when the rule was written. An allow matches the pinned operation only. That asymmetry has its own writeup in [why blocks match names and allows do not](/blog/block-matches-name-allow-matches-operation/).

A restricted tool is invisible, not merely refused. It is withheld from `tools/list` and from the `search_tools` index before the search runs, so the model never learns the tool exists. There is no "I tried to delete it but was denied" moment for the model to reason around. A role or restriction change takes effect within about two minutes.

Resist the urge to write an allowlist instead, unless you mean it. The allowlist stage activates on the presence of an allow rule, not its contents. So an allow rule naming nothing denies everything, which locks the role out of every tool. For a team whose work is open-ended across client spaces, a short block list ages better than a long allow list. A long allow list runs to dozens of entries, one per permitted operation, and needs updating every time the connector adds a tool. The cases where one or the other wins are set out in [restricting one tool or the whole app](/blog/per-tool-vs-per-app-restrictions/).

## Why share a template instead of one toolbox?

Because a template carries no connection and a toolbox does. Share a template at `use` and each CSM stamps their own toolbox, bound to their own ClickUp account. Share one toolbox at `use` and every call runs on the connection pinned in its entries, which belongs to the owner, not the grantee.

| Object | Carries a connection? | What sharing it does |
|---|---|---|
| Template | No | Each grantee stamps their own toolbox, pinned to their own connections |
| Toolbox | Yes (per entry) | Every grantee's calls run on the connection the owner pinned |

A template in Elaichi is a tool list with renames, defaults and frozen parameters, and no connection anywhere in it. Build one holding the ClickUp reads a CSM needs, plus task and comment create and update. Share it with the customer success team at `use`.

When a CSM stamps it, the new toolbox belongs to them. Each entry is filled from connections that person can use, with them recorded as the delegator. An entry with no usable connection sits as "needs connection", exactly what a CSM who has not connected ClickUp yet will see. The fix is to connect ClickUp and re-pin.

The trade-off is real: stamping copies the template once, at that moment. A later edit to the template never reaches a toolbox already stamped. Adding a tool for the team means editing each toolbox individually or asking people to re-stamp. For an 8-person team, that is 8 manual touches per template change, a real maintenance cost, not a hypothetical one. That is the price of per-person connections. For a team handling client data it is usually worth paying, against an alternative of one shared connection and zero per-person isolation.

## How does an admin add the endpoint in ChatGPT?

One URL, added once, then each CSM signs in and gets their own OAuth grant. Nobody types a token and nobody gets a personal URL.

As of this writing, full MCP support including write actions in ChatGPT is in beta for Business, Enterprise and Edu plans. On Business, only admins can enable developer mode (source: [OpenAI's help center, "Developer mode and MCP apps in ChatGPT"](https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt)). Check that page directly before rollout, since OpenAI states the feature, UI, and permission model may change. The admin creates the app under Workspace settings, then Apps, then Create, provides the endpoint, clicks Scan Tools, completes the OAuth prompt, and publishes it. It then appears in members' Apps settings labeled "custom."

The endpoint is `https://api.elaichi.ai/mcp`, typed exactly. With a trailing slash it answers 404 and never starts sign-in.

Each CSM then signs in and lands on Elaichi's consent screen with four checkboxes:

1. Read your organization's data
2. Create and change data
3. Run your connected tools
4. Delete data and remove access

Delete is never pre-ticked, and for this team it should stay unticked. There is no legitimate case for a CSM's ChatGPT session to need delete-and-revoke permission. With "run your connected tools" ticked, a second step asks which toolboxes to expose. Choose "only the ones I pick" and select the stamped ClickUp toolbox, rather than "all my tools". All my tools would expose every toolbox the person has access to, including ones unrelated to this rollout.

One behavior to flag in advance: connected tools are never listed in `tools/list`, however few there are. The model finds a ClickUp tool with `search_tools` and runs it with `execute_tool`. A CSM may open the app list, see no ClickUp tools listed, and file a support ticket. That is normal behavior, not a broken connection. The step-by-step walkthrough is in [connecting Elaichi to ChatGPT](/blog/connect-elaichi-to-chatgpt/), and the sign-in failures worth recognizing are listed in [fixing OAuth errors](/blog/mcp-oauth-errors/).

## Who can reach a ClickUp connection once it is in use?

Everyone the connection itself is shared with, plus everyone holding `use` on a toolbox that pins it. A member sees only what they own or what was explicitly shared with them. No organization-level permission widens that listing, owners and admins included. This is a deliberate design choice. Visibility into a connection and capability to use it are separated, so granting the latter never silently grants the former.

The second clause is the one that surprises people. Pinning a connection into a toolbox and sharing the toolbox hands out the *capability* without handing out the *connection*. The grantee runs the entry and cannot open, see, or share the connection underneath it. The call still reaches ClickUp as the owner's account. They just cannot inspect or redirect it.

So for a per-person setup, the rule is short: each CSM leaves their own ClickUp connection unshared. If someone shares theirs with the whole team, every teammate's "all my tools" grant picks it up. That includes connections shared *after* the grant was originally made, since the resolution happens at call time, not grant time.

Each toolbox entry also records who pinned it, re-checked on every call. Worked example: a CSM pins their ClickUp connection into a shared toolbox, then goes on leave and is suspended via SCIM. From that point, every grantee's call against that entry resolves as unmet until someone currently present re-pins it with their own connection. The toolbox does not silently fail over to another account. Offboarding surfaces these as a non-blocking warning. A private connection pinned by a toolbox its owner shared blocks removal, until an administrator decides what happens to it.

Timing differs by layer. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. A role or restriction change takes effect within about two minutes.

## What does the audit trail show after a task changes?

Elaichi writes one entry per tool-call attempt, succeeded or failed, naming the ClickUp account actually reached. The recorded connection comes from the execution, not from the intent. So "which workspace did it write to" has a verifiable answer rather than an inferred one.

Concretely: you can prove that a CSM's ChatGPT session updated a specific task on their own ClickUp account. It happened at a specific timestamp, via a specific tool call. You cannot read the comment text out of the audit trail. The log records that a write happened and to what object, not the content written, by design.

A call arriving from ChatGPT is recorded with the surface `mcp` and the OAuth client named. ChatGPT's client identity is marked verified, because its redirect URIs prove it. The `ai_assistant` actor kind marks the in-app Elaichi Agent only. Do not expect to find it on ChatGPT-originated rows. The approval line reads "allowed by the access ChatGPT was granted." Over MCP, the grant the person approved during OAuth consent is the human decision being referenced, not a per-call approval.

A blocked tool is never advertised, so the audit signal for "deletes are off" is absence rather than a stream of denied attempts. The evidence is the restriction itself, plus the absence of any delete in the trail. A compliance reviewer can hold the free read-only Auditor seat to check both the restriction and the trail. That is the shape described in [proving AI actions in access review evidence](/blog/shadow-ai-security-lead-access-review-evidence/).

## When is ClickUp's own MCP server enough?

When ClickUp is the only system your team needs inside ChatGPT, and per-user ClickUp permissions are the whole access control you want. In that case, connect ClickUp's server directly and stop here. Adding a control plane buys you nothing in a single-app, single-permission-model setup.

ClickUp hosts a server at `https://mcp.clickup.com/mcp`, connected via OAuth. ClickUp's developer docs list the supported clients. They name Claude, ChatGPT, Cursor, VS Code, Windsurf and Microsoft Copilot Studio ([ClickUp developer docs, "Connect an AI assistant to ClickUp's MCP server"](https://developer.clickup.com/docs/connect-an-ai-assistant-to-clickups-mcp-server-1), checked October 2026). Per ClickUp's own guide, checked October 2026, it is available on all plans including Free Forever. Calls stay within the account's existing permissions. Personal API keys and access tokens are not accepted as credentials. Without the Everything AI add-on, daily call volume is capped by plan. The cap runs from 100 calls/24h on Free Forever to 5,000 calls/24h on Enterprise ([ClickUp blog, "How to use ClickUp's MCP server"](https://clickup.com/blog/how-to-use-clickup-mcp-server/)). Verify current caps and plan terms directly with ClickUp before relying on these numbers. Usage limits are the kind of detail vendors change without much notice.

| Need | ClickUp's native MCP server | A control plane (Elaichi or similar) |
|---|---|---|
| Single app (ClickUp only) | Sufficient | Unnecessary overhead |
| Multiple apps in one chat client (ClickUp + Zendesk + Salesforce) | Not described on ClickUp's pages | One endpoint, one policy layer across connectors |
| Tool-level restriction beyond ClickUp's own role permissions (e.g., block deletes for a role that otherwise has delete access in ClickUp) | Not described on ClickUp's pages | Supported via restrictions |
| Centralized audit trail across apps | Not described on ClickUp's pages | Single trail across all connected apps |
| Offboarding | Deprovision in ClickUp or your IdP; no secondary layer to clear | Removing someone in the control plane ends access *through the control plane*; the underlying ClickUp account still needs separate deprovisioning |

Be precise about that last row: removing someone in Elaichi ends their access through Elaichi. Their ClickUp account still exists and still needs to be deprovisioned in ClickUp or through your identity provider. A control plane does not replace offboarding discipline; it adds a layer that also needs clearing.

For the wider picture of what sits between AI clients and company apps, start with [what an MCP control plane is](/blog/what-is-an-mcp-control-plane/). For the same two decisions made in a support queue, read how a [support team gets Zendesk without bulk deletes](/blog/support-team-claude-zendesk-tickets/). The apps on offer are listed in the [connector catalog](/connectors/), and the team-by-team shapes are on [use cases](/use-cases/).

## FAQ

### Can each person use their own ClickUp account when ClickUp is connected to ChatGPT through Elaichi?

Yes. Each person connects ClickUp in Elaichi with their own ClickUp account, and an admin shares a template, a tool list that carries no connection, with the team at use. Each person stamps their own toolbox from that template, and stamping binds every entry to a connection that person can use. A toolbox shared directly is the opposite case: every grantee's call runs on the connection pinned in its entries, which belongs to the owner.

### How do you stop ChatGPT from deleting ClickUp tasks?

Write a restriction on the role the team holds that blocks the ClickUp delete tools, such as delete_a_clickup_task_by_id, delete_a_clickup_list_by_id, delete_a_clickup_folder_by_id and delete_a_clickup_space_by_id. In Elaichi a blocked tool is withheld from the tool list and from tool search before the search runs, so the model never learns it exists. Restrictions target a role or a user, and a change takes effect within about two minutes.

### Why block ClickUp's guest tools for a customer success team?

Adding a guest to a task shares client work outside the company, which is an access decision rather than a project update. Blocking create_a_clickup_guest, clickup_guests_add_to_task, create_a_clickup_user and their update and delete counterparts keeps that decision with whoever administers the ClickUp workspace, instead of putting it one sentence away in a chat window.

### Does ClickUp have its own MCP server, and when is it enough?

Yes. ClickUp hosts a server at https://mcp.clickup.com/mcp, connected with OAuth, and its own guide dated 8 September 2026, checked October 2026, says it is available on all plans including Free Forever and that what an AI client does stays within your account's existing permissions. It is enough when ClickUp is the only system your team needs in ChatGPT and per-user ClickUp permissions are the only control you want. A control plane adds one address across apps from different vendors, restrictions written once for a role across those apps, and one audit trail across them.

### What does Elaichi's audit trail record for a ClickUp call made from ChatGPT?

Elaichi writes one entry per tool-call attempt, succeeded or failed, naming the ClickUp account actually reached, taken from the execution rather than the intent. The entry holds the operation and tool, the connection, the classification, whether it was approved, the outcome and an error code only. Argument names and counts are logged; argument values never are. The entry records the surface as mcp and names the OAuth client, and ChatGPT's name is marked verified because its redirect URIs prove it.

## Read next

- [Zendesk for support agents, minus bulk deletes](/blog/support-team-claude-zendesk-tickets/) — Zendesk for support agents in Claude: let them read and update tickets, block deletes and bulk sends, and give the lead one exception.
- [Each rep's own Salesforce access, in ChatGPT](/blog/sales-team-chatgpt-salesforce-accounts/) — Salesforce access in ChatGPT works per rep: each call runs on the rep's own connection, so Salesforce's sharing rules decide which accounts they see.
- [Which Notion workspace did ChatGPT write to?](/blog/product-team-chatgpt-notion-workspace/) — Elaichi's audit trail names the Notion workspace each ChatGPT call reached. Pin the connection or database first, and the other workspace is out of reach.