Skip to main content
Glama

mission_start

Start a long multi-step run by saving its goal and ordered checklist to the server, so the plan and acceptance criteria persist outside your context.

Instructions

Write down what a long run is for, before you lose it. Halfway through a twenty-window scenario the plan has scrolled out of your context and what is left is a confident recollection of it — a mission is that plan kept outside you, in the server's database. goal is what the whole run is for. items is the checklist in order, each {title, intent, acceptance}: what to do, WHY it is on the list, and what would make it done. All three are required and none may be blank — intent and acceptance are the two you will no longer have when you read this back, and they are the reason the record is worth keeping at all. THE LOOP: mission_start -> work item by item, running each with execute_plan(steps=[...], mission_item_id=N) so the run files its own verdict and its steps onto item N -> the status block comes back on every reply, so you never have to remember where you are -> repeat a recorded pass later with mission_replay(N) -> mission_finish when there is nothing left to try. One mission is active at a time: starting a second while one runs is refused, naming the one to finish or abandon first. The reply is the status block — goal, progress, the item now in play with its intent and acceptance, and any failures with their reasons.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
goalYes
itemsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and discloses meaningful behavior: state is persisted in the server's database, only one mission may be active, a conflicting start is refused, and the reply is a status block. It does not cover auth requirements or failure modes beyond the concurrency conflict, but the state-machine disclosure is substantive.

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

Conciseness3/5

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

The content is dense and mostly earns its place, but the framing is deliberately narrative ('before you lose it', 'a confident recollection of it'), and the context-window motivation sentence spends prose on why rather than what to do. The actionable verb is not front-loaded; the workflow and constraints arrive well into the text.

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 stateful, multi-step tool with a weak schema and an output schema present, the description supplies the missing nested parameter structure, the concurrency constraint, the reply composition, and the surrounding workflow. Nothing an agent needs to call it correctly is absent.

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?

Schema description coverage is 0% and the nested item structure is undefined in the schema, so the description fully compensates: goal is defined as the purpose of the whole run, and items is defined as an ordered checklist of {title, intent, acceptance} with each field's meaning. It further specifies that all three are required and none may be blank — meaning the description adds information the schema does not.

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?

Once parsed, the description clearly states it creates a persistent mission record holding the run's goal and an ordered checklist. It names the resource (mission) and the workflow verb framing ('write down'), and differentiates from siblings by describing the loop through execute_plan, mission_replay, and mission_finish. The core verb is somewhat buried under the 'long run' metaphor, which slightly muddies the first read.

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?

It gives a clear trigger (before a long run / before you lose the plan) and an explicit workflow ordering all related siblings. It also states a hard constraint: one mission active at a time, and a second start is refused naming the mission to finish or abandon. No explicit 'when not to use' beyond that, so it stops just short of a 5.

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