Skip to main content
Glama

Search Codebase

synapse_search_codebase

Search codebases using semantic, symbol, or regex modes to find relevant code and get compressed responses focused on the intended repository.

Instructions

Searches the repository codebase using different modes. Pass the exact repo_id with every action to keep results focused on the intended repository; if repo_id is unknown, call synapse_manage_repos with action 'list'. High-level actions include:

  • 'semantic': cosine similarity search over in-memory embeddings; best for conceptual or descriptive queries.

  • 'symbol': fast exact/fuzzy symbol index lookup; best when looking for a named function, module, or class.

  • 'regex': line-matching grep over indexed source; best for exact string or pattern matching. Without repo_id, every action returns at most 5 high-confidence matches across indexed repositories and reports the policy in meta.unscoped_retrieval.

REPLACES: grep_search, find, rg, list_dir for code search. Use this tool instead of these alternatives for better results with 30-60% fewer tokens via automatic compression.

Usage (short): Search codebase using semantic embeddings, symbol index, or regex grep. Pass the exact repo_id to keep results focused on the intended repository. For the freshest just-edited file, use actions 'symbol' or 'regex' (analogous to current symbol, regex, and graph context workflows).

Usage (long): Run a natural language semantic search, exact/fuzzy symbol lookup, or line-matching regex grep over indexed files. Pass the exact repo_id with every action to keep results focused on the intended repository. If repo_id is unknown, call synapse_manage_repos with action 'list' and copy it verbatim. Without repo_id, semantic requires score >= 0.75, fuzzy symbols require score >= 0.90, regex keeps exact textual matches, and every action is capped at 5 results. The response reports this in meta.unscoped_retrieval. Compression is on by default — pass compress_payload: false to opt out for debugging. Actions 'symbol' and 'regex' work immediately after quick_pass — they do not require embeddings. Action 'semantic' requires embeddings — avoid when repo_status.embeddings_partial is true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoFilter results by entity kind (e.g., function, module).
pathNoFilter results by partial file path.
fuzzyNoEnable fuzzy matching (default true, used in symbol).
limitNoMaximum number of results to return.
queryNoSearch query (natural language for semantic, regex for regex, symbol name for symbol).
actionYesSearch mode to execute.
symbolNoSymbol name to look up (alternative to query for action 'symbol').
repo_idNoRepository identifier. Pass the exact repo_id to keep results focused on the intended repository and avoid matches from unrelated registered repositories. If unknown, call synapse_manage_repos with action 'list' and copy the repo_id verbatim. When omitted, semantic uses score >= 0.75, fuzzy symbols use score >= 0.90, and every action is capped at 5 results.
languageNoFilter results by programming language.
min_scoreNoMinimum similarity score (used in semantic, default 0.6).
max_tokensNoApproximate final response budget in tokens (500-32000, default 4000).
exclude_testsNoExclude test files from search results (default true, used in semantic).
match_per_lineNoReturn per-line matches with file path, line number, and line content (like grep -n). Use this when hunting for specific function definitions or call sites — results include repo_id, file, line_number, line_content.
case_insensitiveNoIgnore case in regex search (default false, used in regex).
compress_payloadNoSet false to disable lossless response-key compression.
wait_for_ready_msNoOptional timeout in ms to wait for the indexer to finish warming up and enter an idle state before executing. Use to ensure stable results.
Behavior5/5

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

No annotations provided, so description carries full burden. Discloses: compression behavior (on by default, opt-out for debugging), unscoped retrieval policy (5-result cap, score thresholds), embedding dependency (semantic requires embeddings, avoid when embeddings_partial), and freshness behavior (symbol/regex work immediately after quick_pass). This is remarkably thorough for a non-annotated tool.

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?

Well-structured with short usage + long usage sections, action list, and explicit alternatives. Front-loaded key information (exact repo_id, action modes). Some redundancy between short and long usage sections (both repeat repo_id guidance) is a minor cost, but acceptable for a complex tool.

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?

For a 16-parameter complex tool with no output schema, the description covers action selection, result caps, score thresholds, repo scoping, fallback tip (call synapse_manage_repos list), and freshness behavior. Nothing critical is left out for correct invocation.

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 already covers 100% of parameters with rich descriptions (per-action semantics, defaults, purpose). Description adds value by explaining cross-parameter dynamics (repo_id's effect on score thresholds, compress_payload's debugging use case) that the schema lacks. Slightly less than 5 because most parameter meaning is already in the schema rather than in the description.

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?

States a specific verb+resource: searches codebase with 3 distinct modes (semantic, symbol, regex). Explicitly distinguishes from grep_search/find/rg/list_dir — names alternative tools it replaces. The three action modes are clearly differentiated by search type and use case.

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?

Gives explicit when-to-use guidance per action mode ('best for conceptual...', 'best when looking for...', 'best for exact...'). Explicitly names alternatives (grep_search, find, rg, list_dir) and states when to replace them. Also gives concrete behavioral guidance about repo_id and fallback actions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/myelixlabs/synapse-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server