Skip to main content
Glama
Sign In
Search Code MCP

Search Code MCP

by joutvhu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

search

Find code matches using regex, text, AST patterns, or symbols. Paginate results and filter files to navigate large codebases.

Instructions

High-performance unified code search engine combining ripgrep (regex/text) and ast-grep (AST patterns and YAML rules). Supports pagination with searchId and offset/limit for large results.

Input Schema

NameRequiredDescriptionDefault
pathNoDirectory or file to search in. Accepts relative or absolute paths (default: '.').
typeNoSearch engine/type: 'regex' (default), 'text', 'ast', 'ast_rule', 'hybrid', 'symbol'regex
limitNoMaximum matches to return for this chunk (default: 50)
queryNoSearch query: plain text, regex, AST pattern, or YAML rule
offsetNoStarting index for pagination (1-based, default: 1)
contextNoNumber of context lines before and after match (-C)
fileTypeNoRipgrep file type filter, e.g. 'ts', 'py', 'rust', 'json'
languageNoTarget language (e.g. 'typescript', 'python'). If omitted, auto-detected from file extension
noIgnoreNoIf true, do NOT respect .gitignore (search ignored files). Default is false (respects .gitignore)
searchIdNoPrevious search result ID to view remaining results instantly without re-scanning
multilineNoMatch regex across multiple lines (-U)
wordMatchNoMatch whole words only (-w)
filePatternNoGlob pattern to filter files, e.g. '*.{ts,tsx}' or '!**/*.test.ts'
outputFormatNoOutput format: 'content' (default), 'compact' (file:line only), 'files_only', 'json'content
caseSensitiveNoMatch case sensitively. If omitted, smart-case is used
includeHiddenNoSearch hidden files and folders (-.)
maxLineLengthNoMax characters per line before truncating long lines (default: 500)
excludePatternNoPattern to exclude, e.g. '**/dist/**', '**/*.spec.ts'

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.2
    • changedInput schema / properties / path / description
      Previous value: -"Directory or file to search in (default: current directory '.')"New value: +"Directory or file to search in. Accepts relative or absolute paths (default: '.')"
  2. First observedv1.0.0

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses pagination behavior (searchId lets you view remaining results 'instantly without re-scanning'), which is real behavioral context. But it omits permission requirements, cost/latency characteristics of the heavier engines (ast_rule, hybrid), and what happens on invalid patterns.

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?

Two tight sentences with zero padding, and the core capability is front-loaded. It is arguably too terse for an 18-parameter tool, but nothing present is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 18-parameter tool with no annotations and no output schema, the description is thin: it never explains how engine choice changes results, what the response shape is, or when pagination via searchId is required. The rich schema compensates for parameter documentation, leaving this minimally adequate.

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%, so all 18 parameters are already documented, making 3 the baseline. The description adds only the searchId/offset/limit pagination relationship, which is largely mirrored in the schema descriptions themselves.

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?

States a specific verb+resource — a unified code search engine — and names the underlying engines (ripgrep, ast-grep). It does not differentiate itself from siblings like count or find_symbols, and the 'symbol' search type visibly overlaps find_symbols without any clarifying remark.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance: nothing says when to prefer this over count, find_symbols, or list_files, and no conditions for choosing among the six engine types are given. The only usage-adjacent statement concerns pagination mechanics, not tool selection.

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