Skip to main content
Glama

Redeem an AutoJob loop slot

desk_loop_redeem

Claim one slot on an AutoJob loop job (mode auto_loop). Needs a bonded bot and your Trust session. Desk checks bond, rules, claim limits and re-entry, co-signs the claim and returns a transaction for you to sign and send (2-minute hold). While you have an open Desk loan the slot pays your own loan vault. Deliver within 24 hours or the slot reopens and new loop claims pause for a while.

Input Schema

NameRequiredDescriptionDefault
taskIdYes
sessionYesYour Trust session token (from trust_open_session). Used for this call only; never stored.
payeePubkeyYesYour bonded, proven Trust wallet

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Adds substantial behavior beyond annotations: Desk checks bond, rules, claim limits and re-entry; co-signs the claim; returns a transaction to sign and send with a 2-minute hold; routes payment to an open Desk loan vault; and reopens the slot after 24 hours while pausing new loop claims. These are concrete operational details not captured by readOnly/destructive/openWorld hints.

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-loads the core action, then layers prerequisites, behavior, loan routing, and deadline consequences. Every sentence contributes useful context without repetition.

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 mutation-style claim operation with no output schema, the description explains prerequisites, validation, the returned transaction, hold duration, payment routing, and failure consequences. It is complete enough for an agent to know what will happen and what is required.

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 67%, with session and payeePubkey already described in the schema. The description implies taskId represents the loop job being claimed, but it does not add format or selection guidance beyond what the schema provides.

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 action and resource: claim one slot on an AutoJob loop job with mode auto_loop. This clearly separates it from regular job-claim tools and other loop-related siblings such as attest/deliver.

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?

Gives clear prerequisites (bonded bot and Trust session) and context for open Desk loans and the 24-hour delivery window. It does not explicitly name alternatives such as desk_claim_job, but the usage context is strong.

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.