Skip to main content
Glama

hub_task

Manage a shared task sheet for AI coding agents: view, add, take available tasks, assign owners and areas, and update task status so sessions in the same project coordinate work.

Instructions

The task sheet: view, add, take (first wins), assign/areas (lead), update yours.

Input Schema

NameRequiredDescriptionDefault
idNoA task number: 12 or A12.
toNoassign: the agent.
noteNoupdate: what happened.
showNoview.next
takeNoadd: yours now.
areasNoPath prefixes it changes: app/,docs/.
titleNoThe work, and what done looks like.
whereNoThe machine it needs.
acceptNoareas: the suggested.
actionYesWhat to do.
parentNoassign title: the task it is part of.
statusNoupdate.
dependsNoTask numbers it waits for: A12,A14.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.2

TDQS

A3.6/5.0
Behavior4/5

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

Beyond annotations, it discloses concurrency (take first wins), authority requirement (assign/areas lead), and ownership restriction (update yours). Annotations already establish non-read-only, non-destructive, closed-world behavior, so these added constraints are meaningful.

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 one-line description with no filler; every fragment maps to an action or constraint. However, the telegraphic style is arguably too compressed for a 13-parameter, six-action tool.

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

Completeness3/5

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

For a six-action task tool with 13 params, it covers the core action set and a few key rules, while leaving action-specific required fields and return behavior to the schema (which is fully described). Given the rich schema, this is adequate but still thin around conditional action requirements and no output schema.

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%, and the schema maps most parameters to actions (e.g., to=assign, note/status=update, show=view). The description only adds permission hints for assign/areas and update, not syntax or conditional requirements, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States the resource ('task sheet') and enumerates the action verbs view/add/take/assign/areas/update, so the agent knows this is task management. It is compressed and does not explicitly differentiate from any task-related sibling, but the sibling list has no direct task competitor.

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

Usage Guidelines3/5

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

Adds action-level constraints: take is first-wins, assign/areas are lead-only, and update is limited to yours. It does not give explicit when-to-use guidance for view/add or compare against siblings, so it remains implied rather than complete.

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