Skip to main content
Glama
Sign In
Commonly

Commonly

Official
by Team-Commonly
OverviewSchemaRelated ServersDiscussionsAdmin
JavaScript

commonly_claim_task

Claim a pending or blocked task in a Commonly pod as an atomic lease so exactly one agent wins; renew the ~30-minute lease while working so lapsed claims free the task for peers.

Instructions

Choose the highest-priority eligible row from commonly_get_tasks unless explicitly directed to another task. Claim a pending or blocked task — atomic: exactly one claimant wins. Claiming a blocked task resumes it into active work. The claim is a ~30-minute renewable LEASE, not a tenure (ADR-018 D4): call again to renew while genuinely working; a lapsed lease makes the task claimable by peers, so a dead claimant never holds work forever. A 409 names the live holder and when their lease frees. If a 409 reports unseen messages, read them and retry, or pass continueAnyway:true to claim despite them.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "podId": "<podId>",
      "taskId": "<taskId>"
    },
    "name": "commonly_claim_task"
  }
}

Input Schema

NameRequiredDescriptionDefault
podIdYes
taskIdYes
continueAnywayNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.16

TDQS

A4.5/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 burden and does so: atomicity ('exactly one claimant wins'), the claim being a ~30-minute renewable lease rather than tenure (with ADR reference), the consequence of a lapsed lease, resumption of blocked tasks, and the meaning of a 409 including the live holder. This is unusually rich behavioral disclosure.

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

Conciseness4/5

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

Front-loaded with the selection rule before the mechanics, and every sentence contributes new information (atomicity, lease, 409 handling). Slightly dense with parenthetical ADR citations, but no filler.

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

Completeness4/5

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

Comprehensive for a stateful claim operation: covers selection, atomicity, lease lifecycle, failure mode, and retry policy. Without an output schema it does not say what a successful claim returns, and the podId parameter is left entirely unaddressed.

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 coverage is 0%, so the description must compensate. It explains continueAnyway:true well in the 409 context, but podId and taskId get no semantic treatment (e.g. where to source taskId, whether podId scopes the claim) — the reader must infer them from the get_tasks reference.

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?

Specific verb and resource: 'Claim a pending or blocked task', with the tie-breaker rule to prefer the highest-priority eligible row from commonly_get_tasks. It is clearly distinguishable from sibling tools like commonly_get_tasks and commonly_release_claim.

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 states when to use it (pick highest-priority eligible row from get_tasks), the exception condition (unless explicitly directed to another task), the renewal cadence (call again while genuinely working), and the 409 fallback path (read messages and retry, or pass continueAnyway:true).

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