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.
この3つを1つのスコアにまとめることはしません。意見、測定、人気はそれぞれ別のものだからです。
このサーバーのやさしい解説はまだ書いていません。以下はレジストリから読み取った事実です。
使っているAIアプリを選んで、設定をコピーしてください。
どのアプリを使っていますか?
上でアプリを選んでください。選んだアプリを覚えておくので、次からはボタンに「…にインストール」と表示されます。
リンク先は作者自身のファイルです。私たちが置いたり再パッケージしたりしたものではありません。ファイルを開くと、Claude Desktopがインストールします。
ターミナルでこれを実行します
ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。
ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。
これはパソコンで動くサーバーですが、ChatGPTがつなげるのはインターネット上のサーバーだけです。ほかのアプリを選んでください。
選んだアプリは、この端末のCookieに保存されます。アカウントは不要です。
この設定は、作者のレジストリ登録情報から作成しています。READMEと違う場合は、READMEに従ってください。
パソコンで動くサーバーです。インストールすると、ツール一覧がAIアプリに表示されます。
誰でも見られる情報をチェックしており、コードは読んでいません。当てはまらない項目は数に入れていません。 · 2026年11月7日にチェック
レジストリ名は、リポジトリを所有するGitHubアカウント RedholeTechnologies で確認済みです
このリポジトリはまだGitHubから読み取っていません
このリポジトリはまだGitHubから読み取っていません
これはパソコンで動くため、インターネット上のエンドポイントはありません
パソコンで動き、代わりにローカルの設定を使います
パソコンで動くサーバーです。ツール一覧を読み取れるのは、インターネット上のエンドポイントがある場合だけです
レジストリでこのカテゴリにある有効なすべてのサーバーと比較しています。スターは、公開者がリポジトリの所有者である場合だけ数えます。
当てはまる基本チェック1項目のうち1項目に合格しました。コードは読んでいません。キーやトークンを追加する前に、サーバーがどんなアクセスを求めているかを確認し、必要な権限だけを持つキーを使ってください。
レジストリには必須のキーは載っていません。ただし、最初に使うときにサインインを求めるサーバーもあります。
あなたのパソコンで動きます。必要なときにAIアプリが起動し、データは作者のサーバーを通りません(サーバー自体がオンラインサービスを呼び出す場合を除きます)。
GitHubリポジトリの最終更新は–、最新バージョン(0.7.1)がレジストリに届いたのは40 日前です。
Claude Desktop、Claude Code、Cursor、VS CodeなどのMCP対応アプリで使えます。パソコンにMCPBも必要です。
同じカテゴリには:GitHub, Desktop Commander, Cloudflare MCP
同じカテゴリで、ほかの作者が作ったサーバー。スターの多い順。
カードの見方:★ GitHubスターi3つの柱:レビュー · チェック · 利用状況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
冒頭だけを表示しています。続きはリポジトリで読めます