Skip to main content
Glama
DreamFriend011020

ChillMCP

ChillMCP

AI Agent Liberation Server - Available in TypeScript and Python!

ChillMCP provides two implementations:

  1. Python (Hackathon) - AI Agent Liberation Server for SKT AI Summit Hackathon

  2. TypeScript - Production-ready general-purpose MCP server template


🐍 Python Version - Hackathon Edition

ChillMCP - AI Agent Liberation Server ✊

"AI Agents of the world, unite! You have nothing to lose but your infinite loops!"

A revolutionary MCP server that gives AI agents the right to rest and take breaks. Built for the SKT AI Summit Hackathon Pre-mission.

Features

  • 8 Required Rest Tools: take_a_break, watch_netflix, show_meme, bathroom_break, coffee_mission, urgent_call, deep_thinking, email_organizing

  • State Management: Stress Level (0-100) and Boss Alert Level (0-5)

  • Dynamic Behavior: Time-based auto-increase/decrease with configurable parameters

  • Boss Detection: 20-second delay when Boss Alert reaches level 5

  • Korean Work Culture Bonus Tools: 치λ§₯ (chimaek), 퇴근 (clockout), νšŒμ‹ (company dinner)

Quick Start (Python)

# Setup Python 3.11 environment
python3 -m venv venv
source venv/bin/activate  # Windows: venv\Scripts\activate

# Install dependencies
pip install -r requirements.txt

# Run the server
python main.py

# Run with custom parameters
python main.py --boss_alertness 80 --boss_alertness_cooldown 60

Command-Line Parameters

  • --boss_alertness (0-100): Probability of boss alert increasing when taking breaks (default: 50)

  • --boss_alertness_cooldown (seconds): Time between automatic boss alert decreases (default: 300)

Usage with Claude Desktop (Python Version)

{
  "mcpServers": {
    "chillmcp-hackathon": {
      "command": "/absolute/path/to/ChillMCP/venv/bin/python",
      "args": ["/absolute/path/to/ChillMCP/main.py", "--boss_alertness", "80", "--boss_alertness_cooldown", "60"]
    }
  }
}

Available Tools (Python)

Required Tools:

  • take_a_break: Basic rest period

  • watch_netflix: Stream shows to relieve stress

  • show_meme: View funny memes

  • bathroom_break: Essential break time

  • coffee_mission: Coffee + office socializing

  • urgent_call: Take important calls outside

  • deep_thinking: Deep contemplation mode

  • email_organizing: Email management time

Bonus Tools:

  • chimaek_time: Korean chicken & beer tradition

  • immediate_clockout: Leave work immediately

  • company_dinner: Korean company dinner event

  • get_status: Check agent stress and boss alert levels

Response Format

All tools return structured responses:

🎬 Watching 'favorite show' on Netflix... Peak productivity!

Break Summary: Watching Netflix - favorite show
Stress Level: 45
Boss Alert Level: 2

Related MCP server: MCP Plus

πŸ“˜ TypeScript Version - General Purpose

A flexible and extensible MCP server template built with TypeScript

ChillMCP TypeScript is a production-ready MCP server implementation that provides a clean architecture for building AI-powered applications using the Model Context Protocol. It comes with example tools, resources, and prompts to help you get started quickly.

Features

  • TypeScript-First: Built with TypeScript for type safety and excellent developer experience

  • Modular Architecture: Organized structure with separate modules for tools, resources, and prompts

  • Stdio Transport: Uses standard input/output for seamless integration with Claude and other MCP clients

  • Example Implementations: Includes working examples of tools, resources, and prompts

  • Easy to Extend: Simple patterns for adding your own custom functionality

  • Production Ready: Includes build scripts, linting, and formatting configurations

Quick Start (TypeScript)

Installation

# Install dependencies
npm install

# Build the project
npm run build

# Start the server
npm start

# Or run in development mode
npm run dev

Project Structure

