codebase-memory-mcp

Overview Schema Source Related Servers Discussions Admin

search_code

Read-onlyIdempotent

Search codebases by symbols, source snippets, or file paths using graph-ranked text search. Returns ranked matches with context.

Instructions

Graph-ranked text search: compact symbols, full bounded source, or file paths.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`mode`	No		compact
`debug`	No	Add scope_ms/scan_ms/enrich_ms phase timings.
`limit`	No
`regex`	No
`format`	No		tree
`context`	No
`pattern`	Yes
`project`	Yes
`raw_limit`	No
`raw_offset`	No
`match_limit`	No
`path_filter`	No
`file_pattern`	No
`result_limit`	No
`result_offset`	No
`directory_limit`	No
`directory_offset`	No
`source_max_lines`	No
`max_output_tokens`	No
`raw_content_offset`	No	Raw-line byte offset; omit for match-centered preview.

Schema Changelog

Changes observed during successful MCP inspections.

Changed18 schema fields changedv0.11.0Sep 16, 2026

removedInput schema / properties / context / description

Removed value: -"Lines of context around each match (like grep -C). Only used in compact mode."

addedInput schema / properties / debug

Added value: +{
+  "default": false,
+  "description": "Add scope_ms/scan_ms/enrich_ms phase timings.",
+  "type": "boolean"
+}

addedInput schema / properties / directory_limit

Added value: +{
+  "default": 20,
+  "maximum": 64,
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / directory_offset

Added value: +{
+  "default": 0,
+  "minimum": 0,
+  "type": "integer"
+}

removedInput schema / properties / file_pattern / description
```
Removed value: -"Glob for grep --include (e.g. *.go)"
```

addedInput schema / properties / format

Added value: +{
+  "default": "tree",
+  "enum": [
+    "tree",
+    "json"
+  ],
+  "type": "string"
+}

removedInput schema / properties / limit / description

Removed value: -"Max enriched results per call. Default 10. Response includes 'total_grep_matches' and 'total_results' so callers can detect truncation. No offset parameter — raise limit or narrow with file_pattern / path_filter to see more."

addedInput schema / properties / limit / maximum
```
Added value: +500
```

addedInput schema / properties / match_limit

Added value: +{
+  "default": 8,
+  "maximum": 500,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / max_output_tokens

Added value: +{
+  "maximum": 1000000,
+  "minimum": 128,
+  "type": "integer"
+}

removedInput schema / properties / mode / description

Removed value: -"compact: signatures+metadata (default). full: with source. files: just file list."

removedInput schema / properties / path_filter / description

Removed value: -"Regex filter on result file paths (e.g. ^src/ or \\.(go|ts)$)"

addedInput schema / properties / raw_content_offset

Added value: +{
+  "description": "Raw-line byte offset; omit for match-centered preview.",
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / raw_limit

Added value: +{
+  "default": 5,
+  "maximum": 100,
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / raw_offset

Added value: +{
+  "default": 0,
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / result_limit

Added value: +{
+  "default": 10,
+  "maximum": 500,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / result_offset

Added value: +{
+  "default": 0,
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / source_max_lines

Added value: +{
+  "default": 20,
+  "maximum": 200,
+  "minimum": 1,
+  "type": "integer"
+}

Changed2 schema fields changedv0.10.4Aug 14, 2026
- addedInput schema / properties / limit / minimum
```
Added value: +1
```
- changedOutput schema / (root)
```
Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
```

Changed1 schema field changedv0.9.0Jul 8, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}

First observedv1.0.0Jun 9, 2026

TDQS

C2.8/5.0

Behavior3/5

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

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the useful behavioral detail that results are graph-ranked and that modes vary between symbols, full source, and file paths. It does not disclose output shape, pagination behavior, or mode-specific limits, but the annotation coverage lowers the bar.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short and free of fluff, which is positive, but it is closer to a tagline than a structured explanation. For a tool with 20 parameters and no output schema, the brevity borders on under-specification rather than efficient completeness.

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

Completeness2/5

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

Given the high complexity (20 parameters, 10% schema coverage, no output schema), the description is far from complete. It does not explain result formats, how graph ranking affects results, the meaning of raw offsets, or the tradeoffs between modes. An agent would likely need to probe the tool or inspect sibling definitions to use it confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

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

Schema description coverage is only 10%, so the description must compensate for the 20 parameters. It partially does by explaining the mode enum values ('compact symbols, full bounded source, or file paths'), but pattern, project, limit, regex, format, context, filters, offsets, and output token limits are left unexplained. This is insufficient for such a parameter-heavy tool.

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 states a specific action ('search') on a clear resource ('code') and names three distinct output modes: compact symbols, full bounded source, or file paths. It is reasonably clear but does not explicitly differentiate itself from likely siblings such as search_graph or get_code_snippet.

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?

The description gives no guidance on when to use this tool versus alternatives. It does not mention search_graph for graph-oriented queries, get_code_snippet for retrieving a known snippet, or any exclusions. Usage context must be inferred from the name and the phrase 'graph-ranked text search.'

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

Deploy Server

search_code

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools