Feature Request: Multi-Team/Workspace Support

[TechNickAI]

Summary

The ClickUp MCP server currently only supports a single team workspace through the CLICKUP_TEAM_ID environment variable. This significantly limits its utility for users who work across multiple ClickUp teams or need to manage different workspaces within the same session.

Current Limitation

The server is configured with a single CLICKUP_TEAM_ID in the environment configuration:

{
  "mcpServers": {
    "clickup": {
      "command": "npx",
      "args": ["-y", "@hauptsache.net/clickup-mcp@latest"],
      "env": {
        "CLICKUP_API_KEY": "xxxxx",
        "CLICKUP_TEAM_ID": "yyyyy",
        "CLICKUP_MCP_MODE": "write"
      }
    }
  }
}

This makes all operations scoped to a single workspace, which is insufficient for real-world usage patterns where users often:

• Work across multiple client teams
• Manage different projects in separate workspaces
• Need to coordinate between personal and professional ClickUp instances
• Switch between team contexts during the same session

Proposed Solution

Option 1: Dynamic Team Selection (Preferred)

Add optional team_id parameters to relevant tools, similar to how the Asana MCP server handles workspace selection:

// New tool for team discovery
getTeams(): Team[]

// Modified existing tools with optional team_id
searchTasks(terms?, team_id?)
searchSpaces(terms?, team_id?)
createTask(list_id, name, team_id?)
// etc.

When team_id is not provided, fall back to the configured CLICKUP_TEAM_ID for backward compatibility.

Option 2: Multi-Instance Configuration

Support multiple team configurations in a single server instance:

{
  "env": {
    "CLICKUP_API_KEY": "xxxxx",
    "CLICKUP_TEAMS": "team1:9014499987,team2:1234567890",
    "CLICKUP_DEFAULT_TEAM": "9014499987"
  }
}

Option 3: Runtime Team Switching

Add a setActiveTeam(team_id) tool that changes the active context for subsequent operations.

Benefits

1. Increased Utility: Makes the MCP server viable for multi-team environments
2. Better UX: Users can work across teams without multiple server instances
3. Real-world Alignment: Matches how users actually work with ClickUp
4. Backward Compatibility: Existing single-team configurations continue working

Technical Considerations

• The ClickUp API supports multi-team access with proper authentication
• Team IDs are already used in API endpoints (visible in URLs like https://app.clickup.com/9014499987/...)
• Most ClickUp API endpoints accept team context implicitly through the resource hierarchy

Alternative Workarounds (Current)

• Running multiple MCP server instances with different team IDs
• Manually reconfiguring and restarting the server when switching teams
• Using separate Claude projects for different teams

None of these workarounds provide a seamless multi-team experience.

Implementation Priority

High - This limitation significantly impacts the server's practical utility and adoption potential.

[Nemo64]

I understand where this is coming from. I would have preferred not to require the TEAM_ID at all, since it's annoying to figure out.

Let's go over your proposed solutions:

1. Dynamic Team

The note about backwards compatibility sounds a lot like an AI proposal. ;) You always have to tell Claude that backwards compatibility is irrelevant for MCP tool calls.

The problem with that solution is that it adds an additional tool call (more context is needed to run the MCP) and it adds a bit of confusion since it might not be totally clear what happens when you don't provide a team id.
This can both be somewhat solved by not introducing getTeams and making the teamId an enum populated with the users' workspaces. However, that still means that a search without knowing the team (e.g. what's on my to-do list today) requires one tool call per available team ~ which makes interactions slower and will cause some models to take shortcuts and stop checking.

2. Multi-Instance Configuration

I don't know what the default team id is supposed to do, but the idea behind that solution is probably the best.

I would actually argue that the TEAM_ID can be optional entirely, and it'll just use all teams when not specified.

The issue with that is that the search tool already has to cheat, since ClickUp isn't providing a search through the API. I'd have to fetch a lot of tickets over every team you have individually. I don't think this solution could handle more than three teams before hitting API rate limits, unless the amount of tickets per team fetched is reduced. That is totally an option, but I personally only have three teams and mostly use one, so I'm not deep enough in that use case.

3. Runtime Team Switching

This solution adds the most complexity. Searching over three teams will now require six tool calls, and resuming conversations will also break, since the MCP will shut down in between, and there isn't an indication of which session a tool call is coming from. Every tool call has to be more or less stateless.

Conclusion

Most tool calls already work without the team id.

If getTaskById is called with a ticket not in the current team, then it'll do as long as you have access. The only problem is that the time tracking will fail, since it fetches time entries for all your team members.
Most IDs are universally unique, so any tool call requiring a space_id or task_id will just work without modification right now.

The main problems are just the search tools and the time tracking.

• Time Tracking can also be solved by just checking which team a ticket belongs to.
• Search will require some intelligent brute forcing to create search indices over multiple teams without hitting rate limits.

My personal problem is that I don't have a realistic multi-team setup. So if someone wants to implement and test it, I'd be happy to review it.