Skip to main content
Glama
Hmbown

Hegelion

by Hmbown

autocode_turn

Advance an autocoding loop by executing one step: generate implementation prompts as player, verify with coach prompts, or advance state after approval.

Instructions

Execute one step in the autocoding loop. role=player: generate implementation prompt (advances state to coach). role=coach: generate verification prompt. role=advance: advance state after coach review.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdNoOptional working directory for backend execution. Defaults to the MCP server process cwd.
roleYesWhich step to execute: player, coach, or advance
stateYesAutocodingState dict from previous step
backendNoExecution backend for role=player or role=coach. auto prefers Codex MCP, then CLI, then prompt-only fallback.auto
executeNoIf true for role=player or role=coach, execute the returned prompt through the selected backend.
approvedNoWhether coach approved (required for role=advance)
coach_feedbackNoCoach feedback text (required for role=advance)
timeout_secondsNoTimeout (seconds) for backend execution when execute=true (default: 120)
Behavior3/5

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It explains that the tool advances state and can optionally execute through a backend, but it doesn't disclose important side-effect behaviors: that role=advance requires approved+coach_feedback, that execute=true triggers external code execution (a potentially significant/destructive action with real side effects), or error/state-failure behavior. The backend selection fallback (auto prefers Codex MCP, then CLI) is disclosed, which helps, but the external execution side effects are not flagged.

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 compact—three sentences covering the core loop, each role, and execution behavior. It's front-loaded with the essential purpose, then elaborates roles. No wasted words. It could arguably spell out the role-specific required params, but overall it's efficiently written.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex stateful tool with 8 parameters, nested objects (state), no output schema, and no annotations. The description covers the loop mechanics but omits important usage detail: what the returned prompt/structure looks like (no output schema), what happens when state is invalid, how coach_feedback/approved interact, and the specific backend behavior consequences. For a tool this complex with no output schema and no annotations, the description could do more to complete the picture.

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 schema individually documents all 8 parameters. The description adds interconnect between roles and requirements (e.g., advance needing approval), but does not add meaning beyond the schema for most parameters like backend, execute, timeout. The role-specific interplay (which params apply to which role) is partially in the description but the schema's descriptions stand on their own well.

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 clearly explains the tool executes 'one step in the autocoding loop' and breaks out each role (player, coach, advance) with what each does. The verb 'execute' plus the explicit per-role behaviors distinguish it well from siblings like 'autocode' (likely the fuller loop) and 'dialectic'. It doesn't name the sibling alternatives explicitly, but the role breakdown provides strong functional differentiation.

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?

The description tells the agent when to use each role ('generate implementation prompt', 'generate verification prompt', 'advance state after coach review'), giving clear usage context per mode. It establishes the state machine transition (player→coach→advance). However, it doesn't explicitly contrast with siblings 'autocode' (the full loop) or explain when to call this step function vs the complete-loop tool, nor give exclusion guidance.

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

Install Server

Other Tools

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/Hmbown/Hegelion'

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