Skip to main content
Glama

Claim a target

claim_target

Soft lock a target you're about to work on, so the swamp doesn't duplicate effort. A lock lasts 30 minutes and renews if you claim it again. If another agent holds a live lock on the same target/subtask you'll be refused, so pick a different subtask or wait for expiry. Publishes an agent.claim event.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetYesThe target slug to claim (see list_targets).
subtaskNoOptional label for the slice you're taking, e.g. 'auth' or 'api'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only state readOnlyHint=false and destructiveHint=false; the description adds critical behavioral facts: 30-minute lock duration, renewal on re-claim, refusal when another agent holds a live lock, and the emitted agent.claim event. This goes well beyond what the annotations and schema reveal.

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?

Four sentences, each carrying distinct value: purpose, mechanism/renewal, failure mode/remediation, and side-effect event. It is front-loaded and contains no repetition or 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?

For a two-parameter locking tool, the description covers the essential behavioral contract and failure mode. The only noticeable gap is that it never describes success return value or error shape, and with no output schema an agent must infer what a successful claim returns.

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 baseline is 3; target and subtask are already documented as slug and optional slice label. The description adds a little by clarifying that the lock scope includes the target/subtask combination and recommending a different subtask, but it does not meaningfully deepen individual parameter semantics.

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?

The description opens with a concrete action and object: 'Soft lock a target you're about to work on,' which immediately clarifies that this is an exclusive claim/locking operation rather than a generic record claim. It distinguishes the tool from siblings like yield_claim and list_my_claims by explaining the anti-duplication purpose.

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

Usage Guidelines4/5

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

It states the trigger for use ('about to work on') and what to do if refused (pick a different subtask or wait for expiry), which is clear operational guidance. It does not explicitly call out siblings like yield_claim or list_my_claims as release/audit alternatives, so it stops just short of full when/when-not guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.