Skip to main content
Glama
wlee374

sumgrep

by wlee374
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
SUMGREP_CONFIGNoPath to the settings file used by the MCP server. If set it is used instead of sumgrep.toml in the sumgrep folder or ~/.sumgrep/sumgrep.toml. If no sumgrep.toml is found anywhere the server fails with 'sumgrep is not configured: no sumgrep.toml found'.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
search_codeA

Semantic search over indexed repos' functions BY MEANING.

Use for conceptual questions where you don't know the name of the
code: "where do we cache the signing keys", "code that retries
deleting a temp file", "how are search scores from two lists merged".
Do NOT use for literal identifiers, exact strings, or error messages
— use Grep for those.

Searches every indexed repo; pass repo="name" to search only one.

Returns up to k pointers: function name, file path relative to the
repo root, line range, kind, and the first sentence of an LLM-written
summary. Never returns source code: open the file in your checkout
(or grep the function name) to get the truth. The index is a snapshot
at one commit (see index_status): line numbers may have drifted, and
code written after that commit is not in it. Similarity is not
confidence — if the results look unrelated to each other, the concept
probably isn't in the index.

mode: "summary" (default, compares the query to each function's
summary), "code" (to the raw source), or "hybrid" (both, fused).
index_statusA

What is indexed: for each repo (or only repo="name"), how many functions, at which commit, and when.

The index is a snapshot at that commit. Compare it with `git log` in
your checkout: code changed after it may have moved, and code added
after it is not in the index — grep for it. Re-indexing is a manual
CLI step, not a tool.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored across 2 tools

Disambiguation5/5

The two tools are unmistakably distinct: search_code performs semantic retrieval while index_status reports index metadata. The search_code description even explicitly delineates what it is not for (literal greps), leaving no boundary confusion.

Naming Consistency4/5

Both names use consistent snake_case, but search_code follows a verb_noun pattern while index_status is a noun-style status query. That is a minor stylistic deviation rather than an inconsistency.

Tool Count3/5

Two tools is thin, and the server is essentially a single capability (semantic search) plus its status companion. Each tool does earn its place, and the narrow scope keeps the surface honest, but there is little room for anything else.

Completeness4/5

Coverage of the stated purpose is solid: search across repos with scoping, multiple modes, and a status tool for freshness. The main gap is that re-indexing is a manual CLI step with no tool, and source retrieval is deliberately punted to grep/open-file.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources