Umtri

Was du damit machen kannst

Für diesen Server haben wir noch keine Zusammenfassung in einfacher Sprache geschrieben. Unten stehen die Fakten, die wir aus der Registry gelesen haben.

• Verbindung: Computer oder Cloud
• Transport: stdio, Streamable HTTP
• Kategorie: Reisen, Karten & Wetter
• Das musst du eintragen: UMTRI_API_TOKEN

Installation

Wähle die KI-App, die du nutzt, und kopiere die Einstellungen.

Du brauchst

• Läuft in der CloudNichts zu installieren; die Verbindung läuft übers Internet
• npmNode.js installiert (für den Befehl npx)

Welche App nutzt du?

https://mcp.umtri.io

{
  "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.io

claude mcp add umtri --env UMTRI_API_TOKEN=your-value --env UMTRI_API_BASE=your-value -- npx -y umtri-mcp

{
  "mcpServers": {
    "umtri": {
      "url": "https://mcp.umtri.io"
    }
  }
}

{
  "mcpServers": {
    "umtri": {
      "command": "npx",
      "args": [
        "-y",
        "umtri-mcp"
      ],
      "env": {
        "UMTRI_API_TOKEN": "your-value",
        "UMTRI_API_BASE": "your-value"
      }
    }
  }
}

{
  "servers": {
    "umtri": {
      "type": "http",
      "url": "https://mcp.umtri.io"
    }
  }
}

{
  "servers": {
    "umtri": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "umtri-mcp"
      ],
      "env": {
        "UMTRI_API_TOKEN": "your-value",
        "UMTRI_API_BASE": "your-value"
      }
    }
  }
}

https://mcp.umtri.io

Deine Auswahl bleibt in einem Cookie auf diesem Gerät; kein Konto nötig.

Werte, die du selbst einträgst

• UMTRI_API_TOKEN geheim erforderlich env
  Personal access token from app.umtri.io → Settings → API Tokens. Read tokens cannot call write tools.
• UMTRI_API_BASE env
  Override the API base URL. Defaults to https://api.umtri.io — set only when self-hosting.

Diese Einstellungen werden aus dem Registry-Eintrag des Entwicklers erzeugt. Wenn in der README etwas anderes steht, folge der README.

Was er kann

Tool-Namen und -Beschreibungen genau so, wie der Server sie am 7. Nov. 2026 gemeldet hat. Geschrieben hat sie der Entwickler, nicht wir; wir zeigen sie als reinen Text.

• list_projects

  Returns 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_graph

  Returns 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_impact

  Walks 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_bugs

  Scans 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_bug

  Returns 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_seasons

  Returns 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_ground

  Returns 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_events

  Returns 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_bug

  Creates 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_project

  Creates 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_season

  Creates 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_node

  Creates 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_node

  Partial 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_node

  Sets 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_plan

  Promotes 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_commit

  Configuration 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_edge

  Creates 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_edge

  Removes an edge from the ground. Use to retire dependencies/flows that no longer reflect reality.

• create_api

  Records 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_api

  Partial update of an API. Patchable fields: label, description, metadata, start, end.

• delete_api

  Sets removed_at on the API. History is preserved — the API can still be seen in past season views via the time slider.

• update_bug

  Partial 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_bug

  Permanently 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_feedback

  Files 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_feedback

  Lists 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_feedback

  Updates 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_wiki

  Lists 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_wiki

  Returns 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_revisions

  Returns 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_wiki

  Writes 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_wiki

  Replaces 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_wiki

  Permanently 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

Basischecksi

Wir prüfen Informationen, die jeder sehen kann; den Code haben wir nicht gelesen. Checks, die nicht zutreffen, werden nicht mitgezählt. · Geprüft am 8. Nov. 2026

• ✓ Bestanden

  Entwickler passt zum Repo

  Der Registry-Name wurde über die Domain umtri.io bestätigt (die Registry prüft, wem die Domain gehört)

• … Noch nicht geprüft

  Wird noch gepflegt

  Dieses Repo haben wir noch nicht von GitHub gelesen

• … Noch nicht geprüft

  Hat eine Lizenz

  Dieses Repo haben wir noch nicht von GitHub gelesen

• ✓ Bestanden

  Endpunkt antwortet

  Antwort in 1323 ms (HTTP 200)

• – Nicht zutreffend

  Anmeldung mit OAuth

  Keine Anmeldung nötig

• ✓ Bestanden

  Keine versteckten Anweisungen in Tool-Beschreibungen

  Wir haben 32 Tool-Beschreibungen gelesen und keine versteckten Anweisungen an die KI gefunden

Im Vergleich mit anderen in Reisen, Karten & Wetteri

• Mehr Sterne als 0 % der anderen 1711 Server in dieser Kategorie
• Neuer in der Registry veröffentlicht als 95 % der anderen 1711 Server in dieser Kategorie
• Basischecks gleich gut wie oder besser als bei 100 % der anderen 1711 Server in dieser Kategorie

Verglichen mit allen aktiven Servern dieser Kategorie in der Registry. Sterne zählen nur, wenn dem Herausgeber das Repo gehört.

Alternativen

Server derselben Kategorie von anderen Entwicklern, sortiert nach Sternen.

So liest du eine Karte:★ GitHub-SterneiDrei Säulen: Bewertungen · Checks · NutzungiAktualisiert = neueste Version in der Registry veröffentlichti

README vom Entwickler

claude mcp add --transport http umtri https://mcp.umtri.io \

{

claude mcp add umtri \

umtri://rules/vocabulary            umtri://rules/plan