Skip to main content
Glama

request_plan_approval

Submit completed implementation plans for user approval before AI validation, enabling human-in-the-loop review with options to approve, modify, or reject for iterative refinement.

Instructions

Request Plan Approval

Description

Present a completed plan to the user for approval before proceeding to AI judge validation. This tool enables human-in-the-loop plan review and iterative refinement based on user feedback.

When to use

  • After creating a detailed implementation plan but before calling judge_coding_plan

  • When the task is in PLANNING state and a complete plan has been prepared

  • To enable user review and approval of plans before AI validation

Prerequisites

  • Task must be in PLANNING state

  • Complete plan, design, and research must be prepared

  • Task metadata must exist (call set_coding_task first if needed)

Args

  • plan: string — Detailed implementation plan with step-by-step approach (required)

  • design: string — Technical design and architecture decisions (required)

  • research: string — Research summary and findings (required)

  • task_id: string — Task UUID (required)

  • research_urls: list[string] — URLs from external research sources (optional)

  • problem_domain: string — Problem domain statement (optional)

  • problem_non_goals: list[string] — Non-goals and scope boundaries (optional)

  • library_plan: list[dict] — Library selection map with purpose, selection, source (optional)

  • internal_reuse_components: list[dict] — Internal components to reuse with paths (optional)

Returns

  • approved: boolean — Whether the user approved the plan

  • user_feedback: string — User's feedback or modification requests

  • next_action: string — Recommended next step based on user decision

User Options

The tool presents three options to the user:

  1. Approve — Proceed with the plan as-is (transitions to PLAN_APPROVED state)

  2. Modify — Request changes to the plan (returns to PLANNING state with feedback)

  3. Reject — Start over with a different approach (returns to PLANNING state)

Workflow Integration

  • On Approval: Task remains in PLAN_PENDING_APPROVAL state, ready for judge_coding_plan AI validation

  • On Modification: Task returns to PLANNING state with user feedback integrated

  • On Rejection: Task returns to PLANNING state for complete plan revision

Notes

  • This tool uses the MCP elicitation system to present plans in a user-friendly format

  • User feedback is automatically integrated into task requirements for plan iteration

  • The tool maintains full audit trails of user decisions and feedback

  • Always use the exact task_id; recover it via get_current_coding_task if missing

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
planYes
designYes
task_idYes
researchYes
library_planNo
research_urlsNo
problem_domainNo
problem_non_goalsNo
internal_reuse_componentsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
approvedYesWhether the plan was approved
next_actionYesNext action to take based on user decision
user_feedbackNoUser's feedback or modification requests
workflow_guidanceYesLLM-generated next steps and instructions from shared method
current_task_metadataYesALWAYS current state of task metadata after operation
Behavior5/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It thoroughly explains the user options (Approve/Modify/Reject), workflow state transitions, audit trails, and the elicitation system. This goes well beyond a basic mutation statement.

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 well-structured with clear sections (Description, When to use, Prerequisites, Args, Returns, etc.) and is appropriately front-loaded. It is long but avoids redundancy; each section earns its place for a complex human-in-the-loop tool.

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?

The description is exceptionally complete for a tool with 9 parameters and an output schema. It explains return values, user options, workflow integration, state transitions, and prerequisites, making it fully actionable for an AI agent.

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 description coverage is 0%, so the description compensates by listing all 9 parameters with brief definitions. While some definitions are somewhat tautological (e.g., 'research_urls: URLs from external research sources'), most add meaning beyond the raw schema, such as 'library_plan: Library selection map with purpose, selection, source'.

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 opens with a specific verb and resource: 'Present a completed plan to the user for approval before proceeding to AI judge validation.' This clearly states what the tool does and distinguishes it from sibling tools like judge_coding_plan, which handles AI validation.

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?

An explicit 'When to use' section lists exact conditions ('After creating a detailed implementation plan but before calling judge_coding_plan') and prerequisites. This clearly communicates when to use the tool versus alternatives, such as judge_coding_plan or set_coding_task.

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/groxaxo/mcp-llm-router'

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