Skip to main content
Glama
Sign In
taskops

taskops

by bernatch22
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

taskops_board

Check the current board pulse to see what's waiting, grouped by action needed: merge, mentions, review, changes, or blocked.

Instructions

THE pulse: what the board is waiting for, grouped by the move each card needs (MERGE, MENTIONS, REVIEW, CHANGES, STALLED, TAKE, DOING, REVIEWING, BLOCKED). Open every turn with this.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "taskops_board"
  }
}

Input Schema

NameRequiredDescriptionDefault
tzNotimezone the days and months are cut in, e.g. Europe/Madrid (default UTC)
actorNowho is speaking, when it is not the session's own identity. Sub-agents share the session's ONE MCP server, so a spawned worker MUST pass the agent:<dev>/<name> its brief names on EVERY taskops call — without it the board hears the orchestrator.
windowNohours over "7d" (the last N calendar days), "month" (this month so far), "2026-07" (that calendar month) or "total" (the whole log)
milestoneNoms-… one chapter, * the whole board; default: the open one
repo_pathNoanother project's board, by any path inside it. Default: the board this server started in. The host runs ONE MCP server per session, pinned to the directory it opened, so without this a second project is unreachable and the work leaves through curl instead of the tools.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.4.2
    • changedInput schema / properties / milestone / description
      Previous value: -"ms-… to focus one chapter; default: the open one"New value: +"ms-… one chapter, * the whole board; default: the open one"
    • changedInput schema / properties / tz / description
      Previous value: -"timezone for those days, e.g. Europe/Madrid (default UTC)"New value: +"timezone the days and months are cut in, e.g. Europe/Madrid (default UTC)"
    • changedInput schema / properties / window / description
      Previous value: -"hours over the last N calendar days, e.g. \"7d\""New value: +"hours over \"7d\" (the last N calendar days), \"month\" (this month so far), \"2026-07\" (that calendar month) or \"total\" (the whole log)"
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burd of behavioral disclosure. "The pulse of what the board is waiting for" strongly implies a read-only, aggregated status view, but the description does not explicitly state that no changes are made or describe how the snapshot behaves under empty or stale states.

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?

Two sentences with no filler: the first says what kind of information is returned and how it is grouped; the second says exactly when the agent should call it. Each sentence earns its place and the key usage rule is brief and memorable.

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?

The description supplies the purpose, grouping model, and calling frequency for a board view meaning no required params and a fully described schema. It could say more about the exact shape of the returned pulse, but it gives enough for an agent to know whether and why to call it.

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?

The description itself adds no parameter-level information, but schema description coverage is 100%, covering the meaning of timezone, actor identity, window, milestone, and repo path. This the baseline-3 case where the schema does the heavy lifting.

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?

The description clearly identifies the board as an informational pulse of what each card needs, grouping by moves like MERGE, MENTIONS, REVIEW, and BOCKED. This makes the tool's role distinct from the action-oriented sibling tool names, though it lacks an explicit operation verb such as 'list' or 'fetch'.

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?

"Open every turn with this" is an explicit, strong when-to-use instruction and implies it should come before the individual action tools. It does not list when-not-to-use cases or alternatives, but the guidance is clear and actionable.

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

Deploy Server

Other Tools