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., "@jlbloomer-mcp-server show me my custom prompts for code review"
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.
Personal MCP (Model Context Protocol) server for AI assistant integration.
Python 3.14+
UV package manager
Related MCP server: Jilebi
# Clone and enter directory
cd /path/to/mcp
# Install dependencies
uv sync
# Run server
uv run jlbloomer-mcpAdd to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"jlbloomer-mcp": {
"command": "uv",
"args": ["--directory", "/path/to/mcp", "run", "jlbloomer-mcp"]
}
}
}claude mcp add jlbloomer-mcp -- uv --directory /path/to/mcp run jlbloomer-mcp# Install with dev dependencies
uv sync --extra dev
# Run tests
uv run pytest
# Lint
uv run ruff check .
# Type check
uv run mypy src/mcp/
├── src/mcp_server/ # Main package
│ ├── server.py # Entry point
│ ├── tools/ # MCP tools
│ ├── resources/ # MCP resources
│ └── prompts/ # MCP prompts
├── tests/ # Test suite
└── specs/ # Specification docsMIT
Execute a shell command (use with caution)
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | Command to execute | |
| timeout | No | Timeout in seconds |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 mentions 'use with caution' which hints at potential risks, but doesn't elaborate on what those risks are (e.g., destructive effects, security implications, side effects). No information about permissions, rate limits, or what happens during execution is provided.
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 - just 6 words total. It's front-loaded with the core purpose and includes a cautionary note. Every word earns its place with zero waste.
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 this is a potentially dangerous execution tool with no annotations but with an output schema, the description is minimal but covers the basics. The cautionary note addresses some risk awareness, but for a tool that executes arbitrary shell commands, more guidance about safety and behavior would be helpful despite the output schema existing.
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 thoroughly. The description doesn't add any additional meaning about the parameters beyond what's in the schema. Baseline 3 is appropriate when 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 clearly states the verb 'execute' and resource 'shell command', making the purpose specific and understandable. However, it doesn't differentiate from the sibling tool 'system_info', which appears to be a different type of operation (likely informational vs. execution).
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 includes a cautionary note 'use with caution', which provides some guidance about risk but doesn't specify when to use this tool versus alternatives or any prerequisites. There's no explicit when/when-not guidance or mention of the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current system information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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. 'Get' implies a read operation, but it doesn't specify what types of system information are included (e.g., OS, hardware, network), whether authentication is required, or any rate limits. The description is too vague about the tool's behavior beyond the basic read implication.
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 perfectly concise with a single, clear sentence that front-loads the essential information. There's no wasted language or unnecessary elaboration, making it easy for an agent to parse quickly.
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 simplicity (0 parameters, output schema exists), the description is minimally adequate. However, with no annotations and a sibling tool present, it should ideally provide more context about what distinguishes it from 'run_command' and what specific system information it returns. The existence of an output schema reduces the need to describe return values, but the description remains somewhat incomplete for optimal agent usage.
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 tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description doesn't need to compensate for any parameter gaps, and it appropriately doesn't mention parameters since none exist. A baseline of 4 is appropriate for zero-parameter tools.
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 tool's purpose with a specific verb ('Get') and resource ('current system information'), making it immediately understandable. However, it doesn't explicitly differentiate from its sibling tool 'run_command', which might also provide system-related information through command execution.
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 'run_command'. There's no mention of specific contexts, prerequisites, or exclusions that would help an agent choose between these sibling tools for system information retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0run_commandsystem_infoScored across 2 tools
The two tools have completely distinct purposes: run_command executes arbitrary shell commands, while system_info retrieves static system information. There is no overlap in functionality or potential for confusion between these tools.
Both tools follow a consistent verb_noun naming pattern: run_command and system_info. The naming is clear, predictable, and follows the same convention throughout the tool set.
With only 2 tools, this server feels quite thin for what appears to be a general system utility server. While both tools are useful, the scope seems limited and could benefit from additional utilities like file operations, process management, or network tools to better serve system administration tasks.
For a system utility server, there are significant gaps in coverage. Basic operations like file management (read/write/list), process monitoring, network diagnostics, or environment variable access are missing. The current tools provide only command execution and system info, leaving many common system tasks unaddressed.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
An MCP server that integrates with Discord to provide AI-powered features.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
