Searchfox MCP Server
The Searchfox MCP Server provides AI assistants with comprehensive access to Mozilla's code search and analysis service for exploring Mozilla codebases.
Core Capabilities:
Advanced Code Search - Search using exact literal strings or regular expressions with advanced query syntax (symbol:, id:, path:, re: operators). Filter by repository, case sensitivity, language (C++, JavaScript, Rust, etc.), and exclude/include test files, generated files, or third-party code. Path filtering uses glob patterns with substring matching (supports ^ and $ anchoring).
Symbol Analysis - Search for symbols/identifiers and extract complete function/class definitions with intelligent brace-matching for C++, C, Rust, JavaScript, and WebIDL.
Call Graph Analysis - Analyze function call relationships with three modes: calls-from (what a function calls), calls-to (what calls a function), and calls-between (call paths between functions). Supports C++, Java, Kotlin, and Python with configurable traversal depth.
Memory Layout Analysis - View C++ class/struct memory layout including field offsets, sizes, alignment, base classes with offsets, and inheritance hierarchy.
Git Blame - Retrieve commit history (hash, author, date, message) for specific lines or entire files.
File Operations - Retrieve file contents with support for specific line ranges and additional context lines. Search for files matching path patterns.
Multi-Repository Support - Access mozilla-central (default), autoland, comm-central (Thunderbird), mozilla-beta, mozilla-release, and ESR branches.
Important Limitation: Search uses exact literal string matching by default—multiple words are treated as a single string, not OR logic. No built-in phrase matching with quotes. Use separate queries or enable regexp mode for broader searches.
Retrieves file contents from Mozilla repositories via GitHub's raw content API.
Provides access to Mozilla's Searchfox code search service, enabling code search across Mozilla repositories (mozilla-central, autoland, beta, release, ESR branches, and comm-central) and retrieval of file contents from these repositories.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Searchfox MCP Serversearch for 'console.log' in mozilla-central with case sensitivity"
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.
Searchfox MCP Server
A comprehensive Model Context Protocol (MCP) server that provides full access to Mozilla's Searchfox code search and analysis service. This server enables AI assistants to search through Mozilla codebases, analyze code structure, retrieve file contents, and understand call relationships.
Prefer usingsearchfox-cli for agentic workflows (like Claude Code) instead of this MCP.
Features
Advanced Code Search: Unified search with advanced query syntax (symbol:, id:, path:, etc.)
Symbol Analysis: Search for symbols and extract complete definitions
Call Graph Analysis: Analyze function call relationships with three query modes
Memory Layout: View C++ class/struct memory layout with field offsets
Git Blame: Get commit history for specific lines or files
File Operations: Retrieve file contents with line range support
Path Search: Find files matching specific patterns
Multiple Repositories: Support for mozilla-central, autoland, mozilla-beta, ESR branches, and more
Related MCP server: GitBridge
Available Tools (8 Total)
1. search
Unified code search with advanced query syntax and filtering capabilities.
Parameters:
query(string): Search query with optional advanced syntaxsymbol:Name- Symbol search (definitions/declarations)id:Name- Exact identifier matchingpath:dir/file- Path filterpathre:regex- Path regex filtertext:exact- Exact text searchre:pattern- Regular expression pattern
repo(string, optional): Repository to search in (default: "mozilla-central")case_sensitive(boolean, optional): Enable case sensitive searchlimit(number, optional): Maximum number of results (default: 50)context_lines(number, optional): Number of context lines before/after matchesfilters(object, optional): Additional filterslanguage: Filter by language (cpp, c, js, webidl, rust)exclude_tests: Exclude test filesexclude_generated: Exclude generated filesexclude_thirdparty: Exclude third-party filesonly_tests: Include only test files
Example:
{
"query": "symbol:AudioContext path:dom/media",
"filters": {
"language": "cpp",
"exclude_tests": true
}
}2. get_file
Retrieve file contents with optional line range support.
Parameters:
path(string): File path within the repositoryrepo(string, optional): Repository name (default: "mozilla-central")lines(object, optional): Line range to retrievestart(number): Starting line number (1-based)end(number): Ending line number (inclusive)context(number): Additional context lines before/after range
Example:
{
"path": "dom/media/AudioContext.cpp",
"lines": {
"start": 100,
"end": 200,
"context": 5
}
}3. search_paths
Find files by path pattern.
Parameters:
pattern(string): File path pattern to search forrepo(string, optional): Repository to search in (default: "mozilla-central")limit(number, optional): Maximum number of results (default: 100)
Example:
{
"pattern": "AudioContext",
"repo": "mozilla-central"
}4. search_symbols
Dedicated symbol/identifier search with language and path filtering.
Parameters:
symbol(string): Symbol or identifier name to search fortype(string, optional): Search type - "symbol" (default) or "identifier"repo(string, optional): Repository to search in (default: "mozilla-central")path_filter(string, optional): Path filter to narrow resultslimit(number, optional): Maximum number of results (default: 50)language(string, optional): Filter by language (cpp, c, js, webidl, rust)
Example:
{
"symbol": "MediaStream",
"type": "symbol",
"path_filter": "dom/media",
"language": "cpp"
}5. get_definition
Extract complete function/class definitions using intelligent brace-matching.
Parameters:
symbol(string): Symbol name to get definition forrepo(string, optional): Repository to search in (default: "mozilla-central")path_filter(string, optional): Path filter to find the right definitionlanguage(string, optional): Language hint - cpp, c, js, webidl, rust, or "auto" (default: "auto")max_lines(number, optional): Maximum number of lines to extract (default: 500)
Features:
Intelligent brace-matching state machine
Handles nested braces, strings, comments, escape sequences
Supports C++, C, Rust, JavaScript, and WebIDL
Scans backward to find function/class start
Includes initializer lists in C++
Example:
{
"symbol": "AudioContext",
"path_filter": "dom/media",
"language": "cpp"
}6. get_call_graph
Analyze function call relationships with three query modes.
Parameters:
mode(string): Query modecalls-from- What does this function call?calls-to- What calls this function?calls-between- Find call paths between two functions
source_symbol(string): Source symbol/function nametarget_symbol(string, optional): Target symbol (required for calls-between mode)repo(string, optional): Repository to search in (default: "mozilla-central")depth(number, optional): Maximum traversal depth 1-3 (default: 1)
Features:
Results grouped by class/namespace
Overloaded functions collapsed together
Formatted markdown output
Depth control for breadth-first traversal
Language Support:
✅ C++ (full support)
✅ Java, Kotlin, Python (via SCIP indexing)
❌ JavaScript/TypeScript (not supported)
Example:
{
"mode": "calls-from",
"source_symbol": "mozilla::dom::AudioContext::Create",
"depth": 2
}7. get_field_layout
Get C++ class/struct memory layout information.
Parameters:
class_name(string): C++ class or struct namerepo(string, optional): Repository to search in (default: "mozilla-central")
Features:
Shows size and alignment in bytes
Lists base classes with offsets
Shows field offsets, sizes, and types
Handles template class variants
C++ only
Example:
{
"class_name": "mozilla::dom::AudioContext",
"repo": "mozilla-central"
}8. get_blame
Get git blame information for files.
Parameters:
path(string): File path within the repositoryrepo(string, optional): Repository to search in (default: "mozilla-central")start_line(number, optional): Starting line number (default: 1)end_line(number, optional): Ending line number (inclusive)
Features:
Shows commit hash, author, date, and message
Supports line range filtering
Batches commit info requests for efficiency
Formatted markdown output
Example:
{
"path": "dom/media/AudioContext.cpp",
"start_line": 100,
"end_line": 200
}Supported Repositories
mozilla-central(default) - Main development branchautoland- Integration branchmozilla-beta- Beta release branchmozilla-release- Release branchmozilla-esr115,mozilla-esr128,mozilla-esr140- ESR branchescomm-central- Thunderbird codebase
Installation
# Clone the repository
git clone https://github.com/canova/searchfox-mcp.git
cd searchfox-mcp
# Install dependencies
npm install
# Build the project
npm run buildUsage
Claude Desktop Configuration
Add to your claude_desktop_config.json:
{
"mcpServers": {
"searchfox": {
"command": "node",
"args": ["/absolute/path/to/searchfox-mcp/dist/index.js"]
}
}
}Configuration file locations:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.jsonLinux:
~/.config/Claude/claude_desktop_config.json
Other MCP Clients
This server uses stdio transport and follows the MCP protocol specification. Configure your MCP client to run:
node /path/to/searchfox-mcp/dist/index.jsQuery Syntax Examples
Basic Searches
// Simple text search
{"query": "AudioContext"}
// Symbol search
{"query": "symbol:MediaStream"}
// Exact identifier
{"query": "id:nsISupports"}
// Path filtered search
{"query": "AudioNode path:dom/media/webaudio"}
// Regular expression
{"query": "re:Create.*Context"}Advanced Filtering
// C++ code only, exclude tests
{
"query": "symbol:AudioContext",
"filters": {
"language": "cpp",
"exclude_tests": true,
"exclude_generated": true
}
}
// JavaScript in tests only
{
"query": "AudioContext",
"filters": {
"language": "js",
"only_tests": true
}
}Workflow Examples
Understanding a New API:
Search for symbol:
{"query": "symbol:AudioContext"}Get definition:
{"symbol": "AudioContext", "language": "cpp"}See what it calls:
{"mode": "calls-from", "source_symbol": "mozilla::dom::AudioContext::Create"}Find usage:
{"mode": "calls-to", "source_symbol": "mozilla::dom::AudioContext::Create"}
Debugging a Crash:
Get implementation:
{"symbol": "MediaStream::AddTrack"}See what it calls:
{"mode": "calls-from", "source_symbol": "mozilla::dom::MediaStream::AddTrack"}Check blame:
{"path": "dom/media/MediaStream.cpp", "start_line": 100, "end_line": 150}
Memory Layout Analysis:
Get layout:
{"class_name": "mozilla::dom::AudioContext"}Check field sizes and offsets for padding analysis
Understand inheritance hierarchy
Development
# Install dependencies
npm install
# Build the project
npm run build
# Run in development mode with hot reload
npm run dev
# Linting
npm run lint
npm run lint:fix
# Formatting
npm run format
npm run format:checkArchitecture
This MCP server is built with a modular architecture:
src/
├── index.ts # Main server, tool registration
├── types.ts # TypeScript interfaces
├── constants.ts # Constants and mappings
├── tools/ # Tool implementations
│ ├── search.ts # Unified search
│ ├── files.ts # File operations
│ ├── symbols.ts # Symbol tools
│ ├── callgraph.ts # Call graph analysis
│ ├── analysis.ts # Field layout
│ └── blame.ts # Git blame
├── parsers/ # Code parsing utilities
│ ├── definition-extractor.ts # Brace-matching parser
│ └── callgraph-parser.ts # Call graph parsing
└── utils/ # Shared utilities
├── searchfox-client.ts # Searchfox API client
├── github-client.ts # GitHub API client
├── repo-mapping.ts # Repository mappings
├── query-builder.ts # Query syntax parsing
└── filters.ts # Filtering utilitiesRelated Projects
searchfox-cli - Command-line tool for Searchfox (Rust)
Searchfox - Mozilla's code search website
License
Licensed under either of
Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.
Available Tools
2 toolsget_fileC
Get the contents of a specific file from specified repository.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Repository name | mozilla-central |
| path | Yes | File path within the repository |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'Get the contents' but does not disclose behavioral traits such as authentication requirements, rate limits, error handling, or whether it returns raw text or metadata. This leaves significant gaps for a tool that likely interacts with a repository system.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence that efficiently conveys the core purpose without unnecessary words. It is appropriately sized for a simple tool, though it could be slightly more structured by front-loading key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not explain what the tool returns (e.g., file content format, error responses) or address potential complexities like large files or permissions, which are critical for effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for 'repo' and 'path' parameters. The description adds minimal value beyond the schema, as it only reiterates that parameters specify the repository and file path without providing additional context or usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('contents of a specific file'), specifying the action and target. However, it does not explicitly differentiate from the sibling tool 'search_code', which likely searches for code patterns rather than retrieving a specific file's contents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search_code'. The description implies usage for retrieving file contents but lacks explicit context, prerequisites, or exclusions, leaving the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_codeA
Search for code in Mozilla repositories using Searchfox. IMPORTANT: Uses exact string matching only - no search operators, no OR logic, no phrase matching with quotes. Multiple words are treated as a single literal string.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query using exact literal string matching. CRITICAL: Do NOT use multiple words expecting OR logic (e.g., 'profiler raptor' won't find files containing either word separately). Do NOT use quotes around terms (e.g., '"profiler" "raptor"' searches for literal quotes). Use single specific terms, function names, or exact code snippets. For broader searches, use separate queries or enable regexp mode. | |
| repo | No | Repository to search in (e.g., mozilla-central, comm-central) | mozilla-central |
| path | No | Filter results by file path using glob patterns. Path matching uses substring matching - a path matches even if only part of it matches the glob. Use ^ and $ operators to match beginning or end of path (e.g., '^tools/profiler' to match paths starting with tools/profiler, 'profiler$' to match paths ending with profiler). | |
| case | No | Enable case sensitive search (default: case insensitive) | |
| regexp | No | Treat query as regular expression pattern | |
| limit | No | Maximum number of results to return |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: exact string matching only, no search operators, no OR logic, no phrase matching with quotes, and how multiple words are treated. It also implies this is a read-only operation through the search context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with two sentences: the first states the core purpose, and the second provides critical behavioral constraints. Every sentence earns its place by delivering essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no annotations and no output schema, the description provides good contextual completeness. It covers the search methodology constraints and basic usage guidance. The main gap is the lack of information about return format or result structure, which would be helpful given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all 6 parameters thoroughly. The description adds some context about the query parameter's exact matching behavior, but doesn't provide additional semantic meaning beyond what's in the schema descriptions. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Search for code') and resource ('in Mozilla repositories using Searchfox'). It distinguishes from the sibling tool 'get_file' by focusing on search functionality rather than file retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives: it specifies exact string matching only, warns against using multiple words expecting OR logic, and advises using separate queries or regexp mode for broader searches. This gives clear context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
2 tool updates
v1.0.0- First observed
get_file - First observed
search_code
TDQS
The two tools have completely distinct purposes: get_file retrieves specific file contents, while search_code performs code searches across repositories. There is no overlap or ambiguity between these operations, making tool selection straightforward for an agent.
Both tools follow a consistent verb_noun naming pattern (get_file, search_code) with clear, descriptive names that align with their functions. The naming convention is uniform and predictable throughout the set.
With only two tools, the server feels severely under-scoped for a code search and exploration domain. While the tools are clear, the lack of additional operations (e.g., list repositories, browse directories, or more advanced search options) limits functionality and makes the toolset feel incomplete for typical use cases.
The toolset is notably incomplete for a code search server. It provides basic file retrieval and simple string search but lacks essential operations like repository listing, directory navigation, or more sophisticated search capabilities (e.g., with operators). This creates significant gaps that could hinder agent workflows in exploring or analyzing codebases.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
Related MCP Servers
- AlicenseAqualityDmaintenanceProvides LLM-optimized filesystem access with intelligent file pagination for large files, lightning-fast ripgrep-powered code search with regex support, and security sandboxing to safely explore and search codebases.791MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to analyze GitHub repositories, including fetching repository details, searching, and retrieving README content.4672ISC
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to explore, search, and read codebase repositories and API specifications efficiently, with support for file searching, content search via ripgrep, and reading API specs.18ISC
- AlicenseNot gradedqualityDmaintenanceEnables LLMs to query OpenGrok for source code searches, including definitions, symbols, and project listings, returning clickable URLs.2Apache 2.0
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/canova/searchfox-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server