Umtri

Commit a realized plan node

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 considered realized. Call this only after you have actually written the code and recorded implements via update_node. Commit from the top down: a node whose parent is still a plan is rejected — commit the parent first. See 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>",
      "id": "<id>"
    },
    "name": "commit_plan"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Plan node id to commit.
`slug`	Yes	Ground slug.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4.4/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 so well: it names the verification gate, the rejection conditions (missing metadata.implements, uncommitted parent), and the mutation performed (clearing the plan flag). It stops short of covering idempotency, permissions, or the response, which keeps it from 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.

Conciseness5/5

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

Front-loads the core action in the first clause, then layers the gate and ordering constraints in order of operational importance. No sentence is redundant, and the pointer to umtri://rules/plan is placed at the end where it does not interrupt the procedure.

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

Completeness4/5

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

For a two-parameter mutation tool with no annotations and no output schema, the description covers preconditions, ordering, and the state change — nearly everything needed to invoke it correctly. Return value behavior is unaddressed, but the tool is simple enough that this is a minor gap.

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

Parameters3/5

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

Schema description coverage is 100% with only two parameters, both documented in the schema, so the baseline is 3. The description adds conceptual context (the node must already carry implements) but no extra meaning about the 'slug' ground scoping or id format beyond what the schema states.

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 — 'Promotes a plan node (metadata.plan=true) to the real tree by clearing the plan flag' — which precisely describes the state transition. It is clearly distinguishable from siblings like update_node and create_node, which create or modify instead of promoting.

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 preconditions ('Call this only after you have actually written the code and recorded implements via update_node') and an explicit exclusion ('a node whose parent is still a plan is rejected — commit the parent first'). It also names the coupling to update_node, so an agent can sequence the two calls without inference.

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.