Skip to main content
Glama

session_start

Initialize a session by retrieving an orientation packet: workspace path, branch, context, diagnostics, and recent changes; use 'brief' for a lightweight summary.

Instructions

Bootstrap tool — call this first at the start of every session. Returns one-shot orientation: workspace path, language, current git branch, first 200 lines of .plumb/context.md, all saved memory names/descriptions, top-5 most-used tools, 5 most recently-modified files, 3 most recent commits, the live git tool policy (whether commits/destructive/push are enabled), and any active LSP errors/warnings. If no workspace is resolved yet, pass an absolute workspace to pin it — clients like Claude Desktop do not report the folder automatically. A subagent that just needs cheap re-orientation should pass detail: "brief" for a ≤1.5 KB summary instead of the full packet. Idempotent — safe to call multiple times.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNoOverride the sticky-pin guard: a re-pin away from a pin an explicit session_start already holds is refused unless force is true. Use it when you are deliberately moving this pin — see scope for whether that is your own shard or the whole connection.
scopeNoWhich pin a workspace re-pin moves. 'agent' (default) moves only your own shard, leaving peers where they are. 'connection' moves the connection's pin, which peers that never chose a root then follow; it needs force: true when an explicit pin holds the connection, and an identity, since it resets peers' workspace, reads and undo.
detailNoOrientation packet size. 'brief' (≤1.5 KB) returns workspace path, language, branch, a one-line git policy, diagnostics and active-peer COUNTS, memory NAMES only (no descriptions/sizes), and the edit-lane rule where it applies — cheap re-orientation for a subagent that does not need the full packet. 'full' returns the complete packet documented above. Defaults to 'full', except this default flips to 'brief' automatically when the supplied session_id was already seen by this daemon within the last 24h (a resumed conversation); an explicit value always wins over the automatic default.
purposeNoOptional human-readable tag describing what this session is for (e.g. 'deploy-fix', 'feature-auth'). Surfaced in the TUI session list, daemon_info, and workspace_sessions so an operator can tell concurrent sessions apart. Allowed characters: letters, digits, and hyphens; max 32 characters. An invalid value is rejected with a clear error.
languageNoOptional override for the workspace's primary language when automatic detection cannot infer it — e.g. an Xcode app that has .swift sources but no SwiftPM Package.swift, so no root marker resolves. Pass the [lsp.<lang>] key (e.g. 'swift', 'typescript', 'rust') to force that language server as the primary, so workspace_symbols and the call/type hierarchies work. The server must be installed and enabled; an unknown, uninstalled, or disabled language is refused, naming the reason and the remedy, not silently ignored. Honoured on the connection's current workspace, or alongside an explicit 'workspace' arg.
workspaceNoAbsolute workspace path. Use this to pin the project for clients that do not report a folder (e.g. Claude Desktop). Passing it re-pins — see force and scope for what that moves and when it is refused. Defaults to the daemon's already-resolved workspace.
session_idNoA stable id for THIS agent: the client's conversation id, or 'conversation/agent' for a subagent. Pass it every time: it scopes this agent's pin, read tracking and undo when agents share a connection, and carries your session name across a restart (same id, ended under 24 h ago). Claude Code's identity hook fills it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.20.2
    • changedInput schema / properties / force / description
      Previous value: -"Override the sticky-pin guard: when this connection is already pinned to a different project by an explicit session_start call, a re-pin is refused unless force is true. Use it only when you are deliberately switching THIS connection to another project — e.g. a new conversation on a connection reused across conversations. On a connection shared by several agents (Cowork, Claude Desktop local-agent-mode), prefer a dedicated plumb serve process per agent over forcing."New value: +"Override the sticky-pin guard: a re-pin away from a pin an explicit session_start already holds is refused unless force is true. Use it when you are deliberately moving this pin — see scope for whether that is your own shard or the whole connection."
    • addedInput schema / properties / scope
      Added value: +{
      +  "description": "Which pin a workspace re-pin moves. 'agent' (default) moves only your own shard, leaving peers where they are. 'connection' moves the connection's pin, which peers that never chose a root then follow; it needs force: true when an explicit pin holds the connection, and an identity, since it resets peers' workspace, reads and undo.",
      +  "enum": [
      +    "agent",
      +    "connection"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / workspace / description
      Previous value: -"Absolute workspace path. Use this to pin the project for clients that do not report a folder (e.g. Claude Desktop). If this connection is already pinned to a different project, passing a workspace here re-pins it to the new project — this is how you switch projects on a connection reused across conversations. When the current pin was itself set by an explicit session_start, the re-pin is refused unless you also pass force: true — a guard against a peer agent silently stealing the pin on a shared connection (issue #182). Defaults to the daemon's already-resolved workspace."New value: +"Absolute workspace path. Use this to pin the project for clients that do not report a folder (e.g. Claude Desktop). Passing it re-pins — see force and scope for what that moves and when it is refused. Defaults to the daemon's already-resolved workspace."
  2. Changed1 schema field changedv0.19.4
    • changedInput schema / properties / session_id / description
      Previous value: -"Optional opaque identifier linking this plumb session to the caller's own session (e.g. a Claude Code conversation ID). When provided, plumb persists the ID and, if a recent session with the same ID ended within the last 24 h, inherits its name — so a resumed conversation keeps its session name in the TUI."New value: +"A stable id for THIS agent: the client's conversation id, or 'conversation/agent' for a subagent. Pass it every time: it scopes this agent's pin, read tracking and undo when agents share a connection, and carries your session name across a restart (same id, ended under 24 h ago). Claude Code's identity hook fills it."
  3. Changed1 schema field changedv0.18.0
    • changedInput schema / properties / language / description
      Previous value: -"Optional override for the workspace's primary language when automatic detection cannot infer it — e.g. an Xcode app that has .swift sources but no SwiftPM Package.swift, so no root marker resolves. Pass the [lsp.<lang>] key (e.g. 'swift', 'typescript', 'rust') to force that language server as the primary, so workspace_symbols and the call/type hierarchies work. The server must be installed and enabled; an unknown, uninstalled, or disabled language is ignored and normal detection applies. Honoured on the connection's current workspace, or alongside an explicit 'workspace' arg."New value: +"Optional override for the workspace's primary language when automatic detection cannot infer it — e.g. an Xcode app that has .swift sources but no SwiftPM Package.swift, so no root marker resolves. Pass the [lsp.<lang>] key (e.g. 'swift', 'typescript', 'rust') to force that language server as the primary, so workspace_symbols and the call/type hierarchies work. The server must be installed and enabled; an unknown, uninstalled, or disabled language is refused, naming the reason and the remedy, not silently ignored. Honoured on the connection's current workspace, or alongside an explicit 'workspace' arg."
  4. Changed1 schema field changedv0.17.0
    • addedInput schema / properties / detail
      Added value: +{
      +  "description": "Orientation packet size. 'brief' (≤1.5 KB) returns workspace path, language, branch, a one-line git policy, diagnostics and active-peer COUNTS, memory NAMES only (no descriptions/sizes), and the edit-lane rule where it applies — cheap re-orientation for a subagent that does not need the full packet. 'full' returns the complete packet documented above. Defaults to 'full', except this default flips to 'brief' automatically when the supplied session_id was already seen by this daemon within the last 24h (a resumed conversation); an explicit value always wins over the automatic default.",
      +  "enum": [
      +    "brief",
      +    "full"
      +  ],
      +  "type": "string"
      +}
  5. First observedv0.16.6

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states idempotency ('safe to call multiple times'), explains the sticky-pin guard and force/scope semantics, details the automatic default flip to 'brief' for resumed sessions, and describes side effects like re-pinning and resetting peers' workspace/read/undo when using connection scope. The behavioral contract is exceptionally clear.

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?

The description is long but every sentence adds essential information given the tool's complexity (7 parameters, multiple interacting behaviors). It is front-loaded with the core purpose and packet contents, then organizes parameter-specific details logically. A slight deduction for verbosity—some sentences could be tightened—but it remains appropriately structured for the scope.

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 bootstrap tool with no output schema and 7 parameters, the description is remarkably complete. It covers all parameters, their defaults, side effects, edge cases (sticky-pin guard, language refusal, resumed-session behavior), and even explains the TUI and daemon_info integration. There is nothing an agent needs to know to call this tool correctly that is missing.

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

Parameters5/5

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

Although the schema provides 100% coverage, the description adds substantial meaning beyond the schema. For each parameter it explains purpose, interactions (e.g., force and scope together), constraints (purpose allowed characters, max length), and default behaviors (detail default flipping on resumed sessions). It also explains edge cases like language server validation and refusal reasons. This significantly helps an agent use the parameters correctly.

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?

The description opens with 'Bootstrap tool — call this first at the start of every session,' clearly stating the verb (bootstrap/start) and resource (session). It lists the exact contents of the orientation packet, making the tool's purpose unmistakable and distinct from sibling tools, which are all focused on specific file/symbol/topology operations.

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?

The description gives explicit when-to-use guidance: call it first at the start of every session, and it explains the detail parameter to choose between brief and full packets based on need (e.g., 'A subagent that just needs cheap re-orientation should pass detail: brief'). It also addresses the special case of clients that don't report the workspace folder and explains the sticky-pin guard behavior. This is far beyond minimal usage guidance.

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