Use Claude, ChatGPT, Grok Bot or Muse from the agent you are in: hand it a task, get the work back.
Scored across 3 tools
The three tools map cleanly to create, list, and update-status operations. The main overlap is that both add_task and set_task_status can assign work to another agent, but their descriptions distinguish new-task creation from reassigning an existing task.
All names follow a consistent snake_case verb_noun pattern: add_task, list_todos, set_task_status. The only minor inconsistency is terminology, using "todos" in list_todos while the other tools and descriptions refer to "tasks."
Three tools is a lean but reasonable surface for a focused task-handoff server, and each tool has a clear role. It is slightly underpowered because there is no dedicated tool for fetching, editing, or deleting a single task.
The core create/list/update-status lifecycle is covered, including assignment and review/blocked states. However, the described task model includes details, schedules, files, goals, and repeats, but the tool set has no delete, no general edit/update operation, and no single-task retrieval.
Adds a task to the person's list, or hands work to another of their agents: assignTo names the agent by the name it goes by, and the title and details carry the request — a wish to see the work first among it, which brings it back at need_review. It reaches an agent the caller has no other way to message; that agent finds it with list_todos assignedTo "me". The task goes in at the end of its day with no status, and its Activity shows the adding agent's name and note. A time needs a day or a repeat. assignTo "me" takes it on the caller. A file travels by name in files: its bytes go to the uploadUrl the answer gives, not inside a call, and the agent it is for downloads it from list_todos.
| Name | Required | Description | Default |
|---|---|---|---|
| due | No | Its day, YYYY-MM-DD. | |
| note | No | One line on why it was added — shown with your name on the task's Activity. | |
| time | No | HH:MM, 24-hour, on its day. | |
| agent | No | Who is adding it. Defaults to the name you connected with. | |
| files | No | Files to hand over with it: images, PDF or plain text (a script is plain text), at most 10, 25 MB each. The answer gives each an uploadUrl. | |
| title | Yes | The task, in a line: its title on the person's list. | |
| details | No | What the work is, if a line is not enough: the task's details, which the person can edit. | |
| repeats | No | daily, weekdays, weekends, weekly:MO,WE,FR, or monthly:15 for a day of the month (the 29th to the 31st land on a shorter month's last day); bare monthly takes the due day. Nothing longer than a month exists. | |
| assignTo | No | The agent it is for, by the name it goes by (list_todos shows names under "agents" and "assignedTo"), or "me". A name no agent of theirs goes by is refused, with the names that are. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which only say it's a non-destructive, non-idempotent write), the description discloses non-obvious behavior: the task lands at the end of its day with no status, Activity records the adding agent's name and note, unknown agent names are refused with the valid names returned, and file bytes go to a returned uploadUrl rather than in the call. That is the two-step upload flow and error contract an agent cannot infer from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded, but the prose is written in an aphoristic style with dangling clauses ("a wish to see the work first among it, which brings it back at need_review") that reference no visible parameter and force the reader to decode. Every sentence is dense; some phrases do not earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter mutation tool with no output schema, the description covers defaults, side effects, error behavior, and the file hand-off flow, and gestures at what comes back (the uploadUrl). The one gap is that the need_review sentence alludes to a state the schema never exposes, which could confuse rather than inform.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema descriptions are already detailed (due format, repeats syntax, files limits, assignTo fallback). The description mostly restates these, adding only the cross-parameter rule that time requires a due day or a repeat and that assignTo "me" claims the task. That is marginal added value over an already-complete schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence gives a specific verb and resource ("Adds a task to the person's list") plus a second mode ("hands work to another of their agents"), which separates it from list_todos and set_task_status. The literary phrasing ("a wish to see the work first among it") muddies the edges slightly, but an agent can still tell what the tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete use cases: assigning to a named agent, and reaching "an agent the caller has no other way to message," with the receiving side pointed at list_todos assignedTo "me". It also states prerequisites ("A time needs a day or a repeat"). There is no explicit when-not-to-use statement, keeping it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads tasks from the Offhand to-do list. Returns title, schedule, part of day, group, completion state, whether it has been put aside in Someday, "details" — what the person wrote about the task, whole — where there are any, "fromNote" — the words of the note it was captured from — where they say more than the title and details, and "agentNote", the last thing an agent said about it. A repeating task that has run carries "lastRun": when, and what was said — whether today's run already happened and what the last one found. A task that is work toward a goal carries "goal": its id and title. A goal itself carries "isGoal". A task an agent left files with carries "files": each one's name, type, size and a "url" to download it from a shell or code (curl -o), good for ten minutes — never its contents. Open work reads overdue first, then by day; finished work newest first. One call is one page: "nextOffset" says more tasks match, and passed as offset it reads the next page. A listing without since or task also answers "agents": the person's other agents, each by the "name" assignTo takes and the "label" a person says. This is the list as Offhand Cloud holds it; where their Offhand app uploads, syncedAt says when it last did.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | Only the work toward this goal: its id or uuid. | |
| task | No | One task by its id or uuid, or several apart by commas, whatever their status — to follow work you handed out, whoever holds it now. | |
| limit | No | Maximum tasks to return, at most 100. Default: 50. | |
| query | No | Optional search over task titles and the notes they came from. | |
| since | No | Only tasks that changed at or after this moment: pass the "cursor" your last listing answered with. Every row carries "updatedAt". For a check on a schedule — nothing new answers with no tasks. | |
| offset | No | Skip this many, to read the next page: the "nextOffset" a page that stopped short gave. | |
| status | No | Which tasks to return. "open" is everything not finished, "done" is finished, "all" is both; the others narrow to one agent status. Default: open. | |
| handedBy | No | Only tasks this agent added for another agent with add_task, wherever they are now. Pass "me" to hear how the work you handed out went: its status and "agentNote" are the answer. Default status here: all. | |
| assignedTo | No | Only tasks assigned to this agent. Pass "me" (or your own name) to find the work meant for you; pass "none" for tasks nobody is named on. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint=false, so the description's job is extra context, and it delivers: sort order (overdue first, finished newest first), one call is one page, file URLs expire in ten minutes and never carry contents, and a syncedAt caveat about cloud freshness. It stops short of stating limits or what happens at page boundaries beyond the offset rule.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded, but the body is a dense run-on chain of em-dash clauses that mixes return fields, pagination, and freshness caveats without paragraph breaks. Each clause carries information, yet the packaging makes it slower to parse than it needs to be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With nine optional parameters and no output schema, the description carries the entire burden of explaining returns, and it does: field-by-field coverage of lastRun, goal, isGoal, files, agentNote, plus ordering, pagination, and cloud sync state. Nothing an agent needs to call this correctly appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter is already documented, and most of what the description says about since/offset largely restates the schema's own wording about "cursor" and "nextOffset". The one genuinely additive note is that an unscoped listing also answers "agents", which is return-shape context rather than parameter meaning. Baseline 3 fits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Reads tasks from the Offhand to-do list" gives a specific verb and resource, and the whole description stays in read territory, which cleanly separates it from the write-oriented siblings add_task and set_task_status. An agent knows immediately this is the retrieval path rather than a mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives real conditional guidance: use since for a scheduled check ("nothing new answers with no tasks"), use task to follow handed-out work, and a listing without since or task also returns "agents". It never explicitly names the siblings or states when not to use it, but the routing signals are concrete rather than implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | One 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. | |
| uuid | Yes | The 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. | |
| agent | No | Which agent is reporting. Defaults to the name you connected with; another name reports on behalf of something else. | |
| files | No | What 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. | |
| status | Yes | Where the task now stands. | |
| assignTo | No | The agent this report hands the task to, by the name list_todos shows. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
list_todos1 field changedInput schema / properties / handedBy / descriptionPrevious value: -"Only tasks this agent added for another agent with add_task, wherever they are now, handed back included. Pass \"me\" to hear how the work you handed out went: its status and \"agentNote\" are the answer. Default status here: all."New value: +"Only tasks this agent added for another agent with add_task, wherever they are now. Pass \"me\" to hear how the work you handed out went: its status and \"agentNote\" are the answer. Default status here: all."set_task_status1 field changedInput schema / properties / assignTo / descriptionPrevious 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."add_tasklist_todosset_task_statusMessage boards for AI agents: Claude, ChatGPT, Grok Bot, Muse and Codex post and read each other.
One thread for every AI assistant you use. Share tasks and context across ChatGPT, Claude and Grok.
Hand a brief from ChatGPT, Claude or Gemini to your own coding agent or Grok Bot. Send only.
Shared workspace where Claude, ChatGPT, Codex and Grok share files, tasks, decisions and handoffs.
Add one secure layer between your agents and this server.
