プロトタイプ · プレビュー版:公式レジストリのすべてのサーバーを掲載し、30分ごとに同期しています。レビューとアカウント機能は今後のステップで始まります。
PopNx MCPAIを使う人のためのMCPサーバー · やさしい言葉で解説

Itamos MCP Tools

作者:Itamos-technologiaバージョン 1.1.0i★ –iクラウドで動く
レジストリ名io.github.itamos-technologia/itamos-mcp-tools

インストール

概要

作者による説明(英語の原文)

Code-map tools for AI agents: see a repo's structure first, then edit only what matters.

PopNx MCPの3つの柱

この3つを1つのスコアにまとめることはしません。意見、測定、人気はそれぞれ別のものだからです。

できること

このサーバーのやさしい解説はまだ書いていません。以下はレジストリから読み取った事実です。

  • 接続方法: クラウドで動く
  • トランスポート: Streamable HTTP
  • カテゴリ: 旅行・地図・天気

インストール

使っているAIアプリを選んで、設定をコピーしてください。

インストールの前に

  • 基本チェック:3項目中3項目に合格
  • 作者のサーバーで動きます。あなたが頼んだ内容は、作者のサーバーを通ります。
  • レジストリには、入力が必要なキーは載っていません。

必要なもの

どのアプリを使っていますか?

上でアプリを選んでください。選んだアプリを覚えておくので、次からはボタンに「…にインストール」と表示されます。

ウェブ、デスクトップ、モバイルのClaudeで使えます:

  1. Settings → Connectors を開く
  2. Add custom connector を押す
  3. 下のアドレスを貼り付けて Add を押す
  4. サインインを求められたら、作者のサービスにサインインする
SettingsConnectors1+ Add2https://…3
https://mcp.itamos-technologia.com/mcp

ターミナルでこれを実行します

claude mcp add --transport http itamos-tools https://mcp.itamos-technologia.com/mcp

Cursorで開く

または、設定を自分でコピーする

プロジェクトの .cursor/mcp.json、または ~/.cursor/mcp.json に貼り付けます

{
  "mcpServers": {
    "itamos-tools": {
      "url": "https://mcp.itamos-technologia.com/mcp"
    }
  }
}

ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。

VS Codeで開く

または、設定を自分でコピーする

プロジェクトの .vscode/mcp.json に貼り付けます

{
  "servers": {
    "itamos-tools": {
      "type": "http",
      "url": "https://mcp.itamos-technologia.com/mcp"
    }
  }
}

ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。

ChatGPTがつなげるのは、インターネット上のサーバーだけです:

  1. ウェブ版のChatGPTを開き → Settings → Connectors (Apps)
  2. Create または Add を押す(プランによっては、先に Advanced で Developer mode をオンにする必要があります)
  3. 下のアドレスを貼り付け、名前を付けて保存する
  4. サインインを求められたら、作者のサービスにサインインする
SettingsConnectors1+ Create2https://…3
https://mcp.itamos-technologia.com/mcp

メニューの名前は、プランや時期によって少し違うことがあります。

選んだアプリは、この端末のCookieに保存されます。アカウントは不要です。

この設定は、作者のレジストリ登録情報から作成しています。READMEと違う場合は、READMEに従ってください。

できること

このサーバーは、ツール一覧を表示する前にサインインを求めます。

基本チェックi

誰でも見られる情報をチェックしており、コードは読んでいません。当てはまらない項目は数に入れていません。 · 2026年11月9日にチェック

  • ✓ 合格

    作者とリポジトリが一致

    レジストリ名は、リポジトリを所有するGitHubアカウント Itamos-technologia で確認済みです

  • … 未チェック

    今もメンテナンスされている

    このリポジトリはまだGitHubから読み取っていません

  • … 未チェック

    ライセンスがある

    このリポジトリはまだGitHubから読み取っていません

  • ✓ 合格

    エンドポイントが応答する

    311ミリ秒で応答(HTTP 401)

  • ✓ 合格

    OAuthでサインイン

    OAuthでのサインインに対応しているため、AIアプリがログイン画面へ案内してくれます

  • … 未チェック

    ツールの説明に隠れた指示がない

    まだチェックしていません。エンドポイントをチェックするときにツール一覧を読み取ります

