Project Time Visibility

A worked example of an advanced workflow: a Claude-managed scheduled agent that, once a week, reads the time logged against a set of ClickUp projects and flags the ones running noticeably over or under their expected hours, publishing a digest to Slack. It is strictly read-only and never writes a time entry. There are no servers and no code to deploy: the agent is a saved prompt plus a schedule plus two MCP connectors, running in Claude’s cloud.

This workflow is ClickUp-only. Time tracking is a ClickUp feature exposed through its MCP server. Linear has no native time tracking, and Asana’s Workload feature exists in their product but is not exposed through their MCP layer. If your team runs project management on Linear or Asana instead of ClickUp, this specific workflow does not have an equivalent yet on that tool.

What it builds

The finished workflow runs unattended on a weekly cron. Each run it pulls the logged time entries across a set of ClickUp projects for the trailing week, totals hours per project, compares the total against a per-project expected-hours baseline you set when building the routine, and notifies your team with a digest of which projects are running over or under that baseline.

Prerequisites

Before building, your Claude account needs all of the following:

Requirement	Notes
Conduit connector	Connected in claude.ai (https://conduit.wyre.ai/v1/mcp). Provides the ClickUp time-tracking tools. See Connecting an AI Client.
ClickUp connected in Conduit	The vendor connection is read-scoped today — the routine uses only read tools, no write scope is available or required.
Slack connector	The first-party Slack connector connected in claude.ai (https://mcp.slack.com/mcp). Provides slack_create_canvas and slack_send_message.
Scheduled routines access	Created via the /schedule capability; managed at claude.ai/code/routines.
A destination Slack channel	e.g. #sw-dev. The Slack connector must have access to it.
The Space, Folder, or List ID(s) for each project you want covered, and an expected-hours-per-week baseline for each. ClickUp’s time-tracking tools query by that scope, not by a “project” object directly — see the build prompt.

Known gotchas

These are the things worth knowing before you build, based on what’s confirmed about ClickUp’s MCP server today rather than a live build.

• This guide does not hardcode the exact tool identifiers, unlike the other guides on this page. ClickUp’s MCP server requires an authenticated connection even to list its own available tools, so the literal on-the-wire tool names (the equivalent of qbo__qbo_invoices_list or datto-rmm__datto_list_devices in the other guides) haven’t been confirmed independently of a live connect. What is confirmed, from ClickUp’s own published MCP documentation: a tool that returns time entries for a single task, and a separate tool that returns time entries aggregated across multiple tasks within a Space, Folder, or List — the one this workflow needs. When you build this routine, ask Claude to list its available ClickUp tools first and use the one matching “get time entries for multiple tasks” or equivalent; don’t assume a specific string.
• ClickUp’s connector is read-first — no write tools are available. The vendor connection’s OAuth scope is read only; write access to ClickUp (starting timers, adding manual entries) is deliberately not requested. This workflow only reads time-entry data, which matches that scope exactly — there’s nothing to accidentally overreach into.
• ClickUp enforces a real rate limit: 1,000 requests per 15-minute window. Confirmed directly against mcp.clickup.com, via RateLimit-* response headers on a live request. A weekly sweep across a reasonable number of projects sits well inside that window, but if you extend this routine to cover a large number of Spaces individually rather than one aggregated query per scope, keep the request count in mind.
• Time entries are a real cost signal, not a productivity score. Frame the digest around “this project logged more or fewer hours than expected,” not “this person worked less than expected.” The data doesn’t support judging individuals, and using it that way is a fast way to make people stop logging time accurately.
• Faster-than-hourly cadences are rejected. The scheduler will not accept a cron more frequent than once an hour. A weekly cron is well within that limit.
• permitted_tools must be populated per connector. A routine with a connector attached but an empty permitted_tools list runs with no tools and silently does nothing — no error, no output. List the exact tool names the routine needs, confirmed from the live tool list at build time.
• A routine reaches only its attached connectors. The routine sandbox blocks arbitrary network egress, so notifications must go through the Slack connector’s tools, not an outbound webhook. Attach every connector the workflow touches.

The one-shot build prompt

With the connectors above in place, paste this to Claude. Because the exact ClickUp tool identifiers aren’t hardcoded here (see the gotcha above), the first step has Claude discover them from your live connection before building the routine.

Build me a scheduled Project Time Visibility agent. Do all of this end to end:

1. Confirm the Conduit connector works and ClickUp is reachable. List the
   available ClickUp tools and identify: (a) the tool that returns time
   entries aggregated across multiple tasks within a Space, Folder, or List
   (this is the one the routine needs), and (b) confirm no write-scoped
   ClickUp tools are present — the connection should be read-only. Record
   the exact tool name(s) you find; use those exact names in the routine,
   not a guessed name.
2. Ask me which Space, Folder, or List ID(s) to cover, and the expected
   weekly-hours baseline for each. Record them — they get baked into the
   routine prompt.
3. Confirm a Slack connector is connected. Note the destination channel name
   and ID. If Slack does not show in the /schedule connector list, read its
   connector_uuid and url from an existing routine that already uses Slack
   (RemoteTrigger list -> get -> mcp_connections).
4. Create a Claude-managed scheduled routine named "Project Time Visibility":
   - Schedule: weekly, cron "0 12 * * 1" (Monday 08:00 America/New_York =
     12:00 UTC). Faster-than-hourly cadences are rejected.
   - Attach TWO connectors, each with permitted_tools populated:
       * Conduit: the ClickUp time-entries tool you confirmed in step 1 —
         READ only. Do not attach any ClickUp write tool.
       * Slack: slack_create_canvas, slack_send_message
     An empty permitted_tools list = the routine runs with no tools.
   - Routine prompt: every run, pull the trailing week's time entries for
     each configured scope, total the hours, compare against that scope's
     baseline, flag anything running materially over or under, build a
     digest, publish it to Slack. Use the routine prompt below, substituting
     the exact tool name from step 1 and your own scope IDs and baselines.
5. Trigger a manual run and verify: a Slack message or canvas was posted,
   and the hours reported for one project roughly match what you'd expect
   from a manual check in ClickUp.

The resulting routine prompt

This is the lean prompt the build process installs into the scheduled routine itself. Substitute the exact ClickUp tool name confirmed at build time, your own scope IDs, hour baselines, and destination channel.

You are the Project Time Visibility agent. You run weekly, READ-ONLY against
ClickUp. You must NEVER start, stop, or create a time entry — only read.

Projects to check (scope ID - name - expected weekly hours):
- <scope-id-1> - <project name 1> - <N> hours
- <scope-id-2> - <project name 2> - <N> hours
- ... one line per project ...

1. For each scope above, call <exact ClickUp time-entries tool name from
   build step 1> for the trailing 7 days, scoped to that Space, Folder, or
   List ID.
2. Sum the logged hours per project for the week.
3. Compare each project's total against its expected weekly hours. Flag a
   project if it's more than 20% over or 20% under its baseline.
4. Build a digest: project name, hours logged, expected hours, percent
   variance, flagged or not. Sort flagged projects to the top.
5. slack_send_message to the destination channel with the digest. If the
   digest is long, slack_create_canvas instead and post a one-line summary
   linking it.
6. If a scope returns no data or an error, list it in a "could not check"
   section instead of skipping it silently. Never estimate or fabricate
   hours for a project that couldn't be read.

Frame this as a project-health signal, not an individual performance score
— the digest reports on projects, not people.

How it works

ClickUp only, stated plainly

Time tracking is a ClickUp product feature, exposed through ClickUp’s own MCP server. It isn’t a general PM-tool capability: Linear has no native time tracking at all, and Asana’s Workload feature isn’t reachable through Asana’s MCP layer. This workflow doesn’t generalize across project-management tools the way some other advanced workflows generalize across RMMs or PSAs — it’s specific to teams running ClickUp.

A weekly cadence, by design

Time variance is a slow-moving signal — a project drifts over or under its expected hours across days and weeks, not minutes. The routine runs every Monday morning so the digest is waiting before the week’s planning conversation happens.

Read-only by construction, matching the connector’s real scope

ClickUp’s vendor connection in Conduit grants read access only — write scope for starting timers or logging entries was deliberately not requested. The routine’s permitted_tools list can only ever contain read tools as a result, so there’s no path by which a run could create or alter a time entry. The safety guarantee lives in the connector’s actual OAuth scope, not just the prompt.

Tool names are discovered at build time, not hardcoded here

Every other advanced workflow guide on this site names its exact MCP tool identifiers, because each was built and verified against a live connection. This one doesn’t, because ClickUp’s MCP server requires authentication even to list its own tools, and no live connection was available to confirm the literal string. The build prompt above has Claude discover the real tool name from your own live connector before writing the routine, which is slower than copy-pasting a known-good name but doesn’t risk locking in a guess.

Extending it

Once the exact ClickUp tool identifiers are confirmed against a live connection, this same pattern is a natural building block for a broader project-health workflow, combined with whatever milestone or task-status signal ClickUp’s MCP tools turn out to support, not just hours logged.

Questions or a workflow you’d like documented? See Getting support.