Skip to content

Bug: CLICKUP_UPDATE_A_TIME_ENTRY timer_id integer type causes precision loss for large IDs #3154

@jay-deepwater

Description

@jay-deepwater

Bug Description

The CLICKUP_UPDATE_A_TIME_ENTRY tool defines the timer_id parameter as type: integer. However, ClickUp time entry IDs are snowflake-style large numbers (e.g., 5032195474653342504) that exceed JavaScript's safe integer limit (Number.MAX_SAFE_INTEGER = 2^53 = 9007199254740992).

When these IDs are passed as JSON integers, they lose precision (e.g., 5032195474653342504 becomes 5032195474653343000), causing the API call to silently fail — it returns 200 OK with "data": null because the rounded ID doesn't match any time entry.

Steps to Reproduce

  1. Create a time entry in ClickUp (any workspace)
  2. Note the time entry ID (e.g., 5032195474653342504)
  3. Call CLICKUP_UPDATE_A_TIME_ENTRY with that timer_id value and any update (e.g., new start/end times)
  4. Observe the response: {"successful": true, "data": {"data": null}} — the update silently fails

Expected Behavior

The timer_id should be accepted as a string to preserve precision, and the update should succeed.

Suggested Fix

Change the timer_id parameter type from integer to string in the tool schema. The ClickUp API accepts the ID as a path parameter (string in the URL), so no backend changes should be needed — just the schema type definition.

This likely affects other ClickUp tools that reference time entry IDs as well (e.g., CLICKUP_CREATE_A_TIME_ENTRY response handling, or any tool that chains time entry IDs).

Environment

  • MCP Server: Composio hosted MCP (SSE)
  • Tool: CLICKUP_UPDATE_A_TIME_ENTRY
  • ClickUp Workspace: Confirmed with multiple time entries, all with IDs > 2^53

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions