MCP Playground
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., "@MCP Playgroundpropose a team of 5 for a new mobile app development project"
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.
MCP Playground
Requirements
Python 3.13
uv package manager
SQLite3
Related MCP server: DB MCP (HR CSV → SQLite)
Installation
Clone the repository
git clone <repository-url> cd mcp_playgroundInstall dependencies with uv
uv syncSetup the SQLite database
Create a new SQLite database file using the provided schema.
cd dbsqlite3 database.db < schema.sqlInsert dummy data into the database.
sqlite3 database.db < insert_data.sqlStart the venv (if you want to start the server manually)
source .venv/bin/activate
Usage
Starting the server
The server currently uses IO for communication. It is not meant to be started manually, instead it should be accessed through an MCP client.
Implemented Functions
The following functions are implemented in the server:
db_schema(resource)Returns the database schema by reading the
schema.sqlfile.
get_users(tool)Fetches a list of all user names from the
userstable in the database.
get_all_employee_profiles(tool)Retrieves all employee profiles
send_email(tool)Sends an email using mailtrap.
Requires API-key in .env file:
MAILTRAP_API_TOKEN=your_mailtrap_api_key
propose_team_for_project(prompt)Given a project description and team size, proposes a team of employees best suited for the project based on their skills and experience.
Integration with Claude Desktop as the MCP client
Add the following configuration to your MCP client (e.g., Claude Desktop):
Settings → Developer → Edit config →
claude_desktop_config.jsonmcpServers: The server name, in this casenot-solita-corp.command: The ABSOLUTE path to theuvexecutable on your system.args: The arguments to start the MCP server, including the ABSOLUTE path to themcp_playgrounddirectory.Note: Windows paths use backslashes (
\).
{
"mcpServers": {
"mcp_demo": {
"command": "/path/to/user/.local/bin/uv",
"args": [
"--directory",
"/path/to/user/mcp_playground",
"run",
"server.py"
]
}
}
}Available Tools
3 toolsget_all_employee_profilesD
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_usersD
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_emailD
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| subject | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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.
3 tool updates
v0.1.0- First observed
get_all_employee_profiles - First observed
get_users - First observed
send_email
TDQS
Scored across 3 tools
get_users and get_all_employee_profiles likely serve similar purposes, potentially causing confusion. Without descriptions, an agent may select the wrong tool.
All tools follow a verb_noun pattern (get_, send_), but the noun forms are inconsistent: 'users' versus 'all_employee_profiles' and 'email'.
With only 3 tools, the set is small but might be adequate for a simple playground. The count is borderline but not extreme.
Missing basic CRUD operations for users/employees (create, update, delete) and limited email functionality (only send). Significant gaps for a typical management domain.
Maintenance
Related MCP Connectors
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
- UnifAPIOAuthcom.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
- mcp-serverOAuthio.klokin
MCP server exposing klokin time-tracking operations (employees, time entries, stores) to AI clients.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceAn open-source MCP server that imports HR CSV data into an in-memory SQLite database for structured querying and metadata retrieval. It enables users to perform read-only SQL queries and structured searches on employee data through natural language.MIT
- AlicenseNot gradedqualityDmaintenanceThis MCP server imports HR CSV data into an in-memory SQLite database to enable structured querying and metadata retrieval. It provides tools for executing read-only SQL queries and searching employee records through a standardized JSON-RPC interface.MIT
- AlicenseNot gradedqualityDmaintenanceMCP server providing natural-language tools for managing and querying an employee database, including user CRUD, search, and statistics.MIT
- FlicenseNot gradedqualityCmaintenanceAn employee-analytics MCP server backed by SQLite that provides hand-written SQL queries for common analytics tasks like salary ranking and department statistics. It self-seeds sample data, enabling immediate testing of GROUP BY, window functions, NULL handling, and subqueries.-