Skip to main content
Glama

Get Session Info

get_session_info
Read-only

Returns the current MCP session state, including the active session branch and Infrahub instance address, so you can confirm which branch writes will target before making changes.

Instructions

Return the current MCP session state — call before writes to know which branch they target.

Reports the active session branch (if any) and the Infrahub instance address. A session branch is lazily auto-created on the first write tool call (node_upsert / node_delete / mutate_graphql) and is named mcp/session-YYYYMMDD-<hex>. Before that first write, session_branch is None and all read tools target the default branch.

Typical uses:

  • Confirm which branch a proposed change would merge from.

  • Decide whether a write is about to open a new session branch.

  • Display the active branch to the user.

Input Schema

NameRequiredDescriptionDefault

No arguments

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. First observedv1.1.5

TDQS

A4.6/5.0
Behavior5/5

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

Beyond readOnlyHint=true, it discloses the non-obvious mechanism: the session branch is lazily auto-created on the first node_upsert/node_delete/mutate_graphql call, named 'mcp/session-YYYYMMDD-<hex>', and is None with reads targeting the default branch beforehand. That is exactly the state machine an agent needs to reason about.

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

Conciseness4/5

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

Front-loaded with the one-line purpose, then the mechanics, then a short bulleted use list — every section earns its place. Slightly long, but the extra length carries genuinely non-inferable detail.

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 compensates by naming the two returned values and their possible states (branch vs None). An agent has everything needed to call it and interpret the result.

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?

The tool takes zero parameters, so the 4 baseline applies; the description correctly signals a no-argument call while describing what the returned state fields (session_branch, instance address) mean.

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 ('Return the current MCP session state') plus its scope (active branch + instance address). A reader can immediately distinguish it from sibling tools like reset_session_branch or the write tools it references.

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

Usage Guidelines4/5

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

Explicitly says to 'call before writes to know which branch they target' and gives three concrete typical uses (confirm merge branch, predict session-branch opening, display to user). It stops short of naming reset_session_branch as the counterpart alternative, so it is clear context without full when-not guidance.

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