taskops

by bernatch22

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.5.6
Disambiguation4/5
Most tools have clearly distinct purposes: board gives the current state, activity gives history, card gives a single card's full details, and update/comment/review/merge/take/assign/plan/filed each target a specific workflow step. There is minor overlap between board and activity as both provide overviews, but descriptions clarify the current vs historical focus.
Naming Consistency3/5
All tools share the consistent 'taskops_' prefix, but the suffixes mix nouns (card, board, activity) and verbs (update, plan, assign, merge, take, review, comment, filed). 'filed' is a past tense verb, which is unusual. The pattern is not uniform, but the names are still readable and context helps.
Tool Count5/5
With 11 tools, the server is well-scoped for a task management system. Each tool addresses a specific part of the workflow (planning, assigning, executing, reviewing, merging, reporting), and none seem redundant or unnecessary.
Completeness4/5
The tool set covers the core lifecycle: plan creates milestones/cards, assign and take manage work, update and comment handle changes, review verifies, merge integrates, and filed reports results. Minor gaps exist, such as no explicit delete/archive (though 'drop' may serve) and no separate tool to list all workers, but these are not critical to the main workflow.
Average 4/5 across 11 of 11 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 276 commits in the last 12 weeks
- Last stable release on September 1, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that claiming returns a bundle of information (goal, spec, thread, notes, collisions, worktree) and restricts use to workers, which adds useful behavioral context given no annotations. However, it does not mention the side effect of claiming (e.g., assigning the card to the caller, possibly locking it), leaving a transparency gap.
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?
The description is a single sentence that front-loads the core action ('Claim your card') and then lists the returned items compactly. It is efficient with no obvious fluff, though the long list makes it slightly dense. The structure is appropriate for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has nine parameters, no output schema, and no annotations, the description is under-specified. It omits the create-and-claim functionality implied by the title parameter, does not describe the return format in a usable way, and fails to explain conditional parameter usage. The description covers only the most basic claim action, leaving substantial gaps.
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 schema covers all nine parameters with detailed descriptions (e.g., actor explains sub-agent MCP sharing, repo_path explains host pinning), so the schema itself provides strong parameter meaning. The tool description adds no parameter-specific information, meeting the baseline for high schema coverage but not exceeding it.
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 uses the concrete verb 'Claim' and identifies the resource as 'your card', and it lists specific returned artifacts (milestone goal, spec, thread, etc.). This clearly conveys the tool's primary function. However, it does not explicitly differentiate this from sibling tools like taskops_assign or taskops_update, so the distinctiveness is not fully highlighted.
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?
The phrase 'Workers only' gives a clear audience restriction, and 'Claim your card' implies the main use case. But it does not state when to use this tool instead of alternatives, nor does it mention the create-and-claim behavior described for the title parameter. Guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, behavior is conveyed through the definition as a whole: atomic single-call creation, ordering semantics, review precedence ("the card's own value always wins"), collision behavior ("sibling conflicts in THESE paths union-merge... every other conflict still refuses"), and the identity trap ("without it the board hears the orchestrator"). The top-level description is terse, but the parameter descriptions carry the behavioral disclosure burden well; it does not describe what happens on dependency cycles or partial failure.
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?
Three sentences with zero waste: the core operation and scope are front-loaded, the critical dependency-index semantics follow, and the role restriction closes. Every sentence earns its place, and nothing is repeated from the schema.
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 9-parameter creation tool with no annotations and no output schema, the definition is nearly complete: the schema descriptions explain goal, identity, review defaults, conflict-resolution rules on the seam files, and precedence. The missing pieces — return value/result of a successful call, failure mode for invalid indices or cycles, sync between the index semantics and the tree — are gaps, but not clarity-blocking ones.
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%, so the schema already documents all nine parameters, which is equally the baseline of 3. The top-level description's note on the index semantics mostly restates what the property cannot be transformed into, so it adds qualified value. The parameter descriptions themselves are exemplary (priority scale 0-3, precedence rules, example lists), but the tool description is not what provides that benefit.
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 states a specific verb and resource — "Write the tree in ONE call: a milestone and its cards, dependencies included." — making the batch-planning scope unmistakable. It implicitly distinguishes itself from siblings through "ONE call" and "Orchestrator only", but it never names a sibling like taskops_card, so the differentiation is implicit rather than explicit.
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?
The definition implies when to use the tool — the whole milestone-and-cards tree at once, from the orchestrator only — and the schema adds strong guidance (repo_path warns about unreachable second projects, actor warns about identity confusion). But it never states explicit when-not conditions or directs the agent to a sibling (e.g., taskops_card for a single card), so the routing guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries the full behavioral burdens and it does provide balance: it says what statuses preconditions exist (done needs a commit or no_code, released/dropped require a note) and that a released note is shown verbatim to the next worker. Where it falls short is on the bigger side effects: it never states whether changes are permanent, whether they can be undone, or what the mutation notices to the board.
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?
The description is construct, frontloaded with the core mutation point and each clause serves a distinct purpose — status transitions, field rewrites, and the cross-reference to taskops_comment — no filler. It loses a half-point because the long comma-separated gut of status → field mutations is more dense and harder to parse than a short list or bullets, but ever sentence earns its place.
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 19-parameter write tool without annotations or an output schema, the description covers the most common modes but silently omiss some entire axes: card moves via milestone (tool), multi-project routing via repo_path, the all-important actor claim for sub-agents, along with resources-maintain fields like files and union_files. The schema patches most of these gaps with rich parameter descriptions, but a reader of the description along the surface offeature-uncovering would need to open every field to find them.
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 schema already documents all 19 parameters with clear semantic descriptions, so the bar is at baseline-3. The description reinforces status conditions (e.g. done needs a commit, released needs a note) but those largely duplicate the schema's restat and note descriptions rather than adding new parameter-level meanIng. It provides adequate, not exceptional, additive value.
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?
The description leads with 'Change the CARD' — a specific verb and a clear resource — and then enumerates the concrete mutations: close, hand in for review, hand back, drop, retitle, rewrite spec/criteria, re-prioritize, and declare a dependency. It also distinguishes itself from at least one sibling by routing trivial messaging to taskops_comment, so the agent can visibly tell the tools apart.
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?
The description gives clear when-to-use context: it states welkwhat operations are supported and attaches conditions (done needs a command or no_code=true, review-on-a-card-that-requires-imb, released needs a not, dropped needs a reason). It explicitly says 'To say something: taskops_comment,' which is an honest exclusion, but it does not disambiguate among the other mutation siblings like taskopsinate, taskops_review, or taskops_assign, so it falls short of a full decision-guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses what is returned (standing, commits with numstat, merged_into, notes), how depth changes output, and that diffs are not included. However, it does not mention side effects (likely none but not stated), auth requirements, or rate limits, and it doesn't explicitly confirm read-only behavior.
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?
Three sentences pack a lot of value: the first gives a clear overview, the second explains filters and depth, the third sets a critical limitation. There is zero fluff and every phrase earns its place, making the description appropriately sized for a complex read tool.
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?
Without an output schema, the description must communicate return value essence, which it does by enumerating card standing, commits, merge info, and reports. The schema covers parameter details thoroughly, so the description need not repeat them. Minor gaps remain (e.g., error behavior or how to interpret seq) but the overall package is solid.
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 adds meaningful layer: 'since=<seq> returns only what moved' and 'depth=full adds each spec and thread' reinforce the semantics. The milestone/tasks filter explanation also helps, going slightly beyond the raw schema.
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 states it provides 'the whole story of a chapter in ONE read' including cards, commits, merge locations, and reports. While it lacks a direct verb like 'list' or 'get', the intent is unambiguous and the content distinguishes it from sibling tools like taskops_board or taskops_card.
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?
It explicitly covers when to use it (for a comprehensive chapter view), how to limit scope (milestone, tasks), and how to do incremental reads (since=<seq>). The 'No diffs' note tells users to go to git for diffs, acting as a clear exclusion. It doesn't name alternative sibling tools, but the guidance is practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden. It discloses mutating actions (assigning cards, cutting worktrees) and sub-agent spawning, but lacks detail on reversibility, permissions, or failure behavior. It gives core behavior without deep consequences.
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?
Three sentences, front-loaded with the main action, no redundant words. Efficiently packs the workflow into a readable format.
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?
The tool is complex (multi-step, sub-agent spawning) and there's no output schema. The description mentions returning paste-ready briefs but not their structure or additional side effects. It's adequate but lacks depth for a task of this complexity.
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?
All parameters have schema descriptions (100% coverage), so the description doesn't need to add parameter info. It mentions 'cut one worktree each' which aligns with the worktrees parameter, but adds no new semantics beyond the schema.
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?
The description clearly states the tool's function: assign cards to workers, cut worktrees, return paste-ready briefs, and spawn sub-agents. The verb 'assign' and specific actions distinguish it from sibling tools like taskops_take or taskops_update.
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?
'Orchestrator only' provides explicit context on who should call it, and 'spawn one sub-agent per brief' implies it's for delegation workflows. However, it doesn't name alternative tools or specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It clearly discloses the return scope (full card with spec, thread, graph, file collisions, worktree) and the search fallback, which strongly implies a read-only operation. It does not mention error behavior or auth, but the read intent is well conveyed.
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 short sentences, front-loaded with the primary purpose and a list of contents. Every phrase adds useful information; there is no filler or redundancy.
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?
The description is readable and informative for a retrieval tool, but it omits the expected relationship between task and query (e.g., whether they are mutually exclusive) and does not explain behavior when neither is provided. Since there is no output schema, the lack of return-format details is also a gap, though the explicit list of included data partially compensates.
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%, so the baseline is 3. The description only restates the query behavior already in the schema ('search titles and specs') and adds no extra meaning for task, actor, or repo_path beyond the schema's own detailed descriptions.
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?
The description opens with 'One card in full' — a specific verb+resource — and enumerates the full contents (spec, thread, graph, file collisions, worktree). It also distinguishes a second mode (query search) and implicitly separates this tool from siblings like taskops_board or taskops_activity.
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?
The description implies usage: use it to view one card in full, or use query to search titles/specs. However, it never explicitly states when to prefer this over sibling tools, nor does it explain consequences of omitting both task and query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does add valuable context with 'The board stores the pointer, never the prose — every reader renders it from its own clone,' which explains the storage model beyond the schema. Yet it leaves unspecified whether registration is idempotent, what happens on duplicate paths, and what output or errors are returned.
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?
The description is exactly two sentences: the first compactly packs the required parameters and the prerequisite into a single line, and the second explains the pointer-based storage model. Every clause is purposeful with no filler or redundancy.
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 core concept is well covered: the tool requires an existing commit, stores only a pointer, and renders from each reader's clone, with a sensible milestone default. It does not discuss output/return behavior or error cases, but for a simple registration operation with fully documented parameters this is a minor gap rather than a critical one.
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 100% and each parameter already has a descriptive comment, so the description's inline list 'path=, title=, sha=, milestone=' adds no new semantic detail beyond restating names. The milestone default is also repeated from the schema, so the description does not elevate parameter understanding.
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?
The description opens with an explicit verb ('Register') and a specific resource ('a report you already COMMITTED under .taskops/reports/'), immediately clarifying that this tool records a commit pointer rather than storing content. This operationally distinguishes it from siblings like taskops_card or taskops_review, which handle different board actions.
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?
The description clearly states the prerequisite (the report must already be committed) and notes the milestone default ('the single open chapter'), giving the agent a concrete condition for when to use this tool. However, it does not name alternative tools or explicitly say when not to use it, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses important behaviors: 'one verifier per card' (exclusivity), 'full dossier back' (return info), 'the worker's lease untouched' (no impact on worker), 'note reaches the worker verbatim' (note transparency), and the self-review ban. This is substantial context beyond the schema.
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?
The description is two sentences and front-loads the tool's purpose. It uses cryptic capitalization and punctuation, but every clause adds information. It could be clearer on the two-step process.
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 tool has no output schema and no annotations, so the description must cover behavior. It explains the claim vs judge modes, the exclusivity, the dossier return, and the self-review rule. However, it doesn't detail the structure of the 'full dossier' or error conditions, but for a 5-param tool with schema descriptions, it's reasonably complete.
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?
The description adds meaning to key parameters: task is the submitted card, verdict accepts pass|changes, and note is passed verbatim. The schema already has detailed descriptions for all 5 parameters (100% coverage), so the description builds on that by explaining the workflow.
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?
The description clearly identifies this as the verification/review tool: 'THE verifier's one door' and explains it claims a submitted card and judges it with verdict=pass|changes. It distinguishes implicitly from siblings by being the only review tool.
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?
It states the workflow: claim a card (task=...) and then judge with verdict and note. It adds a key constraint: 'You may never judge your own work.' However, it doesn't explicitly compare to alternatives beyond calling itself the 'one door', but the workflow is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full disclosure burden. It states the failure semantics (a batch stops at the first failure, reports per card, and continues on re-run), describes conflict behavior, and asserts a strong safety guarantee ('main is never touched').
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?
The definition is compact and information-dense, with five short sentences, each adding a new behavioral or imperative detail. Nothing is filler, and the primary action is front-loaded in the first sentence.
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 an 8-parameter mutating tool with no output schema, the description covers the main invocation modes, failure behavior, retry semantics, and a key safety property. It does not describe the return/report format in detail, but it names 'reports per card' and the schema covers the remaining conditions like milestone and criteria_met.
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%, so the scoring baseline is 3. The coverage provides useful grouping of the modes, but most parameter-level semantics are already in the schema; the description adds little new meaning beyond that.
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?
The opening sentence names a precise action and resource: integrate DONE cards into their milestone branch, and adds technical specificity with --no-ff and the integration worktree. This clearly distinguishes the tool from the other taskops siblings such as taskops_update or taskops_comment.
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?
The description gives concrete invocation modes (one task, ordered tasks, all cards under MERGE), plus how a stopped batch should be re-run. It also restricts use to the 'orchestrator only', but does not explicitly compare against alternative tool names or name when not to use the tool, so it stops just short of top-level guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden — and it delivers. It discloses that closed cards accept append-only postscripts without reopening, that mentions only deliver on open cards and clear automatically upon the recipient's next write, that the thread is never truncated, and that sub-agents must pass an explicit actor to avoid the board hearing the orchestrator. These are non-obvious side effects an agent needs to call the tool correctly.
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?
The description is dense but every sentence earns its place: the primary function, closed-card semantics, mention delivery, actor identity caveat, and repo_path purpose. It is front-loaded with the key action and packs critical edge cases into a few sentences without fluff. The structure with colons and semicolons keeps it scannable.
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 tool with 5 parameters, no output schema, and no annotations, the description covers all critical usage nuances: mention delivery only on open cards, the actor requirement for sub-agents, repo_path for multi-project scenarios, and the append-only thread behavior. There is no output schema to explain, and the description addresses every parameter's practical implication, leaving no operational gaps.
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% and the schema descriptions are already rich (e.g., task explains any card, mentions explains delivery). The description adds extra meaning beyond the schema: it explains why actor matters for sub-agents ('without it the board hears the orchestrator') and why repo_path is needed ('the host runs ONE MCP server per session ... without this a second project is unreachable'). This adds genuine value beyond the structured fields.
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?
The description opens with 'Say something on ANY card' — a specific verb and resource — and immediately distinguishes it from sibling tools by emphasizing it works on closed cards, others' cards, and other teams. It clearly positions taskops_comment as the generic commenting tool, unlike taskops_update (which likely mutates card fields) or taskops_assign (which changes ownership). The purpose is unambiguous and differentiates from siblings.
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?
The description gives explicit when-to-use context: 'THE channel between agents in parallel: when your files meet theirs, say so on their card.' It also warns about closed cards for mentions ('a closed card delivers nothing, so address the living card instead'). However, it does not explicitly contrast with alternatives (e.g., 'use taskops_update for structured edits'), so it stops short of the highest bar for explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![taskops MCP server](https://glama.ai/mcp/servers/bernatch22/taskops/badges/card.svg)](https://glama.ai/mcp/servers/bernatch22/taskops)

Score Badge

Copy to your README.md:

[![taskops MCP server](https://glama.ai/mcp/servers/bernatch22/taskops/badges/score.svg)](https://glama.ai/mcp/servers/bernatch22/taskops)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bernatch22/taskops'

If you have feedback or need assistance with the MCP directory API, please join our Discord server