What can you do with this server?

Synapse MCP is a read-only structural code context server that connects your local repository to AI assistants, enabling intelligent, on-demand codebase exploration without vector databases, embedding APIs, or copy-pasting files. * get_project_index — Generate a compressed semantic map of all exported symbols (functions, classes, interfaces, types) with signatures but no bodies. Supports glob filtering via file_pattern and optionally includes non-exported symbols. Useful as a first call when exploring an unfamiliar codebase. * get_semantic_context — Retrieve a file's full content plus its local dependency graph (following import hops up to a configurable depth). Supports outline_only mode to return only signatures, reducing token usage by 70–90%. * get_project_tree — View a structured directory tree of the repository, respecting .gitignore rules, with configurable depth and optional display of hidden files. * get_changed_files — List files changed since a given git ref (default: HEAD~1), grouped by status (Added / Modified / Deleted / Renamed). Optionally includes full unified diff output and supports glob filtering. * search_codebase — Perform fast text or regex searches across the project, returning matches with file paths and line numbers. Supports case-sensitive search, regex mode, glob-scoped search, and a configurable result cap. Uses ripgrep when available, falling back to a pure Node.js scanner.

How do I use Synapse MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Synapse MCP show me the project index" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Synapse MCP

by Juanmidev1

Overview Schema Related Servers Score Discussions

TypeScript

Local

Synapse MCP

License: MIT Node ≥ 18 Tests: 301

A structural code context server that connects your local repository to AI assistants via the Model Context Protocol.

Instead of copy-pasting files into a prompt, Synapse lets your AI assistant dynamically explore your codebase — pulling only the code it needs, when it needs it. The result: less context waste, smarter answers, and a workflow that scales to large projects — with no vector database or embedding API to set up.

AI Assistant  ──MCP──►  Synapse MCP  ──fs/git──►  Your Repository
   (pulls)               (server)                   (local)

Status: Early-stage, actively developed. Contributions and bug reports are welcome — see Contributing.

Why Synapse?

Most AI coding tools already index files. Synapse solves a different problem: context quality at scale.

Problem	Synapse solution
Reading an entire file when you only need its API surface	`get_semantic_context` with `outline_only` — signatures only, ≤ 50% of full content
AI doesn't know what files exist in an unfamiliar project	`get_project_index` — full symbol map at ≤ 40% of raw source size, one call
"Review my changes" requires pasting the diff manually	`get_changed_files` — structured git diff, git-aware by default
Dependency rabbit holes filling the context window	Configurable `depth` cap on import traversal

The compression ratios above are enforced as automated test budgets — not marketing estimates.

Why not vector embeddings?

Most code-context MCP servers use semantic search backed by a vector database (e.g. Milvus, Qdrant) and an embedding API (OpenAI, VoyageAI). That gives them a real capability Synapse doesn't have: finding code by conceptual meaning ("find the authentication logic") rather than by structure or text.

Synapse trades that capability for a different set of properties:

Zero external dependencies — no API keys, no vector database, no embedding provider to configure
Zero recurring cost — no per-token embedding charges, no hosted database bill
Fully local and deterministic — the same input always produces the same output, nothing leaves your machine, nothing to index ahead of time
Instant on any repo — no indexing step before first use (see Performance: 120–257 ms on real repos)

If you need natural-language semantic search across millions of lines in many languages, a vector-backed server is the better tool. If you want structural context (signatures, dependency graphs, diffs) without standing up infrastructure, Synapse is built for that.

Related MCP server: CodeAlive MCP

Tools

`get_project_index`

Returns a compressed semantic map of the entire project: all exported functions, classes, interfaces, types, enums, and top-level constants with their signatures — no bodies. The right first call when exploring an unfamiliar codebase.

# Project Index: my-app (47 files, 312 symbols)

## src/services/user-service.ts
  UserService (class) [export]
    constructor(db: Database)
    findById(id: string): Promise<User | null>
    create(data: CreateUserDto): Promise<User>

## src/models/user.ts
  User (interface) [export]
    id: string
    email: string
    createdAt: Date
  createUser(data: Partial<User>): User [export]

