Gradle Tomcat MCP Server
# Gradle Tomcat MCP Server
A Model Context Protocol (MCP) server for managing Gradle-based Tomcat applications with log querying capabilities.
## Features
- **Process Management**: Start, stop, restart, and monitor Tomcat processes via Gradle
- **Log Management**: Capture, store, and query application logs with filtering
- **Real-time Monitoring**: Stream logs and process status updates
- **MCP Integration**: Full integration with Claude and other MCP clients
## Installation
### Global Installation (Recommended)
```bash
npm install -g mcp-gradle-tomcat
```
### Local Installation
```bash
npm install mcp-gradle-tomcat
```
### From Source
```bash
git clone https://github.com/your-username/mcp-gradle-tomcat.git
cd mcp-gradle-tomcat
npm install
```
## Quick Start
### 1. Add to Claude Configuration
Add this to your Claude configuration file (`~/.claude/config.json`):
```json
{
"mcpServers": {
"gradle-tomcat": {
"command": "mcp-gradle-tomcat",
"env": {
"GRADLE_WORKING_DIR": "/path/to/your/gradle/project"
}
}
}
}
```
### 2. Use with Claude
Once configured, you can use these commands in Claude:
- **"Start Tomcat"** - Launches your Gradle application
- **"Stop Tomcat"** - Gracefully stops the running application
- **"Get Tomcat status"** - Shows process status and uptime
- **"Get recent logs"** - Retrieves application logs with filtering
- **"Restart Tomcat"** - Stops and starts the application
## Manual Usage
### Direct Execution
```bash
# Set your project directory
export GRADLE_WORKING_DIR="/path/to/your/gradle/project"
# Run the MCP server
mcp-gradle-tomcat
```
### Testing Tools
```bash
# Test individual tools
npm test
```
## Configuration
Configuration can be set via environment variables:
- `GRADLE_WORKING_DIR`: Working directory for Gradle commands (default: current directory)
- `GRADLE_COMMAND`: Gradle command to run (default: appRun)
- `TOMCAT_PORT`: Expected Tomcat port (default: 8080)
- `MAX_LOG_BUFFER_SIZE`: Maximum log entries in memory (default: 1000)
- `LOG_DIR`: Directory for log files (default: ./logs)
## Available Tools
### `start_tomcat`
Launch Tomcat via Gradle
- `gradle_command` (optional): Gradle command to run
- `working_directory` (optional): Working directory
### `stop_tomcat`
Terminate Tomcat process
- `force` (optional): Force termination with SIGKILL
### `restart_tomcat`
Stop and start Tomcat
- `force` (optional): Force termination during stop
- `gradle_command` (optional): Gradle command for restart
### `get_tomcat_status`
Check Tomcat process status
- No parameters
### `get_logs`
Retrieve log entries
- `lines` (optional): Number of recent log lines (default: 100)
- `level` (optional): Minimum log level (DEBUG, INFO, WARN, ERROR)
- `since` (optional): ISO 8601 timestamp to filter from
- `source` (optional): Filter by source (stdout, stderr)
### `clear_logs`
Clear log buffer and files
- `confirm` (required): Must be true to confirm
## Architecture
```
src/
├── server.js # Main MCP server
├── process-manager.js # Tomcat lifecycle management
├── log-manager.js # Log capture and querying
├── tools/ # MCP tool implementations
└── config.js # Configuration management
```
## License
MITTDQS
Scored across 6 tools
Each tool has a clearly distinct purpose targeting specific Tomcat management tasks: clearing logs, retrieving logs, checking status, restarting, starting, and stopping. No overlap exists between these functions, making tool selection straightforward for an agent.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., clear_logs, get_logs, restart_tomcat). The verbs are action-oriented and predictable, with no deviations in naming style across the set.
With 6 tools, the server is well-scoped for managing Tomcat via Gradle, covering essential lifecycle operations (start, stop, restart, status) and log handling. Each tool earns its place without being excessive or insufficient for the domain.
The tool set provides complete coverage for Tomcat management: it includes lifecycle control (start, stop, restart), status monitoring, and log operations (retrieve and clear). No obvious gaps exist for the stated purpose, enabling agents to handle typical workflows without dead ends.