Skip to main content
Glama

agent_boot

Start or resume autonomous agent work in one token-budgeted call: retrieve session state, checkpoint summary, open tasks, handoff, lessons, facts, goals, skills, and repo map before proceeding.

Instructions

Boot an autonomous agent: ONE token-budgeted call returning everything needed to start or resume work. Call this FIRST in any agent run. Returns {agent, session:{...,role}, resume:{checkpoint_summary, open_tasks}, handoff:{tldr, source}, lessons:[], facts:[], brief, skills:[], skills_full, repo_map, siblings:[], budget:{limit, used, dropped}, client}. If a non-terminal session exists for this agent (or session_id is given), resume tells you exactly where you left off; handoff is the best-ranked latest handoff (a hand-written wrap SEED first). goal drives the facts, lessons AND skills retrieval. skills are parametrized procedures distilled from verified past runs matching the goal ({context_id, name, description, success_count, similarity}) -- check them BEFORE re-deriving a solution. On a session's later boots skills holds only new or changed entries and skills_full is false (empty then means nothing new, not no skills); pass full:true for the complete set. With project_id you also get a goal-graph brief {north_star, role, lane, next, blocked_on, blocking, done} and the session role is inferred from the matched goal node. With include_repo_map:true on a code-indexed workspace, repo_map carries top-ranked file signatures to answer "where is X handled" without grepping. siblings lists other active sessions in this workspace (last ~60 min, max 5) so you can coordinate via relay_* before touching shared resources. Slots fill resume > handoff > lessons > facts > brief; overflow is reported in budget.dropped. Trigger: resume or catch up on tracked work ("hôm trước tới đâu", "tiếp gì", "tóm lại đang làm gì", "what's next", "resume", "where did we leave off", "catch me up"). Skip for unrelated casual questions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fullNoT506: bypass the skills diff-since-last-boot behavior and always return the full current skills match set. Default false (repeat boots of the same session return only new/changed skills).
goalNoThe objective for this run — drives relevant-facts + lessons retrieval AND goal-node role inference
agentYesStable agent slug (handle the agent boots with every run, e.g. 'claude-code')
workspaceNoWorkspace slug to scope handoff + facts to
agent_nameNoHuman-readable name; used only when the agent is first created
project_idNoProject id to scope the goal-graph situation brief + role inference to (omit = no brief, classic pack)
session_idNoResume a specific session by id (otherwise the latest active/paused session for this agent)
token_budgetNoMax tokens for the assembled pack (default 4000)
epistemic_minNoEpistemic floor (T358) for the FACTS slot: only surface facts at or above this confidence tier (weakest->strongest: assumed < inferred < told < observed). Omit for no floor.
include_repo_mapNoWhen true, include a token-budgeted repo map (entries with path+signatures) from code-indexed contexts. Only useful for workspaces indexed with contextq index. Default false.
repo_map_token_budgetNoToken cap for the repo map slot (default ~2000, range 100-16000). Ignored when include_repo_map is false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.1

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses state-dependent behavior (skills diff-since-last-boot on repeat boots, where empty means 'nothing new'), slot precedence ('resume > handoff > lessons > facts > brief'), and overflow reporting via budget.dropped. It also explains role inference and sibling-session scope (~60 min, max 5).

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 purpose and gets denser but rarely wastes a sentence — the trigger examples and slot/resume rules all earn their place. It is a long wall of text, however, and could be broken into scannable lines for faster parsing.

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, yet the description enumerates the returned pack structure in detail (agent, session.role, resume, handoff, lessons, facts, brief, skills, repo_map, siblings, budget, client) and explains how each conditional branch is populated. An agent has everything needed to call it and interpret the response.

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 already 100%, so the baseline is 3, but the description adds real meaning beyond the schema: 'goal' drives facts/lessons/skills retrieval AND role inference, 'full:true' overrides the diff behavior, and 'project_id' gates the goal-graph brief. It adds useful semantics for the highest-impact parameters rather than just restating names.

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+resource ('Boot an autonomous agent') plus the distinguishing value proposition: a single token-budgeted call returning everything to start or resume work. It clearly positions itself apart from siblings like agent_session_start and agent_resume, and even names relay_* for coordination.

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?

Explicit routing: 'Call this FIRST in any agent run', a concrete trigger list for resume/catch-up work (with multilingual examples), and an explicit exclusion ('Skip for unrelated casual questions'). Also states when the resume/handoff/skills branches activate, so an agent knows exactly when this beats alternatives.

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