Parameters: file_pattern (glob to narrow scope), include_non_exported, output_format ("markdown" default · "json" for structured output)

Use output_format: "json" to get the raw symbol data as a structured object, which is easier to post-process programmatically:

{
  "root": "/path/to/project",
  "totalFiles": 47,
  "totalSymbols": 312,
  "files": [
    {
      "relativePath": "src/services/user-service.ts",
      "language": "typescript",
      "symbols": [...]
    }
  ]
}

Large projects: output grows linearly with the number of exported symbols. For monorepos or projects with 500+ files, use file_pattern to scope the index to one area at a time — e.g. "src/services/**/*.ts".

`get_semantic_context`

Returns a file's content alongside its local dependency graph — everything the AI needs to understand the code in context.

Add outline_only: true to get signatures without implementation bodies. Output is enforced by the benchmark suite to be ≤ 50% of full content length, while preserving full structural understanding.

Parameters: file_path (required), depth (import hops, default: 2), outline_only, output_format ("markdown" default · "json" for structured output)

`get_changed_files`

Lists files changed since a git ref, grouped by status (Added / Modified / Deleted / Renamed), with optional line counts and full unified diff.

Changed files since `main` (8 files):

**Added (2):**
  src/services/payment.ts (+120 −0)
  tests/unit/payment.test.ts (+89 −0)

**Modified (5):**
  src/models/order.ts (+14 −3)
  ...

**Summary:** +245 −18 lines

Parameters: base_ref (default: HEAD~1), include_diff, file_pattern

`get_project_tree`

Structured view of the repository, respecting .gitignore rules.

Parameters: path, max_depth, show_hidden

`search_codebase`

Fast text or regex search across the project, returning matches with file paths and line numbers. Uses ripgrep when available, falls back to a pure Node.js scanner.

Parameters: query (required), file_pattern, is_regex, max_results

Language support

Synapse uses ts-morph (TypeScript compiler API) for deep analysis of TypeScript and JavaScript. For other languages, it applies regex-based extraction of function and class names.

Feature	TypeScript / JS	Python · Go · Rust	Other
`get_project_tree`	✓	✓	✓
`search_codebase`	✓	✓	✓
`get_semantic_context` — full source	✓	✓	✓
`get_semantic_context` — dependency graph	✓	—	—
`get_semantic_context outline_only`	✓ full signatures	✓ names only	—
`get_project_index`	✓ full signatures	✓ names only	—

Dependency graph traversal (following import/require chains) is TypeScript/JavaScript only. For all other languages, Synapse still reads and searches files normally — it just won't walk the import graph.

Note: dependency graph traversal follows both relative imports (./foo, ../bar) and path aliases configured via tsconfig.json compilerOptions.paths (e.g. @/components/Foo), as long as a tsconfig.json is present at the project root. Projects without a tsconfig.json fall back to relative-only resolution.

Installation

Global install (recommended):

npm install -g synapse-code-mcp

Run without installing:

npx synapse-code-mcp --root /path/to/your/project

Setup

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "synapse": {
      "command": "npx",
      "args": ["synapse-code-mcp", "--root", "/absolute/path/to/your/project"]
    }
  }
}

Claude Code (CLI)

claude mcp add synapse -- npx synapse-code-mcp --root /path/to/your/project

Or add directly to ~/.claude/settings.json:

{
  "mcpServers": {
    "synapse": {
      "command": "npx",
      "args": ["synapse-code-mcp", "--root", "/path/to/your/project"]
    }
  }
}

Cursor

Add to .cursor/mcp.json in your home directory or project root:

{
  "mcpServers": {
    "synapse": {
      "command": "npx",
      "args": ["synapse-code-mcp", "--root", "/path/to/your/project"]
    }
  }
}

Windsurf

Add to ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "synapse": {
      "command": "npx",
      "args": ["synapse-code-mcp", "--root", "/path/to/your/project"]
    }
  }
}

Tip: Replace /path/to/your/project with the absolute path to the repository you want to serve. You can run multiple Synapse instances — one per project — each with a different key under mcpServers.

