Skip to main content
Glama
ratheesh-aot

Clockify MCP Server

by ratheesh-aot

create_time_entry

Log work hours in Clockify by creating time entries with start times, descriptions, and optional project, task, or tag assignments.

Instructions

Create a new time entry

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
workspaceIdYesWorkspace ID
descriptionNoTime entry description
startYesStart time (ISO 8601 format)
endNoEnd time (ISO 8601 format, optional for ongoing entries)
projectIdNoProject ID (optional)
taskIdNoTask ID (optional)
tagIdsNoArray of tag IDs (optional)
billableNoWhether the entry is billable (optional)

Implementation Reference

  • The core handler function that processes input arguments, formats dates to ISO 8601, makes a POST request to Clockify's /workspaces/{workspaceId}/time-entries API endpoint to create the time entry, and returns a formatted success message with entry details.
    private async createTimeEntry(args: any) {
      const { workspaceId, ...timeEntryData } = args;
      
      // Ensure start time is in ISO format
      if (!timeEntryData.start.includes("T")) {
        timeEntryData.start = new Date(timeEntryData.start).toISOString();
      }
      
      // If end time is provided, ensure it's in ISO format
      if (timeEntryData.end && !timeEntryData.end.includes("T")) {
        timeEntryData.end = new Date(timeEntryData.end).toISOString();
      }
    
      const timeEntry = await this.makeRequest(
        `/workspaces/${workspaceId}/time-entries`,
        "POST",
        timeEntryData
      );
    
      return {
        content: [
          {
            type: "text",
            text: `Time entry created successfully!\nID: ${timeEntry.id}\nDescription: ${timeEntry.description || "No description"}\nStart: ${timeEntry.timeInterval.start}\nEnd: ${timeEntry.timeInterval.end || "Ongoing"}`,
          },
        ],
        isError: false,
      };
    }
  • src/index.ts:283-299 (registration)
    Registers the create_time_entry tool in the ListToolsRequestSchema response, including its description and detailed inputSchema for validation.
      name: "create_time_entry",
      description: "Create a new time entry",
      inputSchema: {
        type: "object",
        properties: {
          workspaceId: { type: "string", description: "Workspace ID" },
          description: { type: "string", description: "Time entry description" },
          start: { type: "string", description: "Start time (ISO 8601 format)" },
          end: { type: "string", description: "End time (ISO 8601 format, optional for ongoing entries)" },
          projectId: { type: "string", description: "Project ID (optional)" },
          taskId: { type: "string", description: "Task ID (optional)" },
          tagIds: { type: "array", items: { type: "string" }, description: "Array of tag IDs (optional)" },
          billable: { type: "boolean", description: "Whether the entry is billable (optional)" },
        },
        required: ["workspaceId", "start"],
      },
    },
  • src/index.ts:731-733 (registration)
    In the CallToolRequestSchema handler's switch statement, maps incoming create_time_entry calls to the createTimeEntry method, with basic param validation.
    case "create_time_entry":
      if (!args?.workspaceId) throw new McpError(ErrorCode.InvalidParams, 'workspaceId is required');
      return await this.createTimeEntry(args as any);
  • TypeScript interface defining the TimeEntry structure, which aligns with the tool's input schema properties.
    interface TimeEntry {
      id?: string;
      description?: string;
      start: string;
      end?: string;
      projectId?: string;
      taskId?: string;
      tagIds?: string[];
      billable?: boolean;
    }
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. 'Create a new time entry' implies a write/mutation operation, but doesn't disclose authentication requirements, rate limits, whether entries can overlap, what happens if end time is omitted, or the response format. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a tool with comprehensive schema documentation. Every word earns its place by clearly communicating the primary action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with 8 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what constitutes a valid time entry, how the system handles optional vs required fields, what happens on success/failure, or how this tool relates to other time management tools in the sibling list. The agent lacks crucial context for proper usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. Baseline 3 is appropriate when the schema does the heavy lifting, though the description could have explained relationships between parameters (like how projectId relates to workspaceId).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('create') and resource ('time entry'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'update_time_entry' or 'duplicate_time_entry' by specifying it creates a new entry rather than modifying or copying existing ones. However, it doesn't specify what a 'time entry' represents in this system's context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing workspace access), when to use 'create_time_entry' versus 'duplicate_time_entry' or 'stop_time_entry', or any constraints on creating entries. The agent must infer usage from the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ratheesh-aot/clockify-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server