Umtri

Record a git commit onto the nodes it touched

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 one commit touches several nodes that are NOT yet connected, the response also carries coChangeCandidates[] ({a, aLabel, b, bLabel}) — nodes that change together are dependency candidates; review them and add a create_edge/create_api where a real relation exists (not auto-created; suppressed for large multi-node commits; pass coChange=false to skip them entirely when nobody will review, e.g. a CI step that only records). Umtri does not run jobs or read git itself — a GitHub Action / CI step or an agent supplies the sha+files. Recording a commit is the LAST step: first make sure the change is in the tree (new unit → create_node with metadata.implements; moved file → update_node), otherwise the sha lands on the nodes that happen to exist and the new ones stay invisible. A repo that keeps forgetting should write the habit down — see umtri://rules/commit-sync. See also umtri://rules/plan.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "slug": "<slug>",
      "sha": "<sha>",
      "files": "<files>"
    },
    "name": "record_commit"
  }
}

Input Schema

Name	Required	Description
`sha`	Yes	Commit SHA (short or full).
`slug`	Yes	Ground slug.
`files`	Yes	Repo-relative paths changed by the commit, matched against nodes' metadata.implements.
`message`	No	Commit message (optional, stored with the record).
`coChange`	No	Default true. false skips coChangeCandidates — for callers that record every commit and never review the suggestions.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations the description carries the full burden and does well: it discloses dedupe-by-sha idempotence, the returned payload (matched node ids plus coChangeCandidates[] shape), that candidates are never auto-created, and that they are suppressed for large multi-node commits. It does not describe error behavior for unmatched files or how a re-record with a different message is handled, which keeps it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Core operation is front-loaded in the first sentence, but the remainder is a single dense paragraph with nested parentheticals and multiple rule references that make it hard to scan. Almost every clause is informative, yet the lack of structural separation costs readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists and the description still explains the return shape (node ids, coChangeCandidates with a/aLabel/b/bLabel), preconditions, and the review follow-up. For a mutation tool with no annotations, that is complete enough for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: files are matched against nodes' metadata.implements, dedup keys on sha, and coChange defaults to true with the practical consequence of skipping review suggestions. It does not clarify slug or message semantics further, but the schema already covers those.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: finds nodes whose metadata.implements match the changed files and appends the commit (sha + timestamp + message) to metadata.commits, deduped by sha. It also names what the tool explicitly is not (Umtri does not run jobs or read git; a CI step supplies sha+files), which separates it from sibling readers/writers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit ordering guidance (recording is the LAST step; create_node with metadata.implements or update_node must happen first), an explicit opt-out condition (coChange=false when nobody will review, e.g. a CI step that only records), and names sibling tools (create_edge, create_api) for the review follow-up.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Umtri tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.