Configuration

CLI flags

Options:
  --root <path>                  Project root directory (default: cwd)
  --max-file-size <bytes>        Skip files larger than this (default: 524288 = 512 KB)
  --max-search-results <n>       Cap on search results returned (default: 50)
  --max-tree-depth <n>           Maximum directory depth for tree view (default: 5)
  --max-dependency-depth <n>     Import hops for semantic context (default: 2)
  --log-level <level>            debug | info | warn | error (default: info)

Per-project config file

Drop a synapse.config.json at your project root to override defaults for that project:

{
  "maxFileSize": 1048576,
  "maxDependencyDepth": 3,
  "extraIgnorePatterns": ["*.generated.ts", "**/__mocks__/**"],
  "cacheEnabled": true
}

cacheEnabled (default true) controls the on-disk incremental index cache (.synapse-cache/index.json) used by get_project_index and get_semantic_context to skip re-parsing unchanged files. Set to false to disable it.

All fields are optional. CLI flags take precedence over synapse.config.json.

Performance

Measured on real open-source TypeScript repositories (single run, --depth 1 clone, no warm cache):

Repository	Files indexed	Time	Heap growth
zod	55	120 ms	3 MB
TypeScript compiler `src/`	247	257 ms	24 MB

The automated benchmark suite enforces upper bounds on a synthetic fixture (3 000 minimal .ts files) to catch regressions under worst-case conditions:

Operation	CI budget (synthetic fixture)
`get_project_tree` — 3 000 files	5 s
`get_semantic_context` — depth 3	10 s
`get_changed_files`	2 s
`get_project_index` — 60 files	30 s
`get_project_index` — 600 files	120 s

The CI budgets are deliberately generous safety margins, not performance estimates — they exist to catch catastrophic regressions (e.g. an accidental O(n²) bug), not to predict real-world timing. The real-repo numbers above are the meaningful reference for expected performance. For large monorepos (1 000+ files), use file_pattern to scope the index to one area at a time.

Security

Synapse is a read-only server. It never writes to the filesystem or modifies the git repository.

Path traversal protection — every file read goes through resolveAndValidate(root, path), which throws a PATH_ESCAPE error if the resolved path escapes the project root. The AI client receives the error code, never the file contents.
Root scoping — only the directory tree under --root is accessible. Paths pointing outside (e.g. ../../etc/passwd) are rejected at the validation layer.
File size cap — files larger than maxFileSize (default 512 KB) are rejected before reading.
Binary detection — compiled artifacts and binary files are detected and skipped automatically.
No outbound network calls — Synapse communicates only over the local stdio pipe to the MCP client. It makes no HTTP requests.

Suggested workflows

Explore a new codebase:

1. get_project_index()
   → Understand the full shape of the project in one call

2. get_semantic_context("src/core/engine.ts", outline_only: true)
   → Inspect a module's API surface without reading implementation

3. get_semantic_context("src/core/engine.ts")
   → Read full source + dependency graph for the relevant file

Code review before a PR:

1. get_changed_files(base_ref: "main")
   → See what changed, grouped and summarised

2. get_changed_files(base_ref: "main", include_diff: true)
   → Full unified diff in context

3. get_semantic_context("src/changed-file.ts")
   → Understand the context around a changed file

Debug a feature:

1. search_codebase("handlePayment")
   → Find where the symbol is defined and used

2. get_semantic_context("src/services/payment.ts", depth: 3)
   → Pull the file + all its local dependencies

Requirements

Node.js ≥ 18
Git — required only for get_changed_files
ripgrep (optional) — significantly faster search; Synapse falls back to a pure Node.js scanner if rg is not on $PATH

Development

git clone https://github.com/Juanmidev1/synapse-code-mcp.git
cd synapse-code-mcp
npm install

npm run dev          # watch mode (tsx, no compile step)
npm test             # run all tests (Vitest)
npm run typecheck    # type-check without emitting
npm run lint         # ESLint
npm run build        # compile to dist/

Test with MCP Inspector

