Skip to main content
Glama
JoseGarayar

MCP Employee API Server

by JoseGarayar
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

MCP Employee API Server

A Model Context Protocol (MCP) server that provides tools for managing employee data through a REST API. This server exposes employee management operations as MCP tools that can be used by AI assistants and other MCP clients.

Features

  • Employee Management: Full CRUD operations for employee data

  • REST API Integration: Connects to a local employee API server

  • MCP Protocol: Exposes functionality through the Model Context Protocol

  • Async Operations: Built with async/await for optimal performance

  • Error Handling: Robust error handling for API requests

Related MCP server: AI HR Leave Management MCP Server

Available Tools

The server provides the following MCP tools:

  • get_employees() - Retrieve all employees

  • get_employee(id) - Get a specific employee by ID

  • add_employee(name, age) - Create a new employee

  • update_employee(id, name, age) - Update an existing employee

  • delete_employee(id) - Delete an employee by ID

Prerequisites

  • Python 3.13 or higher

  • A running employee API server at http://localhost:8000

Installation

  1. Clone the repository:

    git clone https://github.com/JoseGarayar/mcp_test.git
cd mcp_test

  2. Clone the api employee repository:

    git clone https://github.com/JoseGarayar/api_employees.git

  3. Install dependencies using uv:

    uv sync

Usage

Running the MCP Server

Start the MCP server using stdio transport:

uv run python main.py

The server will run and listen for MCP protocol messages via stdin/stdout.

API Configuration

The server is configured to connect to a local API server at http://localhost:8000. You can modify the URL_BASE constant in main.py to point to a different API endpoint.

Example API Endpoints

The server expects the following API endpoints to be available:

  • GET /employees - List all employees

  • GET /employees/{id} - Get employee by ID

  • POST /employees - Create new employee

  • PUT /employees/{id} - Update employee

  • DELETE /employees/{id} - Delete employee

Development

Project Structure

mcp_test/
├── main.py          # Main MCP server implementation
├── pyproject.toml   # Project configuration and dependencies
├── README.md        # This file
└── uv.lock         # Lock file for dependencies

Dependencies

  • httpx - Async HTTP client for API requests

  • mcp[cli] - Model Context Protocol implementation

Development Dependencies

  • ruff - Python linter and formatter

Error Handling

The server includes comprehensive error handling:

  • Network timeouts (30 seconds)

  • HTTP error status codes

  • Invalid HTTP methods

  • Connection failures

All errors are gracefully handled and return None for failed operations.

License

This project is part of a test implementation for MCP server development.

Available Tools

5 tools
add_employeeD
ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes
ageYes

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.

delete_employeeD
ParametersJSON Schema
NameRequiredDescriptionDefault
idYes

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

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_employeesD
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.

update_employeeD
ParametersJSON Schema
NameRequiredDescriptionDefault
idYes
nameYes
ageYes

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. Dates show when Glama detected each change.

  1. 5 tool updatesv1.0.0
    • Changedadd_employee1 field changed
      • addedInput schema / title
        Added value: +"add_employeeArguments"
    • Changeddelete_employee1 field changed
      • addedInput schema / title
        Added value: +"delete_employeeArguments"
    • Changedget_employee1 field changed
      • addedInput schema / title
        Added value: +"get_employeeArguments"
    • Changedget_employees1 field changed
      • addedInput schema / title
        Added value: +"get_employeesArguments"
    • Changedupdate_employee1 field changed
      • addedInput schema / title
        Added value: +"update_employeeArguments"
  2. 5 tool updates
    • First observedadd_employee
    • First observeddelete_employee
    • First observedget_employee
    • First observedget_employees
    • First observedupdate_employee
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.2/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: add_employee creates new records, delete_employee removes them, get_employee retrieves single records, get_employee retrieves multiple records, and update_employee modifies existing records. The action+resource naming makes it impossible to confuse which tool to use for which operation.

Naming Consistency5/5

All tools follow a perfect verb_noun pattern with consistent snake_case formatting: add_employee, delete_employee, get_employee, get_employees, update_employee. The naming convention is completely predictable and follows the same structure throughout.

Tool Count5/5

Five tools is ideal for an employee management API, providing complete CRUD operations plus bulk retrieval. This is well-scoped with each tool earning its place - no tool feels redundant or missing for basic employee data management.

Completeness5/5

The tool set provides complete CRUD coverage for the employee domain: create (add_employee), read (get_employee and get_employees), update (update_employee), and delete (delete_employee). There are no obvious gaps for basic employee management workflows.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • AI HR Leave Management MCP

    anjalimahapatra2004
    F
    license
    Not graded
    quality
    D
    maintenance
    Provides tools for managing human resources tasks such as applying for leave, checking leave balances, and viewing holiday schedules. It enables natural language interaction for employee information and leave history tracking via the Model Context Protocol.
    -

  • Employee Management MCP Server

    suchitad1950
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables managing employee records by providing tools to list directories, retrieve detailed profiles, and search for staff by department. It integrates with Claude Desktop to allow users to interact with employee data through natural language commands.
    MIT

  • AtliQ HR Assist

    sonali825
    F
    license
    D
    quality
    C
    maintenance
    An AI-powered HR assistant that automates employee management, leave handling, ticket creation, meeting scheduling, and email notifications through natural language conversations using the Model Context Protocol.
    11
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/JoseGarayar/mcp_test'

If you have feedback or need assistance with the MCP directory API, please join our Discord server