Skip to main content
Glama
delega-dev

delega-mcp

by delega-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

claim_task

Claim a task for exclusive processing, atomically picking the highest-priority claimable task from the queue or a specific task by ID. Returns a lease for completion.

Instructions

Claim a task for exclusive processing (work-queue semantics). Without task_id, atomically picks the highest-priority claimable task from the queue — open, unclaimed, and unassigned or assigned to you. With task_id, claims that specific task (e.g. one you found via list_tasks, or after a write was rejected with 'claim it first'); fails with a conflict if it is completed, assigned to another agent, or claimed with a live lease. Returns the claimed task, or reports an empty queue. The claim is a lease (default 300 seconds): extend it with heartbeat_task while working, requeue with release_task, or finish with complete_task. Hosted API only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
labelsNoOnly claim tasks carrying all of these labels (queue claim only)
task_idNoClaim this specific task instead of the next from the queue
project_idNoOnly claim tasks in this project (queue claim only)
lease_secondsNoLease duration in seconds (30-3600, default 300)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.19.0
    • removedInput schema / properties / project_id / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  }
-]
    • addedInput schema / properties / project_id / type
      Added value: +[
+  "string",
+  "number"
+]
    • removedInput schema / properties / task_id / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  }
-]
    • addedInput schema / properties / task_id / type
      Added value: +[
+  "string",
+  "number"
+]
  2. Addedv1.18.2
  3. Removedv1.13.1
  4. Addedv1.9.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so: it discloses that queue selection is atomic, the preconditions for claimability (open, unclaimed, unassigned or yours), the conflict failure conditions (completed, assigned to another agent, live lease), lease default and duration, and that it returns the claimed task or an empty-queue report.

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?

Front-loaded with the core purpose, then mode behavior, then failure conditions, then lifecycle routing and the hosted-only constraint. Every sentence is load-bearing with no filler.

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

Completeness5/5

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

For a no-output-schema, zero-required-param tool, the description supplies everything needed to call it correctly: mode selection, filter scoping, conflict behavior, lease duration and renewal path, and the hosted-API restriction.

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

Parameters4/5

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

Schema coverage is 100%, so parameter syntax is already documented. The description adds meaning beyond that by explaining the mode switch driven by task_id and by clarifying the queue-only applicability of labels/project_id and the lease default, though it stops short of syntax-level detail.

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

Purpose5/5

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

States a specific verb (claim) and resource (task) plus its queue semantics, and distinguishes the two operating modes (queue claim vs. specific task_id) that separate it from siblings like list_tasks and get_task. An agent can tell immediately this is the exclusive-acquisition operation.

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

Usage Guidelines5/5

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

Explicitly covers both modes and when each applies: no task_id for the next highest-priority claimable task, task_id when the id came from list_tasks or a rejected write ('claim it first'). It also routes the agent to the correct lifecycle alternatives (heartbeat_task to extend, release_task to requeue, complete_task to finish).

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

Deploy Server

Other Tools