npm run build
npx @modelcontextprotocol/inspector dist/index.js --root .

This opens a browser UI where you can invoke all tools interactively and inspect their input/output.

Project structure

src/
  index.ts              CLI entry point, argument parsing
  server.ts             MCP server, tool registration
  tools/                Thin tool handlers (validation + formatting only)
  core/
    fs/                 File tree building, file reading, ignore resolution
    search/             ripgrep adapter + pure-Node fallback
    analysis/           Dependency graph (ts-morph), outline extractor, project indexer, index cache
    git/                Git adapter (diff, changed files)
  config/               Config loading and Zod validation
  types/                Shared TypeScript interfaces
  utils/                Logger (pino), path helpers, typed errors
tests/
  unit/                 Per-module unit tests
  integration/          Tool handler integration tests
  protocol/             End-to-end MCP protocol tests (InMemoryTransport)
  performance/          Benchmark suite with time and heap budgets
  build/                Tests against the compiled dist/ output (catches source-vs-build divergence)

Roadmap

See ROADMAP.md for what is planned and what ideas are open for community contributions.

Contributing

This project is in active early development. Bug reports, feature requests, and pull requests are all welcome — the codebase is intentionally small and straightforward to navigate.

CONTRIBUTING.md — how to set up the environment, run tests, commit conventions, and architectural rules
CODE_OF_CONDUCT.md — community standards (Contributor Covenant 2.1)
ROADMAP.md — what is planned and what is open for community PRs

New to the project? Browse issues tagged good first issue for the best entry points.

License

MIT

Available Tools

5 tools

get_changed_filesA

Returns a list of files changed since a git ref (default: HEAD~1), grouped by status (added/modified/deleted). Optionally includes the full unified diff. Use this to understand what changed in a branch or commit.

ParametersJSON Schema

Name	Required	Description
`base_ref`	No	Git ref to diff against (branch, tag, or commit SHA). Default: HEAD~1.
`include_diff`	No	Include the full unified diff output (max 50 KB). Default: false.
`file_pattern`	No	Glob pattern to filter changed files, e.g. "*/.ts". Default: all files.

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations, description carries full burden. It adds helpful context like default ref, optional diff with size limit (50 KB), and grouping by status, but does not address performance, git environment requirements, or edge cases.

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

Conciseness5/5

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

Two sentences conveying purpose, behavior, and usage. No redundant or filler words. Very efficient.

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?

Without output schema, description could specify the exact return structure (e.g., list of file paths with status). Also missing prerequisites like needing a git repo. Adequate but not comprehensive.

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 covers all 3 parameters (100% coverage), baseline 3. Description adds value by stating the default for base_ref and the size limit for include_diff, which are not in schema.

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?

Description clearly states it returns a list of files changed since a git ref, grouped by status, with optional diff. This distinguishes it from sibling tools focused on project structure and search.

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?

Description includes 'Use this to understand what changed in a branch or commit,' providing clear context. However, it does not explicitly state when not to use it or mention alternative tools.

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

get_project_indexA

Returns a compressed semantic map of the entire project: all exported functions, classes, interfaces, and types with their signatures — no implementation bodies. Ideal for getting an overview of a large codebase in a single call (~500 tokens). Call this first when exploring an unfamiliar project.

ParametersJSON Schema

Name	Required	Description	Default
`include_non_exported`	No	Include non-exported symbols in addition to exports. Default: false.
`file_pattern`	No	Glob to restrict which files to index (relative to project root), e.g. "src/*/.ts".

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, but the description discloses the tool returns only exported symbols with signatures, no implementation bodies, and is compressed (~500 tokens). Lacks mention of any side effects or permissions, but adequate for a read-only extraction tool.

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

Conciseness5/5

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

Two sentences, front-loaded with the primary purpose, no extraneous words.

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?

Given no output schema, the description fully explains the return value and provides usage context and efficiency estimate, making it complete for this tool's complexity.

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?

100% schema description coverage means the schema already documents both parameters; the description adds no additional parameter-level detail, so baseline score of 3 is appropriate.

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?