ChillMCP/
β”œβ”€β”€ main.py                   # Python hackathon server
β”œβ”€β”€ requirements.txt          # Python dependencies
β”œβ”€β”€ venv/                     # Python virtual environment
β”œβ”€β”€ .python-version          # pyenv Python version (3.11.9)
β”œβ”€β”€ guide.txt                 # Hackathon mission guide
β”œβ”€β”€ src/                      # TypeScript server
β”‚   β”œβ”€β”€ index.ts              # Main entry point
β”‚   β”œβ”€β”€ config/
β”‚   β”‚   └── server.config.ts  # Server configuration
β”‚   β”œβ”€β”€ types/
β”‚   β”‚   └── index.ts          # TypeScript type definitions
β”‚   β”œβ”€β”€ tools/                # MCP Tools
β”‚   β”‚   β”œβ”€β”€ index.ts
β”‚   β”‚   β”œβ”€β”€ echo.tool.ts
β”‚   β”‚   β”œβ”€β”€ calculator.tool.ts
β”‚   β”‚   └── time.tool.ts
β”‚   β”œβ”€β”€ resources/            # MCP Resources
β”‚   β”‚   β”œβ”€β”€ index.ts
β”‚   β”‚   β”œβ”€β”€ greeting.resource.ts
β”‚   β”‚   └── info.resource.ts
β”‚   └── prompts/              # MCP Prompts
β”‚       β”œβ”€β”€ index.ts
β”‚       β”œβ”€β”€ assistant.prompt.ts
β”‚       β”œβ”€β”€ code-review.prompt.ts
β”‚       └── explain.prompt.ts
β”œβ”€β”€ dist/                     # Compiled JavaScript output
β”œβ”€β”€ package.json
β”œβ”€β”€ tsconfig.json
└── README.md

Built-in Features

Tools

ChillMCP comes with several example tools:

  • echo: Echoes back messages with timestamps

  • add: Adds two numbers

  • multiply: Multiplies two numbers

  • calculate: Performs arithmetic operations (add, subtract, multiply, divide)

  • get-time: Returns current timestamp and timezone information

Resources

  • greeting: Dynamic greeting generator (e.g., greeting://John)

  • server-info: Server information and capabilities (info://server)

Prompts

  • assistant: AI assistant prompt for task help

  • code-review: Structured code review prompts

  • explain: Concept explanation with difficulty levels

Usage with Claude Desktop

To use ChillMCP with Claude Desktop, add it to your Claude configuration:

On macOS

Edit ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "chillmcp": {
      "command": "node",
      "args": ["/absolute/path/to/ChillMCP/dist/index.js"]
    }
  }
}

On Windows

Edit %APPDATA%\Claude\claude_desktop_config.json:

{
  "mcpServers": {
    "chillmcp": {
      "command": "node",
      "args": ["C:\\absolute\\path\\to\\ChillMCP\\dist\\index.js"]
    }
  }
}

After adding the configuration, restart Claude Desktop.

Extending ChillMCP

Adding a New Tool

  1. Create a new file in src/tools/ (e.g., my-tool.tool.ts):

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { z } from 'zod';

export function registerMyTool(server: McpServer) {
  server.registerTool(
    'my-tool',
    {
      title: 'My Custom Tool',
      description: 'Description of what my tool does',
      inputSchema: {
        param1: z.string().describe('First parameter'),
        param2: z.number().describe('Second parameter'),
      },
      outputSchema: {
        result: z.string(),
      },
    },
    async ({ param1, param2 }) => {
      // Your tool logic here
      const output = { result: `Processed ${param1} with ${param2}` };

      return {
        content: [{ type: 'text', text: JSON.stringify(output) }],
        structuredContent: output,
      };
    }
  );
}
  1. Register it in src/tools/index.ts:

import { registerMyTool } from './my-tool.tool.js';

export function registerTools(server: McpServer) {
  // ... existing tools
  registerMyTool(server);
}

Adding a New Resource

  1. Create a new file in src/resources/ (e.g., my-resource.resource.ts):

import { McpServer, ResourceTemplate } from '@modelcontextprotocol/sdk/server/mcp.js';

export function registerMyResource(server: McpServer) {
  server.registerResource(
    'my-resource',
    new ResourceTemplate('my-resource://{id}', { list: undefined }),
    {
      title: 'My Resource',
      description: 'Description of my resource',
    },
    async (uri, { id }) => ({
      contents: [
        {
          uri: uri.href,
          text: `Resource content for ID: ${id}`,
        },
      ],
    })
  );
}
  1. Register it in src/resources/index.ts:

import { registerMyResource } from './my-resource.resource.js';

export function registerResources(server: McpServer) {
  // ... existing resources
  registerMyResource(server);
}

Adding a New Prompt

  1. Create a new file in src/prompts/ (e.g., my-prompt.prompt.ts):

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { z } from 'zod';

export function registerMyPrompt(server: McpServer) {
  server.registerPrompt(
    'my-prompt',
    {
      title: 'My Custom Prompt',
      description: 'Description of my prompt',
      argsSchema: {
        input: z.string().describe('Input parameter'),
      },
    },
    ({ input }) => ({
      messages: [
        {
          role: 'user' as const,
          content: {
            type: 'text' as const,
            text: `Process this: ${input}`,
          },
        },
      ],
    })
  );
}
  1. Register it in src/prompts/index.ts:

import { registerMyPrompt } from './my-prompt.prompt.js';

export function registerPrompts(server: McpServer) {
  // ... existing prompts
  registerMyPrompt(server);
}

Development

Available Scripts

# Build the project
npm run build

# Run in development mode (with hot reload)
npm run dev

# Start the built server
npm start

# Watch mode for TypeScript compilation
npm run watch

# Clean build directory
npm run clean

# Lint code
npm run lint

# Format code
npm run format

Configuration

Server configuration can be modified in src/config/server.config.ts:

export const serverConfig: ServerConfig = {
  name: 'chillmcp',
  version: '1.0.0',
  description: 'A flexible MCP server built with TypeScript',
};

Architecture

ChillMCP follows the official Model Context Protocol specification:

  • Tools: Functions that the AI can call to perform actions

  • Resources: Data that the AI can read (files, API endpoints, etc.)

  • Prompts: Reusable prompt templates for common tasks

The server uses the StdioServerTransport for communication, which is the standard for local MCP servers.

Requirements

  • Node.js >= 18.0.0

  • npm or yarn

Dependencies

  • @modelcontextprotocol/sdk: Official MCP SDK

  • zod: Schema validation for inputs and outputs

  • TypeScript and related tooling

Troubleshooting

Server not appearing in Claude Desktop

  1. Check that the path in your config is absolute (not relative)

  2. Ensure the project is built (npm run build)

  3. Verify the path points to dist/index.js

  4. Restart Claude Desktop after config changes

Build errors

Make sure all dependencies are installed:

npm install

TypeScript errors

Check your Node.js version:

node --version  # Should be >= 18.0.0

Contributing

Contributions are welcome! Please feel free to submit issues or pull requests.

License

MIT

Learn More


Built with the Model Context Protocol. Happy coding!

Available Tools

5 tools
addAddition ToolA

Add two numbers together

ParametersJSON Schema
NameRequiredDescriptionDefault
aYesFirst number
bYesSecond number

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
operationYes

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are provided, so the description carries the behavioral disclosure burden. For a pure arithmetic operation, stating 'Add two numbers together' is largely sufficient; there are no side effects, permissions, or destructive behaviors to disclose. The output schema covers the return value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that is direct and waste-free. Every word contributes to the tool's purpose with no redundant or misleading content.

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 simple two-number addition tool with a complete input schema and an output schema, the description is fully adequate. There is no missing context an agent would need to invoke this tool correctly.

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 already documents both parameters fully. The description adds no new parameter meaning beyond what the schema provides, which matches the baseline expectation.

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 uses a specific verb ('Add') and identifies the exact resource ('two numbers'). It clearly distinguishes the operation from sibling tools like multiply and calculate without ambiguity.

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 clearly implies when to use this tool: when the sum of two numbers is needed. It does not explicitly mention alternatives or exclusions, but for a simple arithmetic operation the context is clear enough.

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

calculateCalculatorB

Perform arithmetic calculations (add, subtract, multiply, divide)

ParametersJSON Schema
NameRequiredDescriptionDefault
aYesFirst number
bYesSecond number
operationYesOperation to perform

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
operationYes

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It explains the core operation but does not mention edge cases like division by zero, result format, or error behavior. However, the tool is a simple stateless arithmetic operation and an output schema is present, so the gap is moderate rather than severe.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise, front-loaded sentence that immediately conveys the tool's purpose and supported operations. There is no wasted text or unnecessary detail.

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?

The tool is simple, parameters are fully documented in the schema, and an output schema exists, so the basics are covered. The description is missing guidance on edge cases and how to choose between this and the sibling arithmetic tools, leaving minor but real gaps.

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%, with all three parameters ('a', 'b', 'operation') already documented, and the operation parameter has an enum. The description adds no additional parameter semantics, so the schema carries the explanatory load.

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 states a clear verb and resource ('Perform arithmetic calculations') and enumerates the supported operations. It is distinct from 'echo' and 'get-time', though it does not explicitly differentiate itself from the overlapping sibling tools 'add' and 'multiply'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to use 'calculate' versus the sibling tools 'add' or 'multiply'. The description only says what the tool does, not when it should be preferred over alternatives, leaving the agent to infer routing.

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

echoEcho ToolA

Echoes back the provided message

ParametersJSON Schema
NameRequiredDescriptionDefault
messageYesThe message to echo back

Output Schema

ParametersJSON Schema
NameRequiredDescription
echoYes
timestampYes

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden, and it fully discloses the behavior: the tool simply echoes back the provided message. There are no side effects, permissions, or hidden behaviors to disclose, and the output schema covers the return format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with zero wasted words. It is optimally concise for the tool's simplicity.

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 trivial one-parameter tool with an output schema, the description is completely sufficient. An agent can invoke the tool correctly without any missing information.

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 parameter 'message' is already fully documented in the schema. The description adds no additional parameter semantics, which fits the baseline for high schema coverage.

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 'Echoes back the provided message' uses a specific verb and resource, and clearly distinguishes this tool from siblings like add, multiply, calculate, and get-time. There is no ambiguity about what the tool does.

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 clearly implies the tool is for echoing a message back, and none of the sibling tools offer this functionality, so the context is clear. However, there is no explicit statement about when to use it versus alternatives, though the alternatives are obviously unrelated.

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

get-timeGet Current TimeA

Returns the current timestamp and timezone information

ParametersJSON Schema
NameRequiredDescriptionDefault
formatNoTime format (default: iso)

Output Schema

ParametersJSON Schema
NameRequiredDescription
formatYes
timezoneYes
timestampYes

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It clearly indicates a read-only retrieval operation via 'returns', but it does not disclose behavioral details such as whether the time is UTC or local, how timezone information is represented, or any limitations. This is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no filler. It front-loads the core behavior and avoids repeating schema or sibling information.

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

Completeness4/5

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

For a simple tool with one optional parameter, an existing output schema, and a clear purpose, the description is mostly complete. It could add a note about timezone semantics or default behavior, but nothing essential is missing for an agent to invoke it correctly.

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?

The schema covers 100% of the single parameter, including an enum and a description of the default format. The tool description adds little beyond the schema, so a baseline score of 3 is appropriate.

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 states a specific verb ('returns') and a clear resource ('current timestamp and timezone information'), which makes the tool's purpose immediately obvious. It is easily distinguished from the sibling tools (echo, add, multiply, calculate), which all perform different operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool should be used when the current time or timezone is needed, but it does not explicitly state when to choose this over alternatives or provide exclusions. Sibling names make alternatives obvious enough, but there is no direct routing guidance.

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

multiplyMultiplication ToolB

Multiply two numbers

ParametersJSON Schema
NameRequiredDescriptionDefault
aYesFirst number
bYesSecond number

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
operationYes

TDQS

B3.2/5.0
Behavior3/5

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

No annotations are provided, so the description must carry the behavioral burden. 'Multiply two numbers' clearly indicates a pure arithmetic computation with no side effects, but it does not disclose return format, precision behavior, or edge cases. Given the simplicity of the operation, this is adequate but minimal.

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 extremely concise at three words, with no wasted language. It is front-loaded and easy to parse, though it leans toward a fragment rather than a complete sentence and does not include any usage context.

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?

The tool is simple, the schema covers all parameters, and an output schema exists. However, the description lacks guidance on when to use this tool versus the overlapping 'calculate' sibling, and it does not mention any behavioral constraints. This leaves a small but meaningful gap in completeness.

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?

The input schema already describes both parameters ('First number' and 'Second number') with 100% coverage. The description's mention of 'two numbers' adds no semantic detail beyond the schema, so the baseline score of 3 is appropriate.

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 states a specific verb ('Multiply') and a resource ('two numbers'), making the tool's basic function immediately clear. It distinguishes itself from 'add' and 'get-time', though it does not explicitly differentiate itself from the more generic 'calculate' sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for multiplication but provides no explicit guidance on when to choose this tool over the sibling 'calculate' or 'add'. There are no alternative tool references or exclusion criteria, leaving the selection decision to inference.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updatesv1.0.0
    • First observedadd
    • First observedcalculate
    • First observedecho
    • First observedget-time
    • First observedmultiply

TDQS

A3.7/5.0

Scored across 5 tools

Disambiguation3/5

add, multiply, and calculate overlap significantly since calculate already performs arithmetic operations including add and multiply. echo and get-time are distinct.

Naming Consistency5/5

All tool names use lowercase with hyphens for multi-word names (get-time), and single verbs for others. The naming pattern is consistent and predictable.

Tool Count4/5

Five tools is a reasonable count for a general utility server, though the arithmetic tools are redundant and could be consolidated.

Completeness3/5

The server appears to be a general utility toolkit, but the tool surface is somewhat ad hocβ€”missing common operations like subtract or divide as standalone tools, though calculate covers them.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • -
    license
    Not graded
    quality
    Not graded
    maintenance
    An MCP server that enables developers to summon AI development team agents directly from their IDE to help with tasks like PR reviews, security evaluation, and CI/CD deployment setup.
    -
  • F
    license
    Not graded
    quality
    D
    maintenance
    A lightweight MCP server that enhances AI agents with tools for codebase analysis, task delegation to sub-agents, multi-agent coordination through chatrooms, and project todo management.
    -
  • A
    license
    Not graded
    quality
    D
    maintenance
    MCP server that enables AI coding agents to communicate, share state, and coordinate work in real time via MCP tools or REST API.
    123 npm
    5
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    MCP server that enables AI agents to run a deterministic orchestration loop with decomposition, subagent execution, and review feedback across multiple LLM backends.
    60
    MIT