Skip to main content
Glama

session_start

Orient a coding agent at session start by returning workspace path, language, git branch, memory index, recent files/commits, and live LSP diagnostics. Use 'brief' for a compact subagent re-orientation.

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: 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.
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 ignored and normal detection applies. 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). 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.
session_idNoOptional 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.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 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"
      +}
  2. First observedv0.16.6

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations at all, the description carries the full behavioral burden, and it succeeds. It discloses idempotency ('safe to call multiple times'), the sticky-pin guard and force override, the automatic default flip for resumed sessions, and what the returned packet contains. This gives an agent a faithful model of the tool's side effects and safety characteristics.

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 it is dense and each sentence carries real content: returned fields, workspace pinning, brief mode, idempotency, and the guard behavior. It is front-loaded with the most important instruction ('call this first'). Slight structure improvements (e.g., bullets) would help, but the length is justified for a complex bootstrap tool.

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?

This is a six-parameter tool with no annotations and no output schema, so the description must compensate — and it does. It covers output contents, default behaviors, parameter interactions, edge cases (resumed sessions, no resolved workspace, shared connections), and safety. An agent has enough to invoke it correctly and interpret its results.

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%, so the baseline is 3; the schema already documents all six parameters in detail. The description reinforces the purpose of workspace and detail, and adds context about the sticky-pin guard, but it does not meaningfully add new parameter semantics beyond the rich schema.

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' and then enumerates exactly what it returns (workspace path, language, git branch, context file excerpt, memory names, git policy, diagnostics, etc.). This is a specific verb plus resource with a clear one-shot orientation purpose that separates it from all sibling tools.

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 this first at the start of every session.' It also instructs when to pass workspace ('If no workspace is resolved yet'), when to use detail:'brief' ('A subagent that just needs cheap re-orientation'), and when to use force ('deliberately switching THIS connection to another project'). This is unusually actionable.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/plumbkit/plumb'

If you have feedback or need assistance with the MCP directory API, please join our Discord server