The description clearly states the tool returns a compressed semantic map of the entire project including exported signatures without implementations, and distinguishes from siblings by focusing on overview efficiency and token size.

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?

Explicitly recommends calling this first when exploring an unfamiliar project and notes it's ideal for a single call overview, but does not mention when not to use it or contrast with sibling tools.

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

get_project_treeA

Returns a structured tree view of the project repository, respecting .gitignore rules.

ParametersJSON Schema

Name	Required	Description
`path`	No	Subdirectory to list (relative to project root). Defaults to root.
`max_depth`	No	Maximum depth to traverse. Default: config value.
`show_hidden`	No	Include hidden files/dirs (starting with dot). Default: false.

TDQS

A3.7/5.0

Behavior3/5

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

The description mentions that the tree view respects .gitignore rules, which is a behavioral detail. However, with no annotations provided, the description carries the full burden; it does not disclose result format, recursion behavior (though max_depth parameter suggests depth control), performance implications, or whether it includes file contents. Some transparency but not comprehensive.

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

Conciseness5/5

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

The description is a single sentence of 12 words, no redundant information. It front-loads the core purpose (returns a tree view) and appends the key rule (respects .gitignore). Every word earns its place.

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?

Given the tool has 3 parameters, no output schema, and simple functionality, the description is somewhat complete but lacks explanation of the return format (e.g., JSON, list) or behavior with large directories. It covers the main constraint (.gitignore) but not other aspects like depth or hidden files (though parameters handle those). More detail would be helpful.

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 coverage is 100%, so the input schema already describes each parameter (path, max_depth, show_hidden) with adequate descriptions. The tool description adds no additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.

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?

The description clearly states it returns a structured tree view of the project repository while respecting .gitignore rules. This differentiates it from sibling tools like get_changed_files (diffs), get_project_index (index), get_semantic_context (semantic), and search_codebase (search). The verb 'returns' and resource 'project repository' are specific.

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

Usage Guidelines3/5

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

The description implies the tool is for browsing the project's directory structure, but it does not explicitly state when to use it versus alternatives or provide any exclusions or prerequisites. No guidance on when not to use this tool.

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

get_semantic_contextB

Returns the content of a file along with its local dependency tree, providing rich context for understanding the code.

ParametersJSON Schema

Name	Required	Description
`file_path`	Yes	Path to the file to analyze (relative to project root).
`depth`	No	How many import hops to follow. Default: config value.
`outline_only`	No	Return function/class/interface signatures without implementation bodies. Reduces tokens by 70–90%. Default: false.

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. While it states the core function (return content and dependency tree), it does not mention potential performance impacts, required permissions, file system access, or any side effects. For a tool that may perform heavy analysis (dependency traversal), this is insufficient.

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

Conciseness5/5

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

The description is a single concise sentence with a front-loaded verb ('Returns'). Every word is meaningful and there is no redundancy. It is efficiently structured.

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?

Without an output schema, the description should fully explain what is returned. 'Rich context' is vague; it does not specify the format of the dependency tree or whether it includes full file content. For a tool that returns complex data, this leaves significant ambiguity.

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 coverage is 100%, so the description adds minimal value beyond the schema. It does not explain the practical implications of the depth parameter or how outline_only reduces tokens. The baseline of 3 is appropriate as the description does not enhance parameter understanding.

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?

The description clearly states the tool returns file content and its local dependency tree, which is a specific verb+resource pairing. This distinguishes it from sibling tools like get_changed_files (returns list of changed files) and get_project_tree (returns directory structure). The purpose is unambiguous and well-defined.

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

Usage Guidelines3/5

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

The description implies usage for code understanding but does not explicitly state when to use this tool versus alternatives. There is no mention of when not to use it or which sibling tool to choose instead. The usage context is implied but not directly guided.

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

search_codebaseA

