Skip to main content
Glama
Sign In
Solumbe

Solumbe

by BASHBOP
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Search Repository Catalog

repo_search
Read-only

Search indexed local repositories by path, domain, kind, route, imports, exports, and symbols; omit the query to list the catalog instead. Search one repo, specified paths, or all catalog repos.

Instructions

Search indexed local repositories by path, domain, kind, route, imports, exports, and symbols. Omit query to list the local repository catalog instead. Searches the repository at path (the working directory by default) only; pass paths to search those repositories, or all: true to add every repository in the local catalog (call repo_index to add one). Outside a repository it searches the catalog.

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

Input Schema

NameRequiredDescriptionDefault
allNoAlso search every repository in the local catalog.
pathNoRepository to search. Defaults to current working directory.
limitNoMaximum matches. Defaults to 25.
pathsNoRepositories to search instead of the catalog.
queryNoSearch query. Omit to return the catalog listing instead of search matches.
catalogNoOptional catalog JSON path.
offlineNoUse stored index files without refreshing fingerprints.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv4.10.0
    • addedInput schema / properties / all
      Added value: +{
+  "description": "Also search every repository in the local catalog.",
+  "type": "boolean"
+}
    • addedInput schema / properties / path
      Added value: +{
+  "description": "Repository to search. Defaults to current working directory.",
+  "type": "string"
+}
    • addedInput schema / properties / paths
      Added value: +{
+  "description": "Repositories to search instead of the catalog.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  2. First observed

TDQS

A3.8/5.0
Behavior3/5

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

readOnlyHint=true already tells the agent this is a safe read; the description adds useful scope behavior (default working directory, catalog fallback when outside a repository). It says nothing about index freshness, whether results reflect stale fingerprints, or how offline interacts with search, leaving behavior beyond annotations thin.

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 front-loaded sentences that cover scope, listing mode, and widening options with no filler. The final sentence ('Outside a repository it searches the catalog') repeats the catalog fallback already implied earlier, a minor 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?

For a read-only search with fully documented parameters, this covers how to target repositories and how to switch to listing mode. With no output schema, it could still say what a match or catalog entry looks like, 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real precedence semantics the schema does not: path is the default target, paths replaces it, all: true adds every catalog repo, and query omission switches from search to listing. Those interactions are genuinely useful beyond the per-field descriptions.

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 gives a specific verb (search) and resource (indexed local repositories) and enumerates the searchable facets: path, domain, kind, route, imports, exports, symbols. It also clarifies that omitting the query lists the catalog instead. It doesn't differentiate from look-alike siblings such as repo_map, repo_inspect, or repo_harness, so it falls short of 5.

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 clearly states when to omit query (catalog listing), the default scope (the repo at path, working directory by default), and two ways to widen scope (paths, or all: true with repo_index to add repositories). It doesn't say when to prefer repo_map or repo_inspect over this tool, so alternatives are only partly covered.

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