Skip to main content
Glama
Sign In
cohors

cohors

by rushirb2001
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Pull (fast-forward only)

pull
Idempotent

Fast-forward selected repositories across your Git fleet without merging, rebasing, or losing work; preview targets with a dry run.

Instructions

git pull --ff-only across the selected repos — fast-forward only, so it never merges, rebases, or loses work. Typical flow: find what is behind with {"behind": true}, then pull those. Requires a selector. Executing needs --allow-writes; dry_run:true (or a read-only server) previews the targets.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "selector": "<selector>"
    },
    "name": "pull"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNoOnly fast-forward is supported (the default).
dry_runNoPreview the resolved target set without acting.
selectorYesPredicate that selects repos across the fleet; set fields to AND them, omit a field for no constraint (ADR-024). Scope: all (bool — the whole fleet), ids[str], name (glob, e.g. "pay*"), path_glob (* stays within one path segment, ** crosses /), root, group (a config-defined cluster name, e.g. "payments"). Local state: dirty, ahead (alias unpushed), behind, diverged, no_upstream, unpublished (a branch never pushed although the repo has a remote), stale_fetch (remote not fetched for over 14 days), has_stash, detached, conflicted, in_operation (merge/rebase/… mid-flight), error, branch (exact name), attention ("any"|"notice"|"warn"|"risk"). Remote (needs a GitHub token): ci ("passing"|"failing"|"pending"|"none"), min_prs (int). Combine: any_of[selector] (OR), not (selector). The empty selector {} matches NOTHING by design — pass {"all": true} for the whole fleet.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations, it discloses the crucial safety property that it never merges, rebases, or loses work, states the write-authorization requirement (--allow-writes), and explains that dry_run or a read-only server only previews targets. That is exactly the extra context annotations cannot express.

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?

Three tight sentences with the safety guarantee front-loaded before the workflow and the auth requirement. "Requires a selector" is mildly redundant with the required-field schema, but nothing else is wasted.

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 no-output-schema tool with a fully documented nested selector, the description covers safety, prerequisites, preview mode, and typical flow. It does not say what happens to repos that cannot fast-forward (diverged, no_upstream) during a fleet-wide pull, which is the one remaining gap.

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%, so the selector predicate, mode enum, and dry_run are already documented in detail. The description adds only the selector-is-required reminder and a usage example for the behind field, which is marginal beyond the schema baseline.

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?

"git pull --ff-only across the selected repos" names a specific verb (pull, fast-forward only), the resource (selected repos), and the scope (fleet-wide selector). The fast-forward-only constraint immediately separates it from a generic pull and implicitly from siblings like fetch and commit.

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?

Gives a concrete workflow (query with {"behind": true}, then pull those), states the selector requirement, and explains the --allow-writes gate plus dry_run preview. It stops short of naming when to prefer fetch (download without merging) or push instead, which would have made routing unambiguous.

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