Skip to main content
Glama
opsmill

infrahub-mcp

Official
by opsmill
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Reset Session Branch

reset_session_branch

Control which branch your writes target in the current MCP session. Clear the cached branch to start fresh, or switch to a specific branch; only this session changes.

Instructions

Reset or switch the active session branch for the current MCP session.

Use this to recover or take control of which branch your writes target:

  • No branch — clears the cached session branch; the next write auto-creates a fresh one. Useful after you have merged your work and want to start a new change set.

  • With branch — points this session at the named branch. If it does not exist and the name matches the configured branch pattern, it is created and reported. The instance default branch and merged/read-only branches are rejected.

Note: a merged or deleted session branch is recovered automatically on the next write — this tool is the explicit override on top of that.

Affects only the calling session; other sessions are unaffected.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
branchNoTarget branch. Omit to drop the cached session branch so the next write creates a fresh one. Provide a name to switch this session to that branch (created if it does not exist and the name matches the configured pattern).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.0
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
  2. Addedv1.1.6

TDQS

A4.7/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and the description adds real behavior beyond them: auto-creation when the name matches the configured pattern, rejection of the instance default and merged/read-only branches, and session-local scope. It stops short of stating what happens to a branch left dangling or whether the switch is transactional, so a 4 rather than 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-loaded with the core action, then cleanly split into the two argument modes and a clarification note about automatic recovery. No sentence is filler; the bullets map one-to-one onto the decisions an agent must make.

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?

For a single optional-parameter mutator with no output schema and full annotation coverage, the description closes every gap an agent needs: scope, side effects, fallback behavior, and the automatic-recovery baseline against which the tool is an override.

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 semantics not in the schema: the rejection rule for the default/merged/read-only branches and the report-back behavior on creation. The omit-vs-provide distinction is well covered in both places.

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 (reset/switch) and resource (active session branch for the current MCP session), with the scope delimited up front. No sibling tool touches session-branch state, so it is trivially distinguishable from query_graphql, node_upsert, and the rest.

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?

Explicitly says when to use it (recover or take control of write targets, or start a new change set after merging) and, unusually, when it is NOT needed — automatic recovery on the next write — so the agent knows this is the explicit override. Both argument modes are given matching conditions.

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

Deploy Server

Other Tools