Allows searching and browsing code across multiple Git repositories. Users can register local Git projects, search for keywords using ripgrep, retrieve file trees, and read file contents.
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., "@git-finder-mcp Search for code related to payment"
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.
사내 여러 Git 프로젝트에서 코드를 검색해주는 MCP 서버. Claude Code에 연결하여 자연어로 코드 검색이 가능합니다.
npm install
claude mcp add git-finder -- npx tsx /path/to/git-finder-mcp/src/index.ts끝! 별도의 빌드나 ripgrep 설치가 필요 없습니다.
@vscode/ripgrep 패키지가 ripgrep 바이너리를 자동으로 포함합니다.
tsx가 TypeScript를 직접 실행하므로 빌드 단계가 없습니다.
Node.js 18+
.claude.json에 직접 추가할 수도 있습니다:
{
"mcpServers": {
"git-finder": {
"command": "npx",
"args": ["tsx", "/path/to/git-finder-mcp/src/index.ts"]
}
}
}Related MCP server: CodeSense MCP
Claude Code에서 자연어로 사용합니다:
# 프로젝트 등록
"이 경로를 payment-service라는 이름으로 등록해줘: /Users/box/work/monorepo/packages/payment"
# 코드 검색
"결제 관련 코드 찾아줘"
"인증 미들웨어 어떤 프로젝트에서 쓰고 있어?"
"공통 유틸 함수 중에 날짜 관련된 거 보여줘"
# 프로젝트 구조 확인
"payment-service 프로젝트 구조 보여줘"등록한 프로젝트 목록은 홈 디렉토리에 저장됩니다:
~/.git-finder-mcp/projects.jsonMCP 버전이 바뀌거나 재설치해도 데이터가 유지됩니다.
Tool | 설명 |
| 로컬 경로의 Git 프로젝트를 등록 |
| 등록된 프로젝트 제거 |
| 등록된 프로젝트 목록 + 설명 반환 |
| 키워드로 코드 검색 (ripgrep 사용) |
| 프로젝트 파일/폴더 구조 반환 |
| 특정 파일 내용 읽기 |
ripgrep이 .gitignore를 자동 반영하며, 추가로 다음을 제외합니다:
폴더: node_modules, dist, build, .git, .next, coverage, pycache, .turbo, .cache
파일: *.lock, *.map, *.min.js, *.min.css
바이너리: 이미지, 폰트, 오디오, 비디오 등
현재 버전에서는 보류하고, 필요에 따라 추후 도입할 기능들:
도입 조건: 프로젝트가 30개 이상으로 늘어나거나, grep 기반 검색의 정확도가 부족할 때
효과: "결제"로 검색하면 "payment", "checkout", "billing" 등 의미적으로 관련된 코드까지 자동 검색 (현재는 Claude가 키워드 확장으로 보완)
필요 기술: 임베딩 모델 (OpenAI text-embedding-3-small 등), 벡터 DB (ChromaDB 등)
고려사항: 코드 인덱싱 시 임베딩 API 비용 발생, 코드 청크 분할 전략 (함수/클래스 단위) 필요
도입 조건: 팀원들이 이 MCP를 자주 사용할 때
효과: npx -y git-finder-mcp 한 줄로 사용 가능. 로컬 clone / npm install 불필요
필요 작업: dist/ 빌드 후 npm publish, bin 필드 추가, tsx를 devDependency로 전환
도입 조건: 로컬에 clone 없는 프로젝트도 등록하고 싶을 때
기능: add_project에 url 파라미터 추가. MCP 서버가 자동 clone/pull 수행
고려사항: private repo 인증 (SSH key / Personal Access Token), clone 저장 경로 관리, 자동 최신화 주기 설정
로컬 경로의 Git 프로젝트를 등록합니다. 등록된 프로젝트는 search_code, get_file_tree, read_file로 검색할 수 있습니다.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 프로젝트 이름 (예: payment-service) | |
| path | Yes | 프로젝트의 로컬 절대 경로 (예: /Users/box/work/my-monorepo/packages/payment) | |
| description | No | 프로젝트 설명 (예: 결제/주문 처리 서비스) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It provides a meaningful post-condition ('registered projects can be searched') and an implicit prerequisite ('Git project at local path'). However, it omits details like idempotency, duplicate handling, or whether the path is validated.
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 two short sentences, front-loaded with the primary action and followed by context about post-registration usage. No unnecessary words.
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 simple registration tool with a fully documented schema and no output schema, the description gives enough context: what it does and what it enables. It could mention errors or return values, but these are not critical given the tool's simplicity.
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?
The schema covers 100% of parameters with clear descriptions (path, name, description). The tool description does not add extra parameter-level meaning, so the baseline of 3 applies.
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 action ('register a Git project at a local path') and its resource, and immediately distinguishes it from search-oriented siblings by noting that registered projects become searchable via search_code, get_file_tree, and read_file.
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 implies when to use the tool: before using the search tools on a project. It clearly positions add_project as a prerequisite for those tools, though it does not explicitly mention alternatives like remove_project or list_projects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
프로젝트의 파일/폴더 구조를 반환합니다. 프로젝트 구조를 파악하거나 검색 범위를 좁힐 때 사용합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | 트리 깊이 (기본: 3) | |
| project | Yes | 프로젝트 이름 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the core behavior (returns file/folder structure) and implies a safe read operation, but does not describe return format, depth limits beyond schema, or any side effects. For a simple read tool this is acceptable but not rich.
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?
Two concise sentences, front-loaded with the core function and followed by usage context. No redundant or filler content.
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 simple read-only tool with two parameters and no output schema, the description sufficiently covers purpose and usage. It lacks an explicit description of the return format, but the concept of a file tree is intuitive and the sibling tools provide context.
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 has 100% coverage with descriptions for both 'project' and 'depth' including the default value. The description adds no additional parameter semantics beyond what the schema already provides.
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?
Description clearly states 'Returns the file/folder structure of the project' with a specific verb and resource, distinguishing it from siblings like search_code and read_file. The second sentence adds a use case ('when narrowing search scope'), which reinforces its unique role.
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?
Provides clear usage context: 'used when understanding the project structure or narrowing down the search scope.' This implies a contrast with search tools, though no sibling tool is explicitly named or excluded.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
등록된 프로젝트 목록과 설명을 반환합니다. 검색 전에 호출하여 어떤 프로젝트가 있는지 파악하고, 설명을 기반으로 검색 범위를 좁힐 수 있습니다.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of conveying behavioral traits. It implies a read-only operation via 'returns' but does not explicitly state that it has no side effects, requires no permissions, or does not modify data. It also does not disclose any limitations like pagination or ordering. This is acceptable but not rich.
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 two short sentences. The first sentence states the core purpose, and the second adds usage guidance. Every word earns its place; there is no fluff or repetition.
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 low complexity (0 params, no output schema), the description is reasonably complete. It covers the main return content ('list and descriptions') and the recommended usage context. However, it does not detail the exact structure of the returned data (e.g., field names or types), which would be expected without an output schema. Still, for a simple listing tool, it is sufficient for initial selection.
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?
The tool has 0 parameters, so the baseline is 4 according to the rubric. The description adds value by explaining the returned content (list and descriptions) and its use, even though it does not need to provide parameter-level semantics.
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 function: 'returns the list and descriptions of registered projects.' The verb '반환' (returns) and the resource '프로젝트 목록과 설명' (list and descriptions of projects) make the purpose unambiguous. It also distinguishes itself from siblings like add_project/remove_project (mutations) and search_code/read_file (content 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 gives explicit context for when to use: 'call before searching to understand which projects exist and narrow down the search scope based on the descriptions.' This provides clear usage guidance but does not explicitly mention when not to use or alternative tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
특정 파일의 내용을 읽어 반환합니다. 검색 결과에서 발견한 파일의 전체 내용을 확인할 때 사용합니다. 등록된 프로젝트 경로 내의 파일만 읽을 수 있습니다.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | 읽을 파일의 절대 경로 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses a key constraint: only files within registered project paths can be read, which is valuable. It does not mention error handling or return format, but for a read-only operation this is adequate.
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?
Three short sentences: first states the action, second gives usage, third gives a limitation. No redundant information, front-loaded with the primary purpose.
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 single-parameter read tool with full schema coverage and no output schema, this description covers purpose, usage, and constraints sufficiently. The sibling tools have different functions, so no further context is needed.
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?
The input schema already describes 'path' as an absolute path, achieving 100% coverage. The description adds no extra parameter details beyond referencing a 'specific file', so it meets the baseline but doesn't enhance.
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 uses the specific verb 'reads and returns' with the resource 'specific file', clearly distinguishing it from sibling tools like search_code and get_file_tree. It also adds context about checking full contents of files from search results.
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?
It explicitly states when to use: to check the full contents of a file found in search results. It also mentions the constraint of only registered project paths, implying not for external files, but doesn't name specific alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
등록된 프로젝트를 제거합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 제거할 프로젝트 이름 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only says 'removes' and does not clarify whether this is permanent, whether it deletes associated files, or what happens to the project's data. The word 'registered' provides a hint that it may only remove a registration, but this is not elaborated.
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, focused sentence that delivers the core purpose without any wasted words. It is front-loaded and easily scannable.
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 mutation tool with no annotations and no output schema, the description is too sparse. It does not mention side effects, error conditions, reversibility, or any safety context. The simplicity of the tool does not excuse the lack of behavioral detail.
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?
The schema includes a description for the single 'name' parameter, covering 100% of parameters. The tool description adds no additional meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
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 'Removes the registered project' clearly states the verb and resource, and it is distinct from sibling tools like add_project and list_projects. It immediately conveys what the tool does without ambiguity.
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 implies the tool should be used when removing a project, but it provides no explicit guidance on when to use it versus other tools, nor does it mention prerequisites or alternative approaches. The purpose alone suggests the usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
등록된 프로젝트들에서 키워드로 코드를 검색합니다. ripgrep을 사용하며, 특정 프로젝트로 제한하거나 파일 패턴을 지정할 수 있습니다. 한국어 키워드는 영어 키워드로도 검색하면 더 정확한 결과를 얻을 수 있습니다.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | 검색할 키워드 (예: payment, createOrder, 결제) | |
| project | No | 특정 프로젝트로 검색 범위 제한 (선택, 미지정시 전체 프로젝트 검색) | |
| file_pattern | No | 파일 패턴 필터 (선택, 예: "*.ts", "*.controller.ts", "*.service.ts") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the use of ripgrep and the ability to limit search scope, adding value beyond the raw schema. However, it does not mention output format, read-only nature, or any limitations. With no annotations provided, the description carries the full burden and only partially fulfills it.
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 compact and effective: two sentences that state purpose, capabilities, and a usage tip. It is front-loaded with the main action, with no unnecessary detail.
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 tool with no output schema and no annotations, the description should explain what the tool returns or any important behavior. It covers the core search operation and constraints, but omits return value details (e.g., file paths, snippets) and potential edge cases, leaving the agent with incomplete information for full usage.
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 coverage is 100%, so the baseline is 3. The description adds a practical tip about Korean keywords, but does not significantly elaborate on parameter formats or provide examples beyond what the schema already includes. It reinforces optionality of project and file_pattern but adds little new semantic meaning.
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 it searches code by keyword in registered projects, with specific capabilities like project restriction and file pattern filtering. This distinguishes it from sibling tools like read_file or list_projects, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for keyword-based code search in registered projects, but does not explicitly contrast with alternatives like get_file_tree or read_file. It provides context (search scope, file patterns) but lacks explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0add_projectget_file_treelist_projectsread_fileremove_projectsearch_codeEach tool has a clearly distinct purpose: project management (add/remove/list) vs. code exploration (search/tree/read). There is no overlap or ambiguity between them.
All tool names follow a consistent verb_noun snake_case pattern: add_project, remove_project, list_projects, search_code, get_file_tree, read_file. This makes the API predictable and easy to navigate.
With 6 tools, the server is well-scoped for its purpose of managing and searching local Git projects. Each tool earns its place without being excessive or too sparse.
The tool set covers the full lifecycle for the intended domain: registering/removing projects, listing them, searching code, and exploring file structures. No obvious dead ends or missing essential operations for a local code search server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dudckd6744/git-finder-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
