Skip to main content
Glama

MCP Playground

Requirements

  • Python 3.13

  • uv package manager

  • SQLite3

Related MCP server: DB MCP (HR CSV → SQLite)

Installation

  1. Clone the repository

    git clone <repository-url>
    cd mcp_playground
  2. Install dependencies with uv

    uv sync
  3. Setup the SQLite database

    1. Create a new SQLite database file using the provided schema.

    cd db
    sqlite3 database.db < schema.sql
    1. Insert dummy data into the database.

    sqlite3 database.db < insert_data.sql
  4. Start 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:

  1. db_schema (resource)

    • Returns the database schema by reading the schema.sql file.

  2. get_users (tool)

    • Fetches a list of all user names from the users table in the database.

  3. get_all_employee_profiles (tool)

    • Retrieves all employee profiles

  4. send_email (tool)

    • Sends an email using mailtrap.

    • Requires API-key in .env file:

      MAILTRAP_API_TOKEN=your_mailtrap_api_key
  5. 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.json

  • mcpServers: The server name, in this case not-solita-corp.

  • command: The ABSOLUTE path to the uv executable on your system.

  • args: The arguments to start the MCP server, including the ABSOLUTE path to the mcp_playground directory.

  • 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 tools
get_all_employee_profilesD
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

D1/5.0
Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

D1/5.0
Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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
ParametersJSON Schema
NameRequiredDescriptionDefault
bodyYes
subjectYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

D1/5.0
Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

  1. 3 tool updatesv0.1.0
    • First observedget_all_employee_profiles
    • First observedget_users
    • First observedsend_email

TDQS

D1.6/5.0

Scored across 3 tools

Disambiguation3/5

get_users and get_all_employee_profiles likely serve similar purposes, potentially causing confusion. Without descriptions, an agent may select the wrong tool.

Naming Consistency4/5

All tools follow a verb_noun pattern (get_, send_), but the noun forms are inconsistent: 'users' versus 'all_employee_profiles' and 'email'.

Tool Count3/5

With only 3 tools, the set is small but might be adequate for a simple playground. The count is borderline but not extreme.

Completeness2/5

Missing basic CRUD operations for users/employees (create, update, delete) and limited email functionality (only send). Significant gaps for a typical management domain.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    An 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
  • A
    license
    Not graded
    quality
    D
    maintenance
    This 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
  • A
    license
    Not graded
    quality
    D
    maintenance
    MCP server providing natural-language tools for managing and querying an employee database, including user CRUD, search, and statistics.
    MIT
  • F
    license
    Not graded
    quality
    C
    maintenance
    An 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.
    -