Skip to main content
Glama
Platano78

Smart-AI-Bridge

parallel_agents

Run test-first development as a graph of parallel agents: decomposes tasks, writes failing tests, implements to pass, and iterates quality checks until threshold or max iterations.

Instructions

Run a test-first development workflow as a graph of parallel agents: a decomposer splits the task into atomic subtasks, RED-phase agents write failing tests, GREEN-phase agents implement to pass them, then a quality reviewer iterates the cycle until a threshold is met or max_iterations runs out. Use for self-contained features that benefit from test-first discipline and can be parallelized. For a single agent on a single task, use spawn_subagent. For a generate→review→fix loop on one code blob (no test infrastructure), use dual_iterate. ⚠️ DESTRUCTIVE when write_files:true (default): generated tests, implementation, and refactor outputs are written under work_directory in red/, green/, refactor/ subdirectories (defaults to /tmp/parallel-agents-<timestamp>). Returns: {success, task, decomposition (decomposer's plan), execution:{groups_executed, tasks_completed, tasks_failed, max_parallel_used, files_written, write_files_enabled}, router_info:{slots, model, status}, quality:{verdict, score, iterations}, synthesis (combined output), files:[absolute paths written], work_directory, processing_time_ms, metrics}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taskYesHigh-level task to decompose and execute via TDD workflow
max_parallelNoMaximum parallel agents (matches GPU slots, default: 2)
iterate_until_qualityNoWhether to iterate on failed quality checks
max_iterationsNoMaximum quality gate iterations (prevents infinite loops)
write_filesNoWrite generated code to files in work_directory (default: true). Files are organized by phase (red/green/refactor subdirectories).
work_directoryNoOptional directory for generated files (default: /tmp/parallel-agents-{timestamp})
Behavior5/5

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

No annotations are provided, but the description thoroughly explains behavioral traits: destructive when write_files:true, file organization under red/green/refactor subdirectories, default work_directory, and return structure including detailed fields.

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 fairly long but front-loaded with workflow explanation. It includes warnings and return structure. Every sentence adds value, though could be slightly more concise.

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 tool is complex with 6 parameters and no output schema. The description explains all parameters and the entire return value structure. Given the complexity, it is complete.

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 100%, so baseline 3. The description adds extra meaning beyond the schema: e.g., 'Files are organized by phase (red/green/refactor subdirectories)' for write_files, and explains the iterative cycle for iterate_until_quality and max_iterations.

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 states it runs a test-first development workflow as a graph of parallel agents with specific phases (decomposer, RED, GREEN, quality reviewer), and distinguishes from siblings like spawn_subagent and dual_iterate by naming them directly.

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?

Explicitly says 'Use for self-contained features that benefit from test-first discipline and can be parallelized.' It also gives alternatives: 'For a single agent on a single task, use spawn_subagent. For a generate→review→fix loop on one code blob (no test infrastructure), use dual_iterate.'

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/Platano78/Smart-AI-Bridge'

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