GitHub
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
제작자가 쓴 설명(영어 원문)
A local map of your codebase over time: symbols, callers, subgraphs and structural change.
이 세 가지는 절대 하나의 점수로 합치지 않아요. 의견, 측정, 인기는 서로 다른 것이니까요.
이 서버는 아직 쉬운 말로 된 요약을 쓰지 못했어요. 아래는 레지스트리에서 읽어 온 사실이에요.
쓰고 있는 AI 앱을 고른 다음 설정을 복사하세요.
어떤 앱을 쓰세요?
위에서 앱을 고르세요. 기억해 두었다가 다음부터는 버튼에 “…에 설치”라고 표시해요.
링크는 제작자의 파일로 바로 연결돼요. 우리가 보관하거나 다시 패키징하지 않아요. 파일을 열면 Claude Desktop이 설치해요.
터미널에서 이 명령어를 실행하세요
브라우저가 앱을 열지 물어본 다음, 앱이 설정을 보여 주고 확인을 요청해요. 키 값은 비워 두니 직접 입력하세요.
브라우저가 앱을 열지 물어본 다음, 앱이 설정을 보여 주고 확인을 요청해요. 키 값은 비워 두니 직접 입력하세요.
이 서버는 내 컴퓨터에서 실행되는데, ChatGPT는 인터넷에 있는 서버에만 연결할 수 있어요. 다른 앱을 고르세요.
선택한 앱은 이 기기의 쿠키에만 저장돼요. 계정은 필요 없어요.
이 설정은 제작자의 레지스트리 정보로 만들었어요. README와 다르면 README를 따르세요.
내 컴퓨터에서 실행돼요. 설치하면 AI 앱에 도구 목록이 나타나요.
누구나 볼 수 있는 정보를 점검했고, 코드는 읽지 않았어요. 해당하지 않는 항목은 개수에서 뺐어요. · 2026년 11월 6일 점검
레지스트리 이름이 GitHub 계정 RedholeTechnologies 기준으로 확인되었고, 이 계정이 저장소를 소유하고 있어요
아직 GitHub에서 이 저장소를 읽어 오지 않았어요
아직 GitHub에서 이 저장소를 읽어 오지 않았어요
내 컴퓨터에서 실행되는 서버라 인터넷 엔드포인트가 없어요
내 컴퓨터에서 실행되며, 대신 로컬 설정을 사용해요
내 컴퓨터에서 실행돼요. 도구 목록은 인터넷 엔드포인트가 있는 서버에서만 읽을 수 있어요
레지스트리에서 이 카테고리의 활성 서버 전체와 비교했어요. 스타는 게시자가 저장소를 소유한 경우에만 세요.
해당하는 기본 점검 1개 중 1개를 통과했어요. 코드는 읽지 않았어요. 키나 토큰을 넣기 전에 서버가 어떤 권한을 요구하는지 확인하고, 꼭 필요한 권한만 있는 키를 쓰세요.
레지스트리에 필수 키가 나와 있지 않아요. 다만 처음 쓸 때 로그인을 요구하는 서버도 있어요.
내 컴퓨터에서 실행돼요. AI 앱이 필요할 때 실행하고, 데이터는 제작자의 서버를 거치지 않아요(서버 자체가 온라인 서비스를 호출하는 경우는 제외).
GitHub 저장소는 마지막으로 – 변경됐고, 최신 버전(0.7.1)은 39일 전 레지스트리에 올라왔어요.
Claude Desktop, Claude Code, Cursor, VS Code처럼 MCP를 지원하는 앱에서 쓸 수 있어요. 내 컴퓨터에 MCPB도 있어야 해요.
같은 카테고리에는: GitHub, Desktop Commander, Cloudflare MCP
같은 카테고리에서 다른 제작자가 만든 서버예요. 스타 순으로 정렬했어요.
카드 보는 법:★ GitHub 스타i세 기둥: 리뷰 · 점검 · 사용 정도i업데이트 = 최신 버전을 레지스트리에 공개한 날i
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
MCP server for terminal commands, file operations, and process management
Cloudflare MCP servers
제작자의 저장소에서 쓰인 그대로 가져왔어요. PopNx MCP가 검토하거나 보증한 내용이 아니에요. HTML, 이미지, 스크립트는 제거했어요. 링크를 누르면 이 사이트를 벗어나요.
English | 한국어
Treering draws a map of your codebase and keeps a copy of it for every commit, so you can see how the structure changed: which types started depending on each other last week, or when a class began to collect callers. It runs entirely on your machine and sends nothing over the network. It doesn't use an LLM, so the same code always produces the same graph.
*Click a box to go inside it; the part you opened frames what it holds. Then back out, and the same sheet as a chip.*
*The sample project's modules as a schematic, compared with a month earlier. Green is new: a Billing module now implements the payment interface. Red dashed is gone: the web pages used to call the database directly.*
| Map. Modules as bubbles and the calls between them. New lines are green, broken ones red. | Blueprint. One level as boxes in tiers, each with its role and what the others use it for. |
| Inside a module. The module you opened frames what it holds; wires cross its edge at sheet ports. | One class. Its fields and methods, the types it works with, and which member ties them. |
| Chip. Where the weight is: each region as big as its code, libraries as pads on the edge. |
All of these are the sample project that comes with Treering (treering sample), a small made-up shop.
Treering is still in development, and the database format may change between releases. The design notes are in treering-plan.md (in Korean).
Windows (PowerShell):
irm https://raw.githubusercontent.com/RedholeTechnologies/Treering/main/install.ps1 | iex
Linux (x86-64):
curl -fsSL https://raw.githubusercontent.com/RedholeTechnologies/Treering/main/install.sh | sh
Each script downloads the latest build from Releases, checks it against the published checksum, and puts treering on your PATH. On Windows it also adds Treering to the Start menu. Neither needs administrator rights, and running a script again updates Treering. If you'd rather not run a script, download the zip or tarball from Releases and unpack it anywhere.
Then run treering, or open it from the Start menu. It starts the server and opens http://127.0.0.1:7377 in your browser. If Treering is already running, it only opens the browser.
To look around before importing anything, choose Or look around a sample project first on the first screen. It adds acme-shop, a small made-up online shop with a month of history. treering sample adds it from the command line.
Treering doesn't parse source code itself. It reads SCIP indexes, which each language's indexer produces. Install the indexers for the languages you use:
dotnet tool install --global scip-dotnet # C#
npm install -g @sourcegraph/scip-typescript # TypeScript and JavaScript npm install -g @sourcegraph/scip-python # Python
treering import /path/to/repo
treering serve
import looks at which languages the repository contains and runs each indexer with the flags it needs. For C# it indexes the solution at the root, or each project if there's no solution. For TypeScript it indexes each topmost package.json, and for Python each pyproject.toml. The graph is stored in your user folder, never inside the repository, and treering projects lists what you've imported.
treering serve opens the map at http://127.0.0.1:7377. Without a database argument it serves every imported project, and you can switch between them in the menu at the top of the page.
You can also import from the page. Open the project menu, choose Import…, then Choose a folder…. The server opens your system's folder picker (Explorer on Windows, the standard dialog on macOS, zenity or kdialog on Linux), because a browser won't give a page the full path of a folder. You can type the path instead. The import starts when you pick a folder, and the dialog shows each indexer as it runs. If one fails, it tells you why and what to try.
The import and folder endpoints only accept JSON requests sent by the page itself, so another site open in your browser can't start an import or open a window.
The map shows modules, namespaces and types as nodes, and the references between them as edges.
/ or Ctrl+K to search. Picking a result takes you to where it lives.treering update /path/to/repo
treering watch /path/to/repo # every 10 minutes treering watch /path/to/repo 30 # every 30 minutes
update re-indexes only the projects whose files changed. Each changed file goes to its nearest project (.csproj, package.json, or pyproject.toml and setup.py) and that language's indexer, so a repository with several languages updates each part with its own tool. If an indexer is missing, Treering prints the command that installs it.
watch runs update on a timer and adds a snapshot only when something changed, so the history fills in while you work. It starts from the commit recorded in the last snapshot, so you can stop and restart it without losing anything, and it counts uncommitted changes as well as commits.
You usually don't need to run watch yourself: treering serve does the same for every imported project while it runs. Every 10 minutes it re-indexes what changed and adds a snapshot, and if you're looking at the latest snapshot the page moves to the new one by itself. A re-index that leaves the graph as it was adds no snapshot. Turn it off with --no-watch or under Settings on the page, change the period with --watch-minutes N, and pick another port with --port N.
You can run an indexer yourself and load its output. For C#:
scip-dotnet index YourSolution.slnx --allow-global-symbol-definitions --output index.scip
treering load index.scip graph.db treering serve graph.db treering callers graph.db OrderRepository treering map graph.db type --own
Always pass --allow-global-symbol-definitions to scip-dotnet. Without it, symbols don't carry their package name, and once you index projects separately or add snapshots, one symbol turns into several. In one test that recorded 6,784 symbols as added and 6,790 as removed.
To compare over time, load more snapshots:
treering snap index-new.scip graph.db 1
treering diff graph.db 0 1 treering growth graph.db InvoiceModel
diff lists the dependencies added and removed between two snapshots, and growth shows when a type's callers increased.
treering mcp
This runs a Model Context Protocol (MCP) server over stdio for the projects you've imported. It has six tools: list_projects, find_symbol, callers_of, subgraph, changed_since and snapshots. Each tool takes a project (a name or id from list_projects); left empty, it asks the most recently imported one. They run the same queries as the page, with the same size limits. When a result would be too large, the response says what was left out so the agent can narrow the question and ask again. treering mcp graph.db answers about that one database only.
To add it to Claude Code:
claude mcp add treering -- treering mcp
In other hosts, the command is treering with the argument mcp. Each release also carries MCP bundles (treering-win-x64.mcpb, treering-linux-x64.mcpb) for hosts that install MCPB in one step, and is published to the MCP Registry as io.github.RedholeTechnologies/treering.
On Acme.Shop (4 projects, 632 .cs files):
| Step | Result |
|---|---|
| Indexing (scip-dotnet) | 89s |
| Loading into the graph | 2.6s, 53 MB peak memory |
| Database size | 5.9 MB, from an 8.2 MB index.scip |
| Cost of a second snapshot | 27% more (5.9 MB to 7.5 MB) |
| Whole-map query | 29 ms by module, 30 ms by namespace, 48 ms for every type |
| Drill-down query | 182 ms (384 types, 2,933 edges) |
| Incremental update | 17s, of which 16.6s is indexing |
On a large C# repository (11,385 .cs files):
| Step | Result |
|---|---|
| Indexing | 3 min 28s, 34.5 MB index |
| Symbols and edges | 43,932 and 185,266 |
| Memory while scanning | 41.6 MB, the same as for the 8.2 MB index |
| Loading | 11 to 15s, 103 MB, 40.3 MB database |
| Whole-map query | 26 ms for 115 modules, 48 ms for 406 namespaces, 210 ms for every type (capped at 2,000) |
Scanning memory doesn't grow with the size of the index, and every whole-map view stays under 300 ms at this size. That's because edges are summarised per module, namespace and type once, when the index is loaded, instead of on every query. The module map went from 327 ms to 26 ms with that change.
C#, TypeScript and Python work end to end. Because the input is SCIP, adding a language mostly means adding its indexer: TypeScript needed no changes to Treering, and the module level became npm packages and namespaces became folders on their own. Constructor injection is recognised from .ctor, , __init__ and . update and watch handle TypeScript too; on ShopWeb, 19 changed files in one package took 52s.
scip-python 0.6.6 doesn't start on Windows: it builds a regular expression from the path separator, and \ isn't a valid pattern on its own. Treering loads a small script ahead of scip-python that escapes that one pattern. It also finds pip for scip-python, looking in the repository's .venv first and then at any Python the py launcher knows. If there's no pip, it indexes with an empty package list, which only loses the names of third-party packages. On python-sample this produced 1,800 symbols and 6,564
앞부분만 보여 드려요. 나머지는 저장소에서 읽어 보세요