Skip to main content
Glama

Start a session

start_session

Launch a new coding tool or shell session in Agent Guild after asking the user; it opens on every connected screen in a chosen folder.

Instructions

Start a new session of a coding tool or shell in Agent Guild. Ask the person first. It opens on every screen connected to Agent Guild.

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": {
      "tool": "<tool>"
    },
    "name": "start_session"
  }
}

Input Schema

NameRequiredDescriptionDefault
cwdNoThe folder to start in. Defaults to the home folder.
nameNoA name for the session's card.
toolYesThe tool: "claude", "codex", "antigravity", "grok", "docker" or "shell", or a provider id from guild_status.
resumeNoThe id of one of the tool's own earlier sessions to resume.
accountNoThe account id to run under. Defaults to "default".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare non-read-only, non-destructive, non-idempotent and non-open-world behavior. The description adds two things annotations cannot convey: the session UI is broadcast to every connected Agent Guild screen, and human confirmation is expected before launch — both materially useful for an agent deciding whether to call it.

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?

Three short sentences with zero filler: purpose first, then the consent requirement, then the visible side effect. Nothing is repeated from the schema and every sentence carries information.

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?

Five well-documented parameters, annotations present, and no output schema to explain. The description covers purpose, consent, and side effects, but given there is no output schema it does not mention what the caller gets back (e.g. the session id needed for later stop_session or read_screen calls).

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 coverage is 100%, with every parameter documented including allowed tool values and the resume/account defaults, so the schema does the heavy lifting. The description adds no parameter-level meaning, which is acceptable at this coverage level but earns only the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Start a new session of a coding tool or shell') and scopes it to Agent Guild, which cleanly separates it from stop_session and list_sessions. It is clear enough to select without opening the schema, though it never names a sibling explicitly.

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

Usage Guidelines3/5

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

'Ask the person first' gives a confirmation precondition, which is useful procedural guidance. However, there is no statement of when this tool is preferred over resuming existing work or how it relates to sibling tools, so usage is only implied.

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