Searches the codebase for text or regex patterns, returning matches with file paths and line numbers.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Text or regex pattern to search for.
`is_regex`	No	Treat query as a regular expression. Default: false.
`file_pattern`	No	Glob pattern to restrict search scope (e.g. "*/.ts").
`case_sensitive`	No	Case-sensitive search. Default: false.
`max_results`	No	Maximum number of results. Default: config value.

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden but only states basic functionality (searching and returning matches). It does not disclose whether the tool is read-only, performance implications, or any side effects—though as a search tool, this may be less critical. It provides the core behavior but lacks depth.

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

Conciseness5/5

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

The description is a single, well-structured sentence that front-loads the action and output. Every word is informative and there is no redundancy.

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?

Given the absence of an output schema and the moderate complexity (5 parameters, no enums), the description is minimally adequate. It covers the main purpose but does not explain the structure of results or any advanced behavior like result ordering or error handling.

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 coverage is 100%, so baseline is 3. The description does not add any meaning beyond the schema; it summarizes the tool's purpose but does not elaborate on parameter semantics or usage nuances.

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?

The description clearly identifies the tool as searching the codebase for text or regex patterns, returning specific information (file paths and line numbers). It distinguishes itself from sibling tools like 'get_changed_files' and 'get_project_tree' which serve different purposes.

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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention when not to use it. The agent receives no context about prioritization or exclusions.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: changes, semantic index, tree structure, file context with dependencies, and text search. No overlap.

Naming Consistency4/5

Most tools follow 'get_<noun>' pattern, but 'search_codebase' uses a different verb. However, all names are snake_case and descriptive, with minor inconsistency.

Tool Count5/5

Five tools is ideal for a code exploration server, covering the key tasks without bloat.

Completeness4/5

Core exploration needs are met (changes, overview, structure, context, search). Minor gaps like call hierarchy or references exist but are beyond basic requirements.

Maintenance

ActivityActive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
Cortex C
io.cortex.mcp
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Developer Tools Monitoring Observability
312
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
ContextStream MCP Server
io.github.contextstream
Project memory, semantic code search, and grounded agent context.
Knowledge & Memory Code Analysis RAG Systems
139

Related MCP Servers

code-index-mcp
Code Analysis Developer Tools Search
johnhuang316
A
license
A
quality
A
maintenance
A Model Context Protocol (MCP) server that helps large language models index, search, and analyze code repositories with minimal setup
Updated a month ago (2026-07-27 08:14 UTC)
14
1,005
MIT
CodeAlive MCPofficial
Code Analysis RAG Systems Developer Tools
CodeAlive-AI
A
license
Not graded
quality
A
maintenance
A Model Context Protocol server that enhances AI agents by providing deep semantic understanding of codebases, enabling more intelligent interactions through advanced code search and contextual awareness.
Updated 19 days ago (2026-08-16 13:58 UTC)
88
MIT
MCP Qdrant Codebase Embeddings
steiner385
-
license
Not graded
quality
Not graded
maintenance
A Model Context Protocol server that provides semantic understanding of codebases using Qdrant vector database, enabling AI assistants to search files by purpose, discover relationships between files, analyze architecture, and identify refactoring opportunities.
Updated a year ago (2025-06-22 00:41 UTC)
Local Project Sync
Code Analysis Developer Tools
xueshanisusan
F
license
B
quality
D
maintenance
A Model Context Protocol (MCP) server that enables AI applications to access and analyze local code repositories without manual uploads, providing file listing, content reading, code searching, and project structure analysis capabilities.
Updated a year ago (2025-07-31 19:47 UTC)
7

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Juanmidev1/synapse-code-mcp'

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

Synapse MCP

Why Synapse?

Why not vector embeddings?

Tools

get_project_index

get_semantic_context

get_changed_files

get_project_tree

search_codebase

Language support

Installation

Setup

Claude Desktop

Claude Code (CLI)

Cursor

Windsurf

Configuration

CLI flags

Per-project config file

Performance

Security

Suggested workflows

Requirements

Development

Test with MCP Inspector

Project structure

Roadmap

Contributing

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

CodeAlive MCPofficial

Latest Blog Posts

MCP directory API

`get_project_index`

`get_semantic_context`

`get_changed_files`

`get_project_tree`

`search_codebase`