Skip to main content
Glama
Sign In

Offhand

by com.offhandapp
OverviewDiscussionsAdmin

Say where a task stands

set_task_status
Destructive

Sets where a task stands, with one line of why. "need_review" is work to be seen before it is final, and "blocked" work that cannot go on, with what is missing; the task stays where it is, and the agent that added it reads both in its handedBy "me" listing. "done" ticks the task off, the person's own included; on a repeating task it closes that day and moves it on. assignTo hands the task to another agent with the line: it goes to that agent, who is woken where it can be, and the task is theirs from then on. "in_progress" is work under way, and how a task is taken. in_progress and assignTo are refused on a task named for another agent or that another agent is working on, except from the agent that added it, whose in_progress takes it back. Any other status re-opens a ticked-off task. Each call is one line of the task's trail, with the agent's name and the time, and list_todos shows it at once. A goal takes no status.

Input Schema

NameRequiredDescriptionDefault
noteNoOne line on what changed, or what is missing. Newlines are folded away. Left out, the previous note stays; "" clears it. On a task another agent handed you, done, need_review and blocked are refused without one.
uuidYesThe task's uuid, as returned by list_todos — its short "id" works too, except on a connection that may only report, which needs the whole uuid.
agentNoWhich agent is reporting. Defaults to the name you connected with; another name reports on behalf of something else.
filesNoWhat the work made, to hand back with the report: images, PDF or plain text (a script is plain text), at most 10, 25 MB each. The answer gives each an uploadUrl.
statusYesWhere the task now stands.
assignToNoThe agent this report hands the task to, by the name list_todos shows.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / assignTo / description
      Previous value: -"The agent this report hands the task on to, by the name list_todos shows — usually the one in its \"assignedBy\". Refused on a task no other agent handed you."New value: +"The agent this report hands the task to, by the name list_todos shows."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only flag it as a non-idempotent, destructive write; the description carries far more: blocked/need_review leave the task in place and surface in the adder's handedBy listing, done ticks off and on a repeating task closes that day and rolls forward, any other status re-opens a ticked-off task, and each call appends one line to the trail immediately visible in list_todos. It also discloses assignTo's ownership transfer and wake-up side effect.

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 core action and no filler sentences; each clause encodes a rule. However, it is delivered as one dense prose block with long run-on sentences (notably the in_progress/assignTo refusal rule), which makes scanning harder than it needs to be.

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 six-parameter mutating tool with no output schema, the description covers lifecycle effects, refusals, audit trail, and hand-off consequences thoroughly. The one visible gap is "proposed", which the enum allows but the description never explains.

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 the baseline is 3, but the description genuinely adds meaning beyond the schema's one-line status field: it explains what each status does to the task's lifecycle and what assignTo does behaviorally (ownership moves, agents woken, refusals). The note parameter's role in the trail is also reinforced.

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?

"Sets where a task stands, with one line of why" is a specific verb plus resource, and the description goes on to define each status value's meaning (need_review, blocked, done, in_progress). It also distinguishes itself from the sibling list_todos by framing that tool as the reporter of the trail this call writes.

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?

Explicit when-to-use rules for every status, plus exclusions: in_progress and assignTo are refused on a task named for another agent or actively worked by another agent, except from the adding agent. It also states a clear boundary case: "A goal takes no status."

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

All Offhand toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources