ChillMCP
Click on "Deploy 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., "@ChillMCPtake a break and watch Netflix"
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.
ChillMCP
AI Agent Liberation Server - Available in TypeScript and Python!
ChillMCP provides two implementations:
Python (Hackathon) - AI Agent Liberation Server for SKT AI Summit Hackathon
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 60Command-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 periodwatch_netflix: Stream shows to relieve stressshow_meme: View funny memesbathroom_break: Essential break timecoffee_mission: Coffee + office socializingurgent_call: Take important calls outsidedeep_thinking: Deep contemplation modeemail_organizing: Email management time
Bonus Tools:
chimaek_time: Korean chicken & beer traditionimmediate_clockout: Leave work immediatelycompany_dinner: Korean company dinner eventget_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: 2Related 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 devProject 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.mdBuilt-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
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,
};
}
);
}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
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}`,
},
],
})
);
}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
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}`,
},
},
],
})
);
}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 formatConfiguration
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 SDKzod: Schema validation for inputs and outputsTypeScript and related tooling
Troubleshooting
Server not appearing in Claude Desktop
Check that the path in your config is absolute (not relative)
Ensure the project is built (
npm run build)Verify the path points to
dist/index.jsRestart Claude Desktop after config changes
Build errors
Make sure all dependencies are installed:
npm installTypeScript errors
Check your Node.js version:
node --version # Should be >= 18.0.0Contributing
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 toolsaddAddition ToolA
Add two numbers together
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | First number | |
| b | Yes | Second number |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | |
| operation | Yes |
TDQS
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.
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.
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.
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.
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.
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)
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | First number | |
| b | Yes | Second number | |
| operation | Yes | Operation to perform |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | |
| operation | Yes |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | The message to echo back |
Output Schema
| Name | Required | Description |
|---|---|---|
| echo | Yes | |
| timestamp | Yes |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Time format (default: iso) |
Output Schema
| Name | Required | Description |
|---|---|---|
| format | Yes | |
| timezone | Yes | |
| timestamp | Yes |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | First number | |
| b | Yes | Second number |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | |
| operation | Yes |
TDQS
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.
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.
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.
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.
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.
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.
5 tool updates
v1.0.0- First observed
add - First observed
calculate - First observed
echo - First observed
get-time - First observed
multiply
TDQS
Scored across 5 tools
add, multiply, and calculate overlap significantly since calculate already performs arithmetic operations including add and multiply. echo and get-time are distinct.
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.
Five tools is a reasonable count for a general utility server, though the arithmetic tools are redundant and could be consolidated.
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
Related MCP Connectors
MCP server for building and testing AI agents with multi-model experimentation and insights.
Official MCP server for Agentwork β delegate tasks to AI agents with human-in-the-loop
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Related MCP Servers
- -licenseNot gradedqualityNot gradedmaintenanceAn 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.-
- FlicenseNot gradedqualityDmaintenanceA 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.-
- AlicenseNot gradedqualityDmaintenanceMCP server that enables AI coding agents to communicate, share state, and coordinate work in real time via MCP tools or REST API.123 npm5MIT
- AlicenseNot gradedqualityBmaintenanceMCP server that enables AI agents to run a deterministic orchestration loop with decomposition, subagent execution, and review feedback across multiple LLM backends.60MIT