Skip to main content
Glama
muhammadyusuf-kurbonov

utel-mcp

by muhammadyusuf-kurbonov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

utel-mcp

An MCP server that wraps the UTEL IP-telephony REST API as MCP tools and documentation resources.
Lets LLM agents discover and call UTEL API endpoints with proper auth baked in.

Built with FastMCP (Python).

Prerequisites

  • Python 3.11+

  • uv — package manager

Related MCP server: OpenAPI MCP Server

Setup

uv sync

Configuration

The server is configured through environment variables (no .env file is loaded automatically):

Variable

Required

Description

UTEL_API_BASE_URL

Yes

Base URL of the UTEL API instance (e.g. https://api.cc999.utel.uz/api/v1)

HTTP_BEARER_TOKEN

No

Sets an Authorization: Bearer <token> header on every request

MCP_DEBUG

No

Set to "true" to log full request payloads to /tmp/mcp_debug.log

Usage

uv run utel-mcp

This starts the MCP server on stdio transport — it communicates over standard input/output.
Configure your MCP host (Claude Desktop, OpenCode, etc.) to launch it as a stdio subprocess.

Tools

send_request

Sends an authenticated HTTP request to the UTEL API. The path is joined with UTEL_API_BASE_URL.

Parameters:

Parameter

Type

Default

Description

path

string

—

API path, e.g. /ats/ps-user. Leading slash recommended.

method

string

"GET"

HTTP method (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS)

headers

object

null

Extra headers (merged on top of defaults)

json_data

object

null

JSON body

params

object

null

Query parameters

Returns: Status code + response body as a string.

Pre-configured headers on every request: Accept: application/json, Content-Type: application/json, and Authorization: Bearer <token> (if HTTP_BEARER_TOKEN is set).

Resources (Built-in API Documentation)

The server exposes the full UTEL API reference as MCP resources, so agents can look up endpoint details without leaving the conversation:

Resource

Description

utel://api

Index of all available documentation topics

utel://api/{topic}

Documentation for a specific topic

utel://api/reference

Full comprehensive API reference (all topics)

utel://skill

Same as reference — alias for agent skill context

Available topics: intro, auth, call-history, statistics, trunks, voice-messages, sip-users, ivr, groups, queues, time-rules, voicemail, smart-redirect, webhooks, extension-ranges.

Source Layout

src/utel_mcp/
├── __init__.py    ← MCP server instance, tool/resource registration, entry point
├── config.py      ← Environment variable loading
├── utils.py       ← Shared helpers (header construction)
├── handlers.py    ← Tool and resource implementations
└── docs.py        ← Inline API documentation data

Available Tools

1 tool
send_requestA

Send a request to the UTEL API. The path is joined with UTEL_API_BASE_URL (env var). Use a leading slash, e.g. /ats/ps-user. The Authorization: Bearer token (HTTP_BEARER_TOKEN) is already included on every request.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
methodNoGET
headersNo
json_dataNo
paramsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that the Authorization token is automatically included and that the path is joined with a base URL. This is essential behavioral info. However, it does not mention error handling, rate limits, or side effects, but for a generic HTTP request tool, the transparency is above average.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the main purpose, and every sentence adds value. There is no redundant or wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (5 params, 1 required, output schema present), the description covers the critical aspects: path format and authentication. It does not explain query parameters or error scenarios, but the output schema satisfies return value details. Overall, it is sufficiently complete for its complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It only adds meaning for the 'path' parameter (format and base URL) but does not elaborate on method, headers, json_data, or params beyond what the schema provides. The defaults and enums are in the schema, but additional semantics are missing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the purpose: 'Send a request to the UTEL API.' It specifies the verb ('send') and the resource ('UTEL API'), avoiding any tautology. The additional details about path joining and token inclusion further clarify the operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. While it gives technical usage instructions (path format, auth inclusion), it does not discuss appropriate contexts, exclusions, or comparisons with other tools.

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. 1 tool updatev0.1.0
    • First observedsend_request
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no potential for confusion between tools. The single tool has a distinct purpose: sending requests to the UTEL API.

Naming Consistency5/5

Only one tool exists, so naming consistency is not an issue. The name 'send_request' follows a verb_noun pattern.

Tool Count1/5

A single generic tool for an entire API surface is an extreme mismatch. The tool count is far too low for any non-trivial domain; it forces the agent to manage all API logic internally.

Completeness1/5

The single tool provides no specialized operations (e.g., CRUD, search), leaving agents to manually construct requests for every action. This is severely incomplete for a typical API interface.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • MCP API Server

    fikri2992
    A
    license
    A
    quality
    D
    maintenance
    A Model Context Protocol server that enables AI assistants to make HTTP requests (GET, POST, PUT, DELETE) to external APIs through standardized MCP tools.
    4
    2
    MIT

  • OpenAPI MCP Server

    luciVuc
    A
    license
    Not graded
    quality
    D
    maintenance
    A generic MCP server that dynamically converts OpenAPI-defined REST APIs into tools for LLMs like Claude. It supports multiple authentication methods and transport protocols, enabling seamless interaction with any OpenAPI-compliant API.
    8 npm
    MIT
  • VoIPbin MCP Server by voipbin

    VoIPbin MCP Serverofficial

    voipbin
    A
    license
    B
    quality
    C
    maintenance
    An MCP server that enables AI assistants to interact with the VoIPbin CPaaS platform, exposing tools for managing calls, flows, messaging, conferencing, and more.
    52
    1
    MIT

  • MCP API Requester

    yryuu
    F
    license
    A
    quality
    D
    maintenance
    An MCP server that enables LLMs to make arbitrary HTTP requests (GET, POST, PUT, DELETE, etc.) with custom headers, bodies, and cookies, supporting JSON and error handling.
    1
    2
    -