Skip to main content
Glama
Sign In
cohors

cohors

by rushirb2001
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Search across repositories

search
Read-onlyIdempotent

Locate code or repository metadata across every repository at once by matching file contents, paths, names, or branches, with optional selectors to scope results.

Instructions

Find code or repos ACROSS the whole fleet without cd-ing into each one. kind=content greps file contents (ripgrep/git grep/fallback, fixed-string — the default); kind=path|name|branch matches repo metadata (case-insensitive substring). Sensitive paths (.env, keys, credential stores) never appear in content results. An optional selector limits which repos are searched. This is the entry point for cross-repo audits and refactors — use it instead of running grep/rg in each repo yourself.

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": {
      "query": "<query>"
    },
    "name": "search"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNoWhat to match (default content).
queryYesWhat to look for (fixed string for content; substring/glob for path/name/branch).
selectorNoPredicate 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.
max_resultsNoCap on total hits (default 200).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description still adds real substance: backend fallback chain (ripgrep/git grep/fallback), fixed-string matching by default, case-insensitive substring semantics for metadata kinds, and the security guarantee that sensitive paths (.env, keys, credential stores) never surface in content results. It omits the GitHub-token requirement for remote selectors and the result cap lives only in 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?

Four tight sentences, front-loaded with the core verb and scope, and every clause carries information (default kind, matching semantics, security filter, entry-point routing). Slightly dense parenthetical stacking ("(ripgrep/git grep/fallback, fixed-string — the default)") costs a point but nothing is filler.

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?

Given a complex nested selector but full schema coverage and no output schema, the description covers scope, defaults, the two search modes, and the sensitive-path guarantee. The main gap is that it never says what a hit looks like (file+line for content, repo row for metadata), which an agent needs to plan follow-up calls.

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 nested selector is documented in full there (including the empty-selector trap and {"all": true}), so baseline is 3. The description adds interpretation for kind and query matching semantics but nothing about selector or max_results beyond what the schema already states.

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?

"Find code or repos ACROSS the whole fleet" gives a specific verb, resource, and scope, and the second sentence breaks the tool's two modes apart (kind=content greps file contents vs kind=path|name|branch matches repo metadata). An agent can tell this is the fleet-wide search entry point without opening the schema.

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?

Explicitly frames the tool as "the entry point for cross-repo audits and refactors" and tells the agent to use it instead of running grep/rg per repo, which is a concrete alternative it rules out. It stops short of naming sibling tools (e.g. list_repos, get_repo, changes) or stating when this is the wrong choice, so it is clear context without exclusions.

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