UpRock
Fetch pages, search the web and test site uptime from real devices in real locations.
作者による説明(英語の原文)
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
この3つを1つのスコアにまとめることはしません。意見、測定、人気はそれぞれ別のものだからです。
このサーバーのやさしい解説はまだ書いていません。以下はレジストリから読み取った事実です。
使っているAIアプリを選んで、設定をコピーしてください。
UMTRI_API_TOKEN, UMTRI_API_BASE「秘密」と表示された値は、あなたのアカウントの鍵です。絶対に人に教えたり、チャットに貼り付けたりしないでください。
必要なもの
どのアプリを使っていますか?
上でアプリを選んでください。選んだアプリを覚えておくので、次からはボタンに「…にインストール」と表示されます。
ウェブ、デスクトップ、モバイルのClaudeで使えます:
https://mcp.umtri.ioClaude Desktop → Settings → Developer → Edit Config を開き、claude_desktop_config.json にこれを貼り付けます
{
"mcpServers": {
"umtri": {
"command": "npx",
"args": [
"-y",
"umtri-mcp"
],
"env": {
"UMTRI_API_TOKEN": "your-value",
"UMTRI_API_BASE": "your-value"
}
}
}
}ターミナルでこれを実行します
claude mcp add --transport http umtri https://mcp.umtri.ioclaude mcp add umtri --env UMTRI_API_TOKEN=your-value --env UMTRI_API_BASE=your-value -- npx -y umtri-mcp動かす前に、空欄の値を入力してください。
プロジェクトの .cursor/mcp.json、または ~/.cursor/mcp.json に貼り付けます
{
"mcpServers": {
"umtri": {
"url": "https://mcp.umtri.io"
}
}
}プロジェクトの .cursor/mcp.json、または ~/.cursor/mcp.json に貼り付けます
{
"mcpServers": {
"umtri": {
"command": "npx",
"args": [
"-y",
"umtri-mcp"
],
"env": {
"UMTRI_API_TOKEN": "your-value",
"UMTRI_API_BASE": "your-value"
}
}
}
}ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。
プロジェクトの .vscode/mcp.json に貼り付けます
{
"servers": {
"umtri": {
"type": "http",
"url": "https://mcp.umtri.io"
}
}
}プロジェクトの .vscode/mcp.json に貼り付けます
{
"servers": {
"umtri": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"umtri-mcp"
],
"env": {
"UMTRI_API_TOKEN": "your-value",
"UMTRI_API_BASE": "your-value"
}
}
}
}ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。
ChatGPTがつなげるのは、インターネット上のサーバーだけです:
https://mcp.umtri.ioメニューの名前は、プランや時期によって少し違うことがあります。
選んだアプリは、この端末のCookieに保存されます。アカウントは不要です。
UMTRI_API_BASE envこの設定は、作者のレジストリ登録情報から作成しています。READMEと違う場合は、READMEに従ってください。
ツールの名前と説明は、サーバーが2026年11月7日に返したそのままの内容です。書いたのは作者で、私たちではありません。プレーンテキストとして表示しています。
list_projectsReturns all grounds the authenticated user can access, with latest activity timestamp. Use this first to discover slugs for other tools. By default returns a summary view — each ground carries slug, name, isActive, transplanting, nodeCount, openBugs, seasonCount, nowSeasonLabel,
get_graphReturns the tree(nodes), edges, apis, seasons, and bugs for one ground. The tree is the project's information-structure (IA) diagram — each node is a structural element (an object, or an action it performs), not a work-log entry. Node types follow the plant metaphor: trunk → limb
get_impactWalks the connection graph (edges + apis) from a start node — or a bug's target — to find which other nodes a problem would reach. This is the tool for "if this breaks / I change this, what else do I need to check?" and for QA scoping. Impact does NOT always flow with the arrow.
list_bugsScans the bugs (issues eroding the ground) of one ground. Looking at ONE bug you already know the number/id of? Call get_bug instead — no need to list. Bugs default to status="active" (wild + chasing): a healed bug is history, and history is not what a scan is for. Ask for "resol
get_bugReturns a single bug by reference — the cheap path when you already know which bug you mean. `ref` accepts either the human-facing number shown in the UI (seq — "14" or #14) or the internal id (bug- ), so a human saying "#8" needs no listing at all. Unlike list_bugs this ignores
list_seasonsReturns the seasons (time epochs) of a ground in chronological order. A season is the human's declaration that a chapter closed. You may create one with create_season, but only after the user confirms it — see umtri://rules/seasons. By default returns a summary view (id, label, s
export_groundReturns everything in a ground as one JSON document — project, seasons, nodes (removed ones included, with removedAt), edges, apis, bugs and wiki pages with full bodies. For backups, moving off Umtri, or answering "can I take my data out?" (yes — see umtri://about/data). The resu
list_eventsReturns the append-only change history (most recent first) of a ground: node/edge/api/bug create, update (with a field-level diff {from,to}), delete, and plan_commit. Each event carries the actor ("user: " for humans, "token: " for agents/automation), a summary label, and for upd
create_bugCreates a new bug (issue eroding the target). target.kind = "node" or "api" requires target.id of an existing node/api in the ground. target.kind = "ground" attaches the bug to the project itself (no id). score = change risk on a 0–8 scale (8 = riskiest). It blends functional imp
create_projectCreates a new ground. Slug must match /^[a-z0-9][a-z0-9-]{0,49}$/ and be unique. By default it goes into the authenticated user's personal space; pass org (a team slug, as list_projects shows it) to create it in a team — only the team's owner can. Requires a write-scope token.
create_seasonCreates a new season and makes it the "now" season. This is not an additive act: the ground's current now-season is sealed as past and every node in it is marked grown, which locks that node's parent/season/type/sproutedAt. CONFIRMATION GATE: call once WITHOUT confirm to get back
create_nodeCreates a node. Follows the plant vocabulary protocol — see umtri://rules/vocabulary. type ∈ trunk · limb · twig · leaf · vein. Role is derived (structure / object / action). Build leaf-first: when adding a leaf/vein, create only the missing trunk/limb/twig ancestors on its path,
update_nodePartial update of a node. Patchable fields: label, type, parent, season, description, tags, metadata, sproutedAt. metadata is merged key by key: only the keys you send change, keys you leave out (commits that record_commit accumulated, transplanted, and so on) are kept, and a key
delete_nodeSets removed_at on the node. By default this tool rejects deletion if the node has any active descendant, so a subtree is never lost silently. To soft-delete the node together with all its active descendants, pass cascade=true — only when the human asked to remove the whole branc
commit_planPromotes a plan node (metadata.plan=true) to the real tree by clearing the plan flag. VERIFICATION GATE: the node must already carry metadata.implements (the source path(s) you wrote) — without it the commit is rejected, because an uncommitted plan node with no implements is not
record_commitConfiguration record (CI/CD). Given a commit SHA and the files it changed, finds nodes whose metadata.implements include any of those files and appends the commit (sha + timestamp + optional message) to their metadata.commits (deduped by sha). Returns the matched node ids. When o
create_edgeCreates a directed edge (source → target) for a STRUCTURAL relation: type "dependency" (A is built on / needs B) or "data_flow" (data moves A → B outside a request). Use for module/library deps, a route depending on the data store, a job writing a table. For a runtime request/cal
delete_edgeRemoves an edge from the ground. Use to retire dependencies/flows that no longer reflect reality.
create_apiRecords an API flow (start → end) for a RUNTIME request / call / data flow: a screen calling an endpoint, an endpoint hitting a table, an external integration (payment, SMS, webhook). Direction is caller → callee. APIs are first-class (apis table), not generic edges — for a build
update_apiPartial update of an API. Patchable fields: label, description, metadata, start, end.
delete_apiSets removed_at on the API. History is preserved — the API can still be seen in past season views via the time slider.
update_bugPartial update of a bug. Most common use: status transition. Send only the fields that actually change. A status transition is patch:{status} alone — do not re-send an unchanged solution, description, or metadata. Those fields carry prose, and re-emitting them costs far more time
delete_bugPermanently removes a bug record. Bugs do not have history — once deleted, the record is gone. For "I resolved this", use update_bug with status="resolved" instead, so the tree remembers what was eroded.
send_feedbackFiles a suggestion or a defect report about **Umtri the product** — this MCP server, its tools, the app, the docs. This is NOT for issues in the user's own project: those are bugs on a ground (create_bug). Call this ONLY when the human explicitly asks to leave feedback ("건의해줘", "
list_feedbackLists feedback filed about **Umtri the product** (see send_feedback) — not the bugs of any ground. Umtri operators only: every other account gets 403, so do not call this to check on feedback you filed. Newest first. Status: open (untouched) → done (handled) / wontfix (declined,
update_feedbackUpdates one feedback record about **Umtri the product** — typically closing it: status="done" once it shipped, or "wontfix" when it was declined. Put what was actually done (or why not) in note; that is the part worth reading a year later. Umtri operators only: every other accoun
list_wikiLists the ground's wiki — the prose the tree cannot hold: conventions, decisions and why they were made, glossary, onboarding. Reference entries describing how things work, not a log of what happened: the change record is list_events, the page's own past is in its revisions. Not
get_wikiReturns one wiki page. `ref` takes either the page slug (what a human says) or the internal id (wiki- ) — renaming a page changes its slug but never its id, so ids stay safe to store. Every response carries rev (the current revision, what you pass as baseRev when you write) and b
list_wiki_revisionsReturns what this page said before, newest first — rev number, who wrote it, when, and the body length. Bodies are not included (a history of twenty full documents is expensive to skim); read one with get_wiki rev= . Use it to answer "what did this say last week", to see whether
write_wikiWrites one wiki page. Creates it if the page slug is new, updates it otherwise — you do not need to check first. **The wiki is the project's encyclopedia: one page is one entry, and its body is the current spec and rules of that thing.** It is a tree read front to back: an overvi
edit_wikiReplaces one passage of an existing wiki page without resending the body. Pass the exact text to replace (oldString) and what it becomes (newString) — the same contract as a code editor's Edit: oldString must occur **exactly once** on the page. If it is missing, or occurs more th
delete_wikiPermanently removes a wiki page **and its whole revision history** — unlike an overwrite, this cannot be undone, and only the history entry (list_events) remains to say it happened. Prefer rewriting a page that went stale over deleting it: a page that records a decision you have
誰でも見られる情報をチェックしており、コードは読んでいません。当てはまらない項目は数に入れていません。 · 2026年11月8日にチェック
レジストリ名はドメイン umtri.io で確認済みです(レジストリがドメインの所有を確認しています)
このリポジトリはまだGitHubから読み取っていません
このリポジトリはまだGitHubから読み取っていません
1323ミリ秒で応答(HTTP 200)
サインイン不要
32件のツールの説明を読み、AIへの隠れた指示は見つかりませんでした
レジストリでこのカテゴリにある有効なすべてのサーバーと比較しています。スターは、公開者がリポジトリの所有者である場合だけ数えます。
当てはまる基本チェック3項目のうち3項目に合格しました。コードは読んでいません。キーやトークンを追加する前に、サーバーがどんなアクセスを求めているかを確認し、必要な権限だけを持つキーを使ってください。
入力が必要なもの:UMTRI_API_TOKEN
どちらでも使えます。パソコンにインストールしても、クラウド版につないでもかまいません。
GitHubリポジトリの最終更新は–、最新バージョン(1.7.1)がレジストリに届いたのは一昨日です。
Claude Desktop、Claude Code、Cursor、VS CodeなどのMCP対応アプリで使えます。URLでつながるので、リモートMCPサーバーに対応したアプリ(開発者モードのChatGPTなど)でも使えます。
同じカテゴリには:UpRock, NAPSPAN, BusCalc Business Calculators
同じカテゴリで、ほかの作者が作ったサーバー。スターの多い順。
カードの見方:↓ 週あたりのダウンロードi★ GitHubスターi3つの柱:レビュー · チェック · 利用状況i更新=最新バージョンをレジストリに公開した日i
Fetch pages, search the web and test site uptime from real devices in real locations.
European NAP road data (DATEX II): incidents, roadworks, cameras, truck parking. Paid API key.
42 tools: business math, U.S. map lookups, truck trip screening and public data references.
作者のリポジトリから書かれたとおりにコピーしたものです。PopNx MCPは内容を確認・推奨していません。HTML、画像、スクリプトは取り除いています。リンクはこのサイトの外へ移動します。
MCP server for Umtri — give your AI coding agent a persistent map of your project's structure, dependencies, and bugs.
Your agent re-derives your codebase from scratch every session. Umtri stores the structure once and hands it back through MCP: a tree of what the system is made of, the calls and dependencies between its parts, and the bugs eroding it. Ask "what breaks if I change this?" and get an answer traced through recorded connections rather than guessed from a grep.
The fastest path is the hosted endpoint at https://mcp.umtri.io — nothing to install. Generate a token at app.umtri.io → Settings → API Tokens, then:
claude mcp add --transport http umtri https://mcp.umtri.io \
--header "Authorization: Bearer umtri_pat_xxxxxxxxxxxxxxxx"
Any MCP client that takes a config object uses the same shape:
{
"mcpServers": { "umtri": { "type": "http", "url": "https://mcp.umtri.io", "headers": { "Authorization": "Bearer umtri_pat_xxxxxxxxxxxxxxxx" } } } }
Use this package when you want to pin a version or point at a self-hosted API:
claude mcp add umtri \
-e UMTRI_API_TOKEN=umtri_pat_xxxxxxxxxxxxxxxx \ --transport stdio \ -- npx -y umtri-mcp
| Variable | Required | Default |
|---|---|---|
UMTRI_API_TOKEN | yes | — |
UMTRI_API_BASE | no | https://api.umtri.io |
The token is not validated at setup time, so a bad token connects but every call fails. If tools appear and then error, re-check the token and its scope — read tokens cannot call any write tool.
Read — get_graph, get_bug, get_impact, list_projects, list_bugs, list_seasons, list_events, export_ground
Write — create_project, create_node, update_node, delete_node (a subtree only with cascade: true), create_edge, delete_edge, create_api, update_api, delete_api, create_bug, update_bug, delete_bug, create_season (acts only after the user confirms)
Plan loop — commit_plan, record_commit
Wiki — list_wiki, get_wiki, list_wiki_revisions, write_wiki, edit_wiki, delete_wiki. The ground's encyclopedia: pages form a table of contents (parent, position) read from an overview down, each has a kind, and every write comes back with warnings when a page strays from the skeleton.
Feedback — send_feedback files a suggestion or defect about Umtri itself.
get_graph returns a slice, not a dump: scope by subtree (rootId), by layer (maxType), by role, or by season, and control description weight separately. A large tree stays cheap to read.
Ten read-only documents the agent can pull for domain rules — the plant vocabulary (trunk/limb/twig/leaf/vein), what counts as a node and what does not, how seasons work, how plan nodes are meant to be realized, how a ground behaves while transplanting, keeping the tree in step with commits, and how to write and organize the wiki.
umtri://rules/vocabulary umtri://rules/plan
umtri://rules/vocabulary-detailed umtri://rules/commit-sync umtri://rules/system-structure umtri://rules/wiki umtri://rules/seasons umtri://templates/wiki umtri://rules/transplant umtri://about/vision
Apache-2.0. See LICENSE.