Skip to main content
Glama
Sign In
cohors

cohors

by rushirb2001
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

What to do next

overview
Read-onlyIdempotent

Surface what to do next across all git repositories, ordered by urgency, with reasons, risk figures, and the verb to act on each item.

Instructions

The briefing: what to DO NEXT across the fleet and why, in one call. Returns actions (most urgent first — each with a title, the reason, the registry verb that carries it out when there is one, and the ids of the repos it applies to), figures (the key numbers: work not backed up, stashes, uncommitted files, stale fetches, open tasks, commits this week), repos (one line per repo, most urgent first, with every reason in plain words and at_risk marking where local work could be lost), work (open tasks per repo) and commits (last 7 days per repo). This is the exact model the terminal UI, the web dashboard and the editor extension render, so what you report matches what the user sees. Use it for "what should I do", "brief me", "what's at risk", or before planning a day; use list_repos when you need raw per-repo fields or a selector. To act on an action, pass its repos as {"ids": [...]} to the named verb. Takes no arguments.

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": "overview"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds value beyond that by fully specifying the payload shape of actions/figures/repos/work/commits, including ordering guarantees (most urgent first, actions and repos alike) and the at_risk marker; it does not discuss data freshness or how figures are computed.

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 one-line purpose, then payload, then usage, then the follow-up recipe — a sensible order. It is dense and long for a single paragraph, and the per-key enumeration could be tightened, but nearly every clause conveys information the agent would otherwise have to discover by calling.

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?

There is no output schema, and the description fully compensates by describing all five return groups, their ordering, and the meaning of at_risk. It also states the result is identical to what the terminal, web and editor surfaces render, so the agent can trust the reported content as the user's canonical view.

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?

With zero parameters the baseline is 4, and the closing clause 'Takes no arguments' removes any ambiguity about passing filters. It could have added a note on whether the caller's scope/workspace constrains results, but nothing is misleading.

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 the specific verb/resource pair in plain terms: 'what to DO NEXT across the fleet and why, in one call.' It also enumerates the five return keys, so an agent knows exactly what it gets, and it contrasts the scope against list_repos for raw per-repo fields.

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 trigger phrases are given ('what should I do', 'brief me', 'what's at risk', before planning a day), plus the exclusion: use list_repos instead when raw per-repo fields or a selector are needed. It even explains the follow-up path — pass an action's repos as {"ids": [...]} to the named verb — which is exactly the routing an agent needs.

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