Skip to main content
Glama

Hands Delegated Run

alterlab_hands_run

Hands supplies structure, verification and execution; your own model supplies drafts and decisions, and no platform model is called. action=create starts a run from a goal (mode preview runs the loop in a throwaway context and never commits; mode run commits after verification and policy). action=advance sends facts you found (each with its sources), a batch of actions to execute, or finish. A contradicted fact blocks the run until it is found again. When the approval policy asks, the run is awaiting_user with a pending_request to relay to the user; reply with action=answer. action=status returns the run and action=events returns events after a seq cursor (the same stream the CLI and the Playground Studio read).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "alterlab_hands_run"
  }
}

Input Schema

NameRequiredDescriptionDefault
actNoAdvance: the batch to execute, as for alterlab_task_act
goalNoCreate: the goal in the user's words
modeNoCreate: default run
afterNoEvents: return events with seq greater than this
factsNoAdvance: facts you found, each with evidence
graphNoCreate: optional task graph you propose; validated, never executed as given
actionNoDefault create
answerNoAnswer: the user's words for a question
finishNoAdvance: you are done; ends the run with a receipt
inputsNoCreate: values the goal needs
run_idNoRequired for advance, answer, status and events
targetNoCreate: what the run acts on
decisionNoAnswer: for an approval
policy_refNoCreate: approval-policy label the run's actions match
request_idNoAnswer: the pending request id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the structured data, it discloses critical behavioral traits like the difference between 'preview' and 'run' modes, how 'contradicted facts' block progress, and how it handles the 'await_user' state.

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 definition is appropriately dense given the extreme complexity of the tool, laying out the entire operational lifecycle. It is highly technical and dense, slightly reducing its conciseness score but remains structurally logical by addressing philosophy, actions, and state sequentially.

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 state-driven workflow tool with 15 parameters, the definition is exceptionally complete. It explains the internal logic and state transitions (e.g., pending_request, seq cursor), leaving very little ambiguity for an agent attempting to manage the run.

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?

While the schema provides structure, the description provides crucial meaning to the parameters within the workflow context, such as defining 'goal' as the user's natural language input or clarifying that 'facts' must include sources/evidence.

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 clearly defines the tool's operational model: the platform provides structure while the external model supplies drafts and decisions. It immediately establishes the primary purpose as managing a delegated run process.

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?

It provides detailed guidance on when to invoke each action, such as 'create' for starting from a goal, 'advance' for executing actions, and 'answer' for responding to system prompts. This removes ambiguity in a multi-step workflow.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.