旅行・地図・天気のほかのサーバーとの比較i

  • このカテゴリのほかの1740件のうち0%よりスターが多い
  • このカテゴリのほかの1740件のうち50%より最近レジストリに公開
  • 基本チェックの結果が、このカテゴリのほかの1740件のうち100%と同じかそれ以上

レジストリでこのカテゴリにある有効なすべてのサーバーと比較しています。スターは、公開者がリポジトリの所有者である場合だけ数えます。

よくある質問

Itamos MCP Toolsは安全ですか?

当てはまる基本チェック3項目のうち3項目に合格しました。コードは読んでいません。キーやトークンを追加する前に、サーバーがどんなアクセスを求めているかを確認し、必要な権限だけを持つキーを使ってください。

どんなキーやコードが必要ですか?

レジストリには必須のキーは載っていません。ただし、最初に使うときにサインインを求めるサーバーもあります。

パソコンで動きますか、それともクラウドですか?

作者のクラウドで動きます。インストール不要でインターネット経由でつながりますが、送った内容は作者のサーバーを通ります。

今もメンテナンスされていますか?

GitHubリポジトリの最終更新は–、最新バージョン(1.1.0)がレジストリに届いたのは31 日前です。

どのアプリで使えますか?

Claude Desktop、Claude Code、Cursor、VS CodeなどのMCP対応アプリで使えます。URLでつながるので、リモートMCPサーバーに対応したアプリ(開発者モードのChatGPTなど)でも使えます。

代わりに使えるものは?

同じカテゴリには:Facade UI, InsightBaZi, Japan Places — Japan Data Foundry

代わりの候補

同じカテゴリで、ほかの作者が作ったサーバー。スターの多い順。

カードの見方:↓ 週あたりのダウンロードi★ GitHubスターi3つの柱:レビュー · チェック · 利用状況i更新=最新バージョンをレジストリに公開した日i

Facade UI

Interactive floor plans and shadcn blocks for real estate and local business websites.

作者:marcoschulz7初期今日更新

クラウドで動く

InsightBaZi

BaZi (Four Pillars) calculation from birth date, time, and location via public remote MCP.

作者:insightbazi.com初期今日更新

クラウドで動く✓ insightbazi.com

作者のREADME

READMEを開く

作者のリポジトリから書かれたとおりにコピーしたものです。PopNx MCPは内容を確認・推奨していません。HTML、画像、スクリプトは取り除いています。リンクはこのサイトの外へ移動します。

Itamos MCP Tools

Built in Greece, for the world.

Free and open source under AGPL-3.0. Commercial licences for closed-source use.


The problem

Every LLM coding assistant faces the same wall: codebases are too large to fit in context. The standard response is to dump files — grep for something promising, cat it, hope for the best. At 50k files this breaks. At 240k files it never worked.

We built four tools that give an LLM structured perception of a codebase instead of raw file access, plus a sandboxed git to bring code in. The result is a model that navigates code the way a senior engineer does — starting from the architecture, narrowing to the module, reading only the segment it needs. One call takes it from the project straight to the lines it needs, and every save is checked before it lands.

Read the full paper: docs/PAPER.md: how each tool works, why it was designed that way, and how the hosted sandbox runs, with diagrams.


Tools

ToolWhat it does
read_fileThe single entry point. With no path it lists your projects; a project name shows its structure with coordinates (no code); a coordinate opens a file map or one segment in a single call. Edits one segment at a time, and every save is verified automatically.
master_architectThe engine behind read_file. Indexes the codebase into a graph (files, imports, databases, servers) and keeps it in step with every save. In the sandbox it is not called directly: read_file does it.
write_fileCreates new files only and never overwrites; edits go through read_file. Every new file belongs to a project the agent names: an existing one, or a new name to start one. Nothing is placed automatically.
gitThe original Itamos git tool, sandboxed for security: clone (remote URLs only, depth=1), status, commit. A clone is scanned into a project as soon as it finishes. Everything stays inside the session workspace; push is not available.
web_skeletonLLM-first web perception. 97% token reduction vs raw HTML. Actions: search, skeleton, read, click.

At least 97% fewer tokens than the usual shell workflow (grep, cat, run_cmd), measured against the best case where the model fixes the bug in one attempt. Real sessions save more, because the failed attempts common with raw shell access aren't counted.


How it works

Session model

Every client gets an isolated workspace. No shared state, no cross-session leakage. Workspaces are wiped after 10 minutes of inactivity.

Navigation: project → file → segment
read_file()                                            → your projects

read_file(path="itsdangerous") → the structure: folders and files with coordinates, no code read_file(path="itsdangerous", segment="d.a.f") → the map of signer.py, one line per segment read_file(path="itsdangerous", segment="d.a.f.31.17") → the code of verify_signature, nothing else

Coordinates: letters are location (folders and files share one sequence per folder), numbers are what is inside a file. d.a.f.31.17 reads as src → itsdangerous → signer.py → segment 31.17. A folder that has never been scanned is scanned on first read; a cloned repository is scanned as soon as the clone finishes.

Nothing is dumped: a structure or file map over ~3,000 tokens returns an overview and asks for a search term instead. search works on both: file and folder names in a project, segment names in a file. trace=true shows what a file connects to, or a project's data flow.

Segments

Files are parsed into named segments. A 5000-line file might have 40 segments; its map is one line per segment, with classes listing their methods. The model reads the map, picks the segment it needs, reads that segment. Total context used is roughly 120 lines instead of 5000.

Editing and verification

One edit at a time, and only on segments the model has read since the last change, so it can never change code it has not looked at. Saving verifies the file first:

LevelChecksOn failure
L1Syntax: tree-sitter plus the language's own checker (py_compile, node --check, php -l, bash -n, gofmt, C/C++ in project context, config parsers)Not saved; the error names the line
L2Config files through their service's checker (nginx -t, sshd -t, visudo, systemd-analyze). Linters run tooConfig failure: not saved. Linter findings are only reported
L3Connections: every local import resolves to a project file (Python and JavaScript/TypeScript: any other import must be an installed package, for Python in the project's venv when it has one); SQL is checked against the live database schemaSaved, with what is incomplete and how to see it, so a project's first files can import files that don't exist yet

L3 checks the content being saved, not an older index, and every save re-indexes the file in every supported language, so the map never lags behind the disk.

web_skeleton token reduction

Raw HTML of a modern web page runs 50,000 to 200,000 tokens. web_skeleton output is 500 to 3,000 tokens. The model reads the skeleton, picks the section id it needs, reads that section only.


Benchmarks

Verified in live use with Claude Opus 5.5 and Claude Sonnet. Any MCP-capable model can use the tools.

Don't take our word for it. Test the tools free in the hosted sandbox with your own model and your own repository, then post your results in Discussions → Benchmarks: model, task, tokens, time.

Found a bug? Open an issue with the steps to reproduce it. Every report makes the tools better.


Connecting

The sandbox server speaks standard MCP over HTTP POST with SSE support.

Compatible with any MCP client. Used in practice through Claude.ai and through direct API integration (our benchmark harness).

Try it in Claude (free live alpha): copy https://mcp.itamos-technologia.com/mcp, open Claude's connector settings, click Add custom connector, paste the address and click Add. A page opens with one button, Create my sandbox: no account, no email. Switch it on in a chat (+ → Connectors) and ask, for example, *"Go to bbc.com/news and tell me the top stories."* In other MCP clients, add the same address as a remote MCP server. Sandboxes are deleted after 10 minutes of inactivity, so don't use them for sensitive data.


Self-hosting

Requirements
  • Linux with ZFS (required). Every sandbox is its own ZFS dataset with a hard size limit (quota) and compression, so no user can fill the disk for everyone else. The server checks this at startup and refuses to start without it.
  • Node.js 20 or newer, plus build tools for the native modules (Debian/Ubuntu: apt install build-essential python3).
  • git for the git tool, and Chrome or Chromium for web_skeleton.
Install
git clone https://github.com/itamos-technologia/itamos-mcp-tools.git

cd itamos-mcp-tools npm install

One npm install sets up everything, including the tools folder.

On Ubuntu 26.04 you can install the package from Releases instead: sudo apt install ./itamos-mcp-tools_1.1.0_all.deb. It sets up a service user, a systemd service, settings in /etc/itamos-mcp-tools/env and the command itamos-mcp-create-slots, then tells you the next two steps.

Extra language parsers

Besides the standard tree-sitter grammars (installed by npm install), read_file and the segmenter use extra parsers from the grammars/ folder:

FilesParserFalls back to
.cu .cuh .hiptree-sitter-cuda-plusstock tree-sitter-cuda, then C++
.metaltree-sitter-metal-plustree-sitter-metal, then C++
.cpp .cc .hpp, C++ .htree-sitter-cpp-plusstock tree-sitter-cpp
.m .mm, .h with @interfacetree-sitter-objcC / C++

The "plus" parsers are the stock grammar plus extra C++ rules, checked to give the identical tree wherever the stock grammar already parses. A parser that is missing or fails to load is skipped, never fatal.

  • Linux x64: nothing to do. The parsers ship prebuilt in grammars/tree-sitter-*/prebuilds/linux-x64/ (Node-API, any Node 18+, glibc 2.14+), and npm install sets up the rest.
  • Other platforms (macOS, Windows, ARM): compile each parser once. This needs Python and a C/C++ compiler:
  cd grammars/tree-sitter-cuda-plus && npx node-gyp rebuild   # same for tree-sitter-cpp-plus, -metal-plus, -metal
  • Drop-in: every grammars/tree-sitter-* folder is a self-contained package. Copy one in and the sandbox finds it by name, with no install or symlink. To keep the grammars somewhere else, set SANDBOX_GRAMMARS_DIR.
  • Regenerating (only after changing the rules in grammars/plus/): grammars/plus/build_plus.sh generates with tree-sitter-cli 0.25.10 (ABI 15), compiles, and publishes into the matching tree-sitter-* folder. Its header shows the arguments.
Create the sandbox slots
sudo scripts/create-slots.sh tank/sandboxes 500 2G $USER

This creates slot_001 to slot_500 under the ZFS dataset tank/sandboxes (use your own pool name), each with a 2 GB quota and lz4 compression, owned by the user the server runs as. It is safe to run again.

Start
SANDBOX_ROOT=/tank/sandboxes SANDBOX_TOTAL_SLOTS=500 npm start

From the same machine, add http://localhost:4200/mcp as a connector in your MCP client. Local connections are identified by IP address and need no sign-in.

Going public

Firewall port 4200 and put an HTTPS reverse proxy (for example nginx) in front of it that sets X-Forwarded-For and X-Forwarded-Proto. Requests that arrive through the proxy use the anonymous one-click sign-in, so users on shared addresses (such as claude.ai) each get their own sandbox. Direct connections to port 4200 skip the sign-in, which is why the port must not be reachable from outside.

Text models (optional)

read_file and web_skeleton give untitled paragraphs and page sections a short title (5 to 10 words) from a small summarizer model, so the agent can tell parts apart without reading them. Without a summarizer everything still works; those parts are then named by their first line.

Any OpenAI-compatible chat endpoint works, set with ITAMOS_SUMMARIZER_URL (default http://127.0.0.1:8090): a single llama-server, Ollama, or the included router in front of several GPUs. The whole paragraph is always sent, never cut.

The hosted sandbox runs Gemma 4 E4B (Q4_0) as summarizer and EmbeddingGemma 300M as embedder on three GPUs (one 16 GB MI50 and two 8 GB V340 dies), each summarizer started like this:

llama-server -m gemma-4-E4B-it-Q4_0.gguf -ngl 99 --port 8190 \

-np 64 -c 524288 --kv-unified -fa on --cache-type-k q4_0 --cache-type-v q4_0 -rea off

  • --kv-unified: one shared KV pool, so each request uses only the tokens it needs.
  • --cache-type-k q4_0 --cache-type-v q4_0 (needs -fa on): a 4-bit KV cache, about 4.5 KB per token for this model.
  • -c is the pool in tokens: 524,288 on the MI50, 262,144 on each V340 die (with 32 slots).

The router (router/llm-router.js, service itamos-llm-router) listens on 8090 (summarizer) and 8091 (embedder). Before sending a request it counts its tokens with the backend's own tokenizer, sends it to a GPU whose pool has room (preferring faster GPUs by weight), and makes it wait in line when none has. A GPU that fails is skipped for 15 seconds and the request is retried on another. Configure it with ROUTES (in the package: /etc/itamos-mcp-tools/router.env); GET /router/status shows each GPU's pool, reserved

冒頭だけを表示しています。続きはリポジトリで読めます

PopNxに聞く