Enables the parallel generation and orchestration of Angular-based UI components and design systems through specification-driven architecture.
Supports the automated creation of structured technical documentation, API references, and reports in Markdown format.
Facilitates the sophisticated generation of React components and interface patterns, incorporating TypeScript compliance and accessibility standards.
Allows for the automated generation of type-safe code, including functions, classes, and modules, ensuring adherence to specified quality standards.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Universal Infinite Loop MCP Server Orchestrate 5 modern React search components with unique interaction patterns."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A goal-agnostic parallel orchestration framework implementing Disler's Infinite Agentic Loop patterns as a Model Context Protocol (MCP) server. This system enables sophisticated multi-agent coordination for any domain through specification-driven architecture.
UI Components: React, Vue, Angular, Web Components
Documentation: Technical docs, API references, tutorials, guides
Code Generation: Functions, classes, modules, entire applications
Research & Analysis: Data analysis, reports, investigations
Content Creation: Articles, marketing copy, social media, blogs
Design Systems: Component libraries, style guides, design tokens
Wave-Based Generation: Parallel agent coordination with progressive sophistication
Context Management: Intelligent context usage monitoring and graceful degradation
Innovation Dimensions: Multi-dimensional creative exploration and uniqueness enforcement
Quality Assurance: Domain-specific validation and quality scoring
Failure Handling: Graceful error recovery and agent reassignment
Flexible Specifications: Adapt to any domain through comprehensive specification system
Progressive Sophistication: Multiple sophistication levels from basic to revolutionary
Evolution Patterns: Linear, exponential, adaptive, and creative burst generation patterns
Validation Rules: Customizable validation for syntax, semantics, functionality, and quality
Related MCP server: Bernstein - Multi-agent orchestration
# Clone and install
git clone <repository-url>
cd infinite-loop-mcp-server
npm install
# Build
npm run build
# Run in development
npm run devAdd to your MCP client configuration:
{
"mcpServers": {
"infinite-loop": {
"command": "node",
"args": ["/path/to/infinite-loop-mcp-server/dist/server.js"]
}
}
}infinite_orchestrateMain orchestration tool for goal-agnostic parallel generation.
{
specification: UniversalSpecification,
outputDirectory: string,
mode: {
type: 'SINGLE' | 'BATCH' | 'INFINITE',
count: number | 'INFINITE',
batchSize?: number,
maxWaves?: number
},
config?: {
contextThreshold?: number,
gracefulShutdown?: boolean,
progressiveSophistication?: boolean
}
}Example - UI Component Generation:
{
"specification": {
"name": "React Search Components",
"description": "Modern search interface components with various interaction patterns",
"domain": {
"category": "UI",
"subcategory": "React Components",
"targetAudience": "Frontend Developers",
"complexity": "MODERATE"
},
"outputRequirements": {
"format": "tsx",
"structure": "Single component file with TypeScript",
"namingPattern": "SearchComponent_{number}.tsx",
"qualityStandards": ["TypeScript compliant", "Accessible", "Responsive"]
},
"innovationDimensions": ["interaction_patterns", "visual_design", "accessibility", "performance"],
"sophisticationLevels": [...],
"evolutionPattern": "CREATIVE_BURST"
},
"outputDirectory": "./generated-components",
"mode": {
"type": "BATCH",
"count": 10,
"batchSize": 5
}
}Example - Documentation Generation:
{
"specification": {
"name": "API Documentation",
"description": "Comprehensive API documentation with examples and best practices",
"domain": {
"category": "DOCUMENTATION",
"subcategory": "API Reference",
"targetAudience": "Developers",
"complexity": "COMPLEX"
},
"outputRequirements": {
"format": "md",
"structure": "Structured markdown with code examples",
"namingPattern": "api_docs_{number}.md",
"qualityStandards": ["Complete coverage", "Clear examples", "Best practices"]
},
"innovationDimensions": ["clarity", "completeness", "interactivity", "searchability"],
"evolutionPattern": "LINEAR"
},
"outputDirectory": "./docs",
"mode": {
"type": "INFINITE",
"count": "INFINITE"
}
}wave_planPlan generation waves with sophisticated agent assignment.
{
existingWork: IterationInfo[],
sophisticationLevel: SophisticationLevel,
targetCount: number,
contextBudget: number
}agent_coordinateCoordinate parallel agent execution with uniqueness enforcement.
{
assignments: AgentAssignment[],
innovationDimensions: string[],
contextMonitor: ContextMonitor
}context_monitorMonitor context capacity and manage graceful shutdown.
{
waveId: string,
capacityThreshold: number,
gracefulShutdown: boolean
}spec_validateValidate and enhance specifications with intelligent defaults.
{
userSpec: Partial<UniversalSpecification>,
domain: SpecificationDomain,
outputRequirements: any
}interface UniversalSpecification {
id: string;
name: string;
description: string;
domain: SpecificationDomain;
version: string;
outputRequirements: {
format: string;
structure: string;
namingPattern: string;
qualityStandards: string[];
};
innovationDimensions: string[];
sophisticationLevels: SophisticationLevel[];
constraints: string[];
evolutionPattern: 'LINEAR' | 'EXPONENTIAL' | 'ADAPTIVE' | 'CREATIVE_BURST';
progressionStrategy: string;
successCriteria: string[];
validationRules: ValidationRule[];
}UI: Frontend components, interfaces, user experiences
DOCUMENTATION: Technical writing, API docs, tutorials
CODE: Functions, classes, modules, applications
RESEARCH: Data analysis, investigations, reports
CONTENT: Articles, marketing, social media
ANALYSIS: Business analysis, performance reports
DESIGN: Visual design, component libraries
OTHER: Custom domains
Basic: Fundamental functionality with core features
Intermediate: Enhanced features with improved user experience
Advanced: Sophisticated implementation with innovative approaches
Revolutionary: Cutting-edge concepts pushing domain boundaries
SINGLE: Generate one iteration
BATCH: Generate specific number of iterations in coordinated batches
INFINITE: Continuous generation until context limits with progressive sophistication
Parallel Execution: Multiple agents working simultaneously with unique assignments
Innovation Assignment: Each agent gets distinct innovation dimension to explore
Context Management: Intelligent context usage tracking and optimization
Quality Assurance: Real-time validation and quality scoring
Uniqueness Enforcement: Prevention of duplicate concepts across parallel streams
Wave 1: Basic functional implementations
Wave 2: Enhanced features and user experience
Wave 3: Advanced concepts and innovative approaches
Wave N: Revolutionary paradigm-defining implementations// Detect when parallel generation is needed
if (taskRequiresParallelGeneration(task)) {
const specification = generateSpecificationFromTask(task);
const result = await mcpClient.callTool('infinite_orchestrate', {
specification,
outputDirectory: task.outputDirectory,
mode: {
type: 'BATCH',
count: task.iterationCount,
batchSize: 5
}
});
return integrateResultsIntoTask(result, task);
}// Define custom domain specification
const customSpec: UniversalSpecification = {
name: "Custom Data Analysis",
domain: {
category: "ANALYSIS",
subcategory: "Financial Reports",
targetAudience: "Business Analysts",
complexity: "COMPLEX"
},
innovationDimensions: [
"visualization_techniques",
"data_insights",
"predictive_modeling",
"business_impact"
],
// ... rest of specification
};Real-time context usage tracking
Graceful shutdown when approaching limits
Wave-based context optimization
Agent-specific context allocation
Functionality compliance scoring
Innovation uniqueness measurement
Domain-specific quality validation
Progressive improvement tracking
Agent coordination efficiency
Wave execution timing
Resource utilization optimization
Failure rate and recovery metrics
Generate diverse component variations
Explore different interaction patterns
Create comprehensive design systems
Test accessibility approaches
Create multi-perspective documentation
Generate comprehensive examples
Explore different explanation styles
Develop interactive documentation
Generate alternative implementations
Explore architectural patterns
Create comprehensive test suites
Develop optimization variations
Explore multiple analysis angles
Generate diverse visualization approaches
Create comprehensive reports
Investigate different methodologies
Universal specification system
Wave-based generation framework
Agent coordination system
Context management
Machine learning-based quality prediction
Dynamic specification evolution
Cross-domain knowledge transfer
Performance optimization
IDE extensions and plugins
Cloud deployment options
Collaboration features
Marketplace for specifications
Contributions are welcome! Please read our contributing guidelines and submit pull requests for any improvements.
MIT License - see LICENSE file for details.
Based on Disler's Infinite Agentic Loop concept with universal goal-agnostic adaptations for maximum reusability and flexibility.
Coordinate parallel agent execution with sophisticated assignment
| Name | Required | Description | Default |
|---|---|---|---|
| assignments | Yes | Array of agent assignments | |
| innovationDimensions | Yes | Available innovation dimensions | |
| contextMonitor | Yes | Context monitoring configuration |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It vaguely mentions 'sophisticated assignment' but does not explain what this entails—such as whether it modifies agent states, handles errors, or has side effects. For a coordination tool with no annotation coverage, this lack of detail is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded with the core function. It avoids unnecessary words and gets straight to the point, though it could be more specific to enhance clarity without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by coordinating parallel agents and the lack of annotations and output schema, the description is incomplete. It does not cover behavioral aspects, return values, or error handling, leaving the agent with insufficient information to use the tool effectively in a multi-agent context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond what the input schema provides. With 100% schema description coverage, the schema already documents all three parameters (assignments, innovationDimensions, contextMonitor). The description does not elaborate on their roles or interactions, so it meets the baseline of 3 without compensating for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool coordinates parallel agent execution with sophisticated assignment, which provides a vague purpose. It mentions a verb ('coordinate') and resource ('parallel agent execution'), but lacks specificity about what coordination entails or how it differs from sibling tools like 'infinite_orchestrate' or 'wave_plan'. This makes it unclear for precise agent selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, and it fails to differentiate from sibling tools such as 'context_monitor' or 'infinite_orchestrate'. This leaves the agent without direction on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Monitor context capacity and manage graceful shutdown
| Name | Required | Description | Default |
|---|---|---|---|
| waveId | Yes | Wave ID to monitor | |
| capacityThreshold | Yes | Threshold for triggering graceful shutdown (0.0-1.0) | |
| gracefulShutdown | Yes | Whether to enable graceful shutdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'graceful shutdown' which implies a potentially destructive operation, but doesn't clarify what gets shut down, whether it's reversible, or any rate limits or authentication requirements. This is inadequate for a tool that appears to manage system state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that clearly states the tool's purpose. It's appropriately sized and front-loaded with the core functionality, though it could potentially benefit from more detail given the complexity implied by the tool name and parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and parameters suggesting system management capabilities, the description is insufficient. It doesn't explain what 'context capacity' means, what happens during graceful shutdown, or what the tool returns. The agent would need to guess about important behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing clear documentation for all three parameters. The description adds no additional parameter semantics beyond what's already in the schema, so it meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as monitoring context capacity and managing graceful shutdown, which is clear but somewhat vague. It specifies the verb 'monitor' and resource 'context capacity' but doesn't clearly distinguish this from sibling tools like 'agent_coordinate' or 'wave_plan', leaving ambiguity about its specific role in the system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions monitoring and shutdown management but doesn't specify prerequisites, exclusions, or how it relates to sibling tools. This leaves the agent without context for appropriate tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Orchestrate infinite agentic loop generation with universal specifications
| Name | Required | Description | Default |
|---|---|---|---|
| specification | Yes | Universal specification defining generation parameters | |
| outputDirectory | Yes | Directory where iterations will be generated | |
| mode | Yes | Orchestration mode configuration | |
| config | No | Optional orchestration configuration |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'orchestrate' implies coordination/management, it doesn't reveal whether this is a read-only or mutation operation, what permissions might be required, whether it runs continuously or in batches, what happens to existing files in the output directory, or any rate limits/constraints. The description mentions 'infinite' and 'loop generation' but doesn't clarify the operational behavior beyond those vague terms.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point. It's appropriately sized for a tool with this complexity level, though it could be more front-loaded with concrete purpose rather than abstract terminology. There's no wasted verbiage or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent complexity (4 parameters with nested objects, no output schema, no annotations), the description is inadequate. It doesn't explain what 'generations' are produced, what format they take, how the infinite loop is controlled or monitored, or what the expected outcomes are. For a tool that seems to manage potentially continuous processes with configuration options, more operational context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain what 'universal specifications' means for the specification parameter, how the output directory is used, or what the different mode types imply. With complete schema coverage, the baseline is 3 even without description enhancement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Orchestrate infinite agentic loop generation with universal specifications' which is somewhat tautological with the tool name 'infinite_orchestrate' and uses vague terms like 'agentic loop generation' and 'universal specifications' without concrete explanation. It doesn't clearly distinguish what this tool does versus siblings like 'agent_coordinate' or 'wave_plan' - all seem related to orchestration/coordination. The purpose is implied but not specific enough for clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. With siblings like 'agent_coordinate', 'context_monitor', 'spec_validate', and 'wave_plan', there's no indication of how this tool's 'infinite orchestration' differs from those coordination/monitoring/planning tools. The description doesn't mention prerequisites, constraints, or appropriate contexts for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate and enhance user specifications for goal-agnostic generation
| Name | Required | Description | Default |
|---|---|---|---|
| userSpec | Yes | User-provided specification | |
| domain | Yes | Domain information | |
| outputRequirements | Yes | Output requirements |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It hints at validation and enhancement but doesn't explain what these entail—such as error handling, output format, or side effects. For a tool with three parameters and no output schema, this is insufficient to inform the agent about how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded and efficiently conveys the core purpose without unnecessary elaboration, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (three required parameters, nested objects, no output schema, and no annotations), the description is incomplete. It lacks details on behavior, output, or usage context, leaving significant gaps for the agent to understand how to effectively invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters with basic descriptions. The description adds no additional meaning about the parameters beyond what the schema provides, such as examples or constraints. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Validate and enhance user specifications for goal-agnostic generation' states a purpose but is vague. It mentions 'validate' and 'enhance' as verbs with 'user specifications' as the resource, but 'goal-agnostic generation' is ambiguous and doesn't clearly differentiate from sibling tools like 'agent_coordinate' or 'wave_plan'. It avoids tautology but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, and it doesn't reference sibling tools. This leaves the agent without direction on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plan a generation wave based on existing work and sophistication level
| Name | Required | Description | Default |
|---|---|---|---|
| existingWork | Yes | Array of existing iteration information | |
| sophisticationLevel | Yes | Target sophistication level for the wave | |
| targetCount | Yes | Number of iterations to plan for | |
| contextBudget | Yes | Available context budget for the wave |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool 'plans' a generation wave, implying it's a read-only planning operation, but doesn't clarify if it performs computations, makes recommendations, or has side effects like creating data. No information on permissions, rate limits, or error handling is included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, usage context, or output expectations. Given the complexity and lack of structured data, it should provide more guidance to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description mentions 'existing work and sophistication level' but doesn't add meaningful context beyond what the schema provides, such as examples or usage patterns. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'plan' and the resource 'generation wave', specifying it's based on existing work and sophistication level. However, it doesn't distinguish this tool from its siblings like 'agent_coordinate' or 'infinite_orchestrate', which might also involve planning or coordination aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'agent_coordinate' or 'context_monitor'. It mentions the inputs (existing work and sophistication level) but doesn't specify prerequisites, constraints, or appropriate contexts for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct aspect of agentic loop orchestration (coordination, monitoring, orchestration, validation, planning) with clear boundaries, though 'infinite_orchestrate' and 'wave_plan' could be mildly confused as both involve generation planning. Descriptions help differentiate them effectively.
Tools follow a consistent snake_case pattern with descriptive compound names (e.g., agent_coordinate, context_monitor). While all use noun-based structures, there is minor deviation with 'spec_validate' using a verb-noun combination, but overall naming is highly readable and predictable.
With 5 tools, this server is well-scoped for its purpose of infinite loop orchestration. Each tool appears to serve a specific, necessary function without redundancy, fitting the typical 3-15 range for a focused domain.
The toolset covers core lifecycle aspects of agentic loops: planning, validation, orchestration, coordination, and monitoring. A minor gap exists in direct execution or termination tools, but agents can likely work around this with the provided monitoring and orchestration capabilities.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-powered spec-to-task decomposition and execution orchestration for coding agents.
AI work orchestration for plans, tasks, teams, and coding-agent dispatch.
Build, validate, and deploy multi-agent AI solutions from any AI environment.
The AI orchestration agent for modern software teams.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/gptcompany/universal-infinite-loop-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
