Skip to main content
Glama
ratheesh-aot

Clockify MCP Server

by ratheesh-aot

create_task

Add a new task to a Clockify project with details like name, assignees, estimates, and status for time tracking and project management.

Instructions

Create a new task in a project

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
workspaceIdYesWorkspace ID
projectIdYesProject ID
nameYesTask name
assigneeIdsNoArray of assignee user IDs (optional)
estimateNoTask estimate (ISO 8601 duration, optional)
statusNoTask status (optional)

Implementation Reference

  • The main handler function for the 'create_task' tool. It extracts parameters, makes a POST request to the Clockify API to create a task in the specified project, and returns a formatted success message with task details.
    private async createTask(args: any) {
      const { workspaceId, projectId, ...taskData } = args;
    
      const task = await this.makeRequest(
        `/workspaces/${workspaceId}/projects/${projectId}/tasks`,
        "POST",
        taskData
      );
    
      return {
        content: [
          {
            type: "text",
            text: `Task created successfully!\nID: ${task.id}\nName: ${task.name}\nProject: ${projectId}\nStatus: ${task.status}\nEstimate: ${task.estimate || "No estimate"}`,
          },
        ],
        isError: false,
      };
    }
  • src/index.ts:768-770 (registration)
    Registers the tool handler in the CallToolRequestSchema switch statement by routing calls to 'create_task' to the createTask method.
    case "create_task":
      if (!args?.workspaceId || !args?.projectId) throw new McpError(ErrorCode.InvalidParams, 'workspaceId and projectId are required');
      return await this.createTask(args as any);
  • src/index.ts:475-489 (registration)
    Tool registration in the ListToolsRequestSchema response, including name, description, and input schema definition.
      name: "create_task",
      description: "Create a new task in a project",
      inputSchema: {
        type: "object",
        properties: {
          workspaceId: { type: "string", description: "Workspace ID" },
          projectId: { type: "string", description: "Project ID" },
          name: { type: "string", description: "Task name" },
          assigneeIds: { type: "array", items: { type: "string" }, description: "Array of assignee user IDs (optional)" },
          estimate: { type: "string", description: "Task estimate (ISO 8601 duration, optional)" },
          status: { type: "string", enum: ["ACTIVE", "DONE"], description: "Task status (optional)" },
        },
        required: ["workspaceId", "projectId", "name"],
      },
    },
  • Input schema defining parameters for the create_task tool.
    inputSchema: {
      type: "object",
      properties: {
        workspaceId: { type: "string", description: "Workspace ID" },
        projectId: { type: "string", description: "Project ID" },
        name: { type: "string", description: "Task name" },
        assigneeIds: { type: "array", items: { type: "string" }, description: "Array of assignee user IDs (optional)" },
        estimate: { type: "string", description: "Task estimate (ISO 8601 duration, optional)" },
        status: { type: "string", enum: ["ACTIVE", "DONE"], description: "Task status (optional)" },
      },
      required: ["workspaceId", "projectId", "name"],
Behavior2/5

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

No annotations are provided, so the description carries full burden. 'Create' implies a write/mutation operation, but the description doesn't disclose behavioral traits like required permissions, whether the task is immediately active, what happens on duplicate names, or what the response contains. For a mutation tool with zero annotation coverage, this is inadequate.

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 with zero waste. It's front-loaded with the core action and resource. Every word earns its place, making it easy to parse quickly.

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?

Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral nuances. For a 6-parameter tool that creates resources, more context is needed to guide effective use.

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%, providing good documentation for all parameters. The description adds no parameter-specific information beyond implying a project context. With high schema coverage, the baseline is 3, and the description doesn't compensate with additional semantics like format examples or constraints not in the schema.

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 'Create a new task in a project' clearly states the action (create) and resource (task) with context (in a project). It distinguishes from siblings like create_project or create_time_entry by specifying the resource type. However, it doesn't explicitly differentiate from create_tag or create_client beyond the resource name.

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 a project first), when not to use it, or how it relates to sibling tools like update_task or get_tasks. The agent must infer usage from the 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