What can you do with this server?

The Utility MCP Server provides AI assistants with tools for time management, data analysis, and observability integration. Time Management Tools * get_current_time: Retrieve the current time in any timezone (e.g., Asia/Shanghai, UTC, America/New_York), returned as YYYY-MM-DD HH:MM:SS timezone * get_timestamp: Get the current Unix timestamp in seconds (timezone-independent) * format_timestamp: Convert a Unix timestamp to a human-readable YYYY-MM-DD HH:MM:SS timezone string in a specified timezone ChatBI Data Analysis Tools * schema_search: Search project schemas using vector recall and keyword retrieval (with stages: tokenization, embedding, vector search, keyword search, fusion) * execute_sql: Execute read-only PostgreSQL queries and return JSON results (with SQL Guardrail validation) Observability Integration * Automatically logs tool usage to Langfuse for end-to-end tracing with nested stage logging * Propagates tracing context (traceparent headers) from upstream services like ChatBI Deployment & Configuration * Runs in local (stdio) or remote (Streamable HTTP/SSE) modes * Supports Docker/Docker Compose deployment * Compatible with Cursor, Claude Desktop, and ChatBI/LangChain4j clients * Health check endpoint at /health; configurable via environment variables

Which integrations are available for this server?

Provides capabilities to execute read-only PostgreSQL queries and perform schema searches using vector recall and keyword retrieval.

How do I use Utility MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Utility MCP Server What is the current time in Tokyo?" 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.

Utility MCP Server

by Love-Gwen2025

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

MCP Server - 通用功能服务器

一个基于 Model Context Protocol (MCP) 的通用功能服务器，为 AI 提供扩展能力。

支持 本地模式 (stdio) 与 远程模式 (Streamable HTTP / SSE) 双模式运行，并可将 ChatBI -> MCP -> Langfuse 的观测链路串起来。

✨ 功能

🕐 时间工具

工具	描述
`get_current_time`	获取指定时区的当前时间
`get_timestamp`	获取当前 Unix 时间戳
`format_timestamp`	将时间戳转换为可读格式

📊 ChatBI 数据分析工具

工具	描述
`schema_search`	基于向量召回 + 关键词检索返回项目相关 Schema
`execute_sql`	执行只读 PostgreSQL 查询并返回 JSON 结果

🔭 Langfuse 链路观测

schema_search 会记录嵌套阶段：分词、Embedding、向量检索、关键词检索、融合裁剪。
execute_sql 会记录嵌套阶段：SQL Guardrail 校验、SQL 执行。
当上游 ChatBI 通过 traceparent 和 x-chatbi-* 头透传上下文时，MCP 工具观测会自动挂到同一条 Langfuse Trace 下。

Related MCP server: Time

🚀 快速开始

安装依赖

uv sync

本地模式运行

uv run mcp-server

远程模式运行（默认推荐）

uv run mcp-server --remote --transport streamable-http --port 8000

启动后可访问：

MCP: http://localhost:8000/mcp
Health: http://localhost:8000/health
SSE 兼容端点: http://localhost:8000/sse

SSE 兼容模式

uv run mcp-server --remote --transport sse --port 8000

🔌 客户端集成

本地模式配置

适用于 Cursor / Claude Desktop：

{
  "mcpServers": {
    "utility-server": {
      "command": "uv",
      "args": ["--directory", "/path/to/mcp-server", "run", "mcp-server"]
    }
  }
}

远程模式配置

ChatBI / LangChain4j

直接连接 Streamable HTTP 端点：

http://your-server:8000/mcp

兼容 `mcp-remote` 的 SSE 客户端

{
  "mcpServers": {
    "utility-server": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "http://your-server:8000/sse"]
    }
  }
}

🐳 Docker 部署

使用 Docker Compose（推荐）

docker compose up -d

docker compose logs -f

docker compose down

手动 Docker 命令

docker build -t mcp-server .

docker run -d -p 8000:8000 --name mcp-server mcp-server

docker run -d -p 9000:9000 -e PORT=9000 --name mcp-server mcp-server

🔐 Langfuse 配置

在 .env 中配置：

LANGFUSE_ENABLED=true
LANGFUSE_HOST=https://cloud.langfuse.com
LANGFUSE_PUBLIC_KEY=pk-lf-xxxx
LANGFUSE_SECRET_KEY=sk-lf-xxxx
LANGFUSE_ENVIRONMENT=production
MCP_SERVER_RELEASE=2026.03.09

如果未配置 Langfuse 凭证，服务仍可正常提供 MCP 工具，只是不会上报 tracing 数据。

🧪 开发测试

uv run mcp dev src/mcp_server/server.py
uv run mcp-server --help

📖 架构说明

ChatBI Java Service
    |
    |  traceparent + x-chatbi-* headers
    v
External MCP Server (/mcp)
    |
    |-- schema_search
    |     |-- tokenize
    |     |-- embedding
    |     |-- vector_search
    |     |-- keyword_search
    |     `-- fusion
    |
    `-- execute_sql
          |-- validate
          `-- query

All observations -> Langfuse

📄 许可证

MIT

Available Tools

3 tools

format_timestampA

将Unix时间戳转换为指定时区的可读时间格式

Args:
    timestamp: Unix时间戳（秒）
    timezone: 目标时区名称，默认为中国标准时间

Returns:
    格式化的时间字符串，格式为: YYYY-MM-DD HH:MM:SS 时区

Raises:
    ValueError: 当时区名称无效或时间戳不合法时

ParametersJSON Schema

Name	Required	Description	Default
`timestamp`	Yes
`timezone`	No		Asia/Shanghai

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it converts timestamps, has a default timezone ('Asia/Shanghai'), specifies the return format ('YYYY-MM-DD HH:MM:SS 时区'), and mentions error conditions ('Raises: ValueError'). This adds valuable context beyond the input schema, though it doesn't cover aspects like rate limits or authentication needs.

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 appropriately sized and front-loaded, with the core purpose stated first, followed by structured sections for Args, Returns, and Raises. Every sentence earns its place by providing essential information without redundancy, making it efficient and easy to parse.

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

Completeness5/5

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

Given the tool's low complexity, no annotations, and an output schema (implied by 'Returns'), the description is complete enough. It covers the purpose, parameters, return format, and error handling, providing all necessary context for an agent to use the tool correctly without needing additional explanations.

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

Parameters5/5

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

The description adds significant meaning beyond the input schema, which has 0% schema description coverage. It explains that 'timestamp' is a Unix timestamp in seconds and 'timezone' is a target timezone name with a default of '中国标准时间' (mapped to 'Asia/Shanghai' in the schema). This compensates fully for the schema's lack of descriptions, providing clear semantics for both parameters.

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 tool's purpose with specific verbs ('将Unix时间戳转换为指定时区的可读时间格式') and distinguishes it from siblings like 'get_current_time' and 'get_timestamp' by focusing on conversion rather than retrieval. It explicitly mentions the resource (Unix timestamp) and transformation (to readable time format).

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

Usage Guidelines4/5

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

The description provides clear context for when to use this tool (converting Unix timestamps to readable time in a specific timezone) but does not explicitly state when not to use it or name alternatives. It implies usage for timestamp formatting needs, though lacks explicit exclusions or comparison with sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_current_timeA

获取指定时区的当前时间

当AI需要知道当前时间时可以调用此工具。
支持世界各地的时区，默认使用中国标准时间。

Args:
    timezone: 时区名称，常用时区包括:
        - Asia/Shanghai (中国标准时间)
        - UTC (协调世界时)
        - America/New_York (美国东部时间)
        - Europe/London (英国时间)
        - Asia/Tokyo (日本时间)

Returns:
    格式化的当前时间字符串，格式为: YYYY-MM-DD HH:MM:SS 时区

Raises:
    ValueError: 当提供的时区名称无效时

ParametersJSON Schema

Name	Required	Description	Default
`timezone`	No		Asia/Shanghai

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior4/5

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

With no annotations provided, the description carries full burden and does well: it discloses the default timezone behavior, mentions worldwide timezone support, describes the return format, and specifies error conditions (ValueError for invalid timezone). It doesn't mention rate limits or authentication needs, but those are less critical for a time lookup tool.

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 well-structured with clear sections (purpose, usage, Args, Returns, Raises), front-loads the core functionality, and every sentence adds value. No wasted words while maintaining completeness.

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

Completeness5/5

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

Given the tool's low complexity (single optional parameter), no annotations, but having an output schema, the description is complete: it explains purpose, usage, parameter semantics, return format, and error conditions. The output schema existence means the description doesn't need to detail return structure, and it appropriately focuses on semantic context.

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

Parameters5/5

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

The input schema has 0% description coverage and only shows a string parameter named 'timezone'. The description compensates fully by explaining what the parameter means ('时区名称'), providing concrete examples of common timezones with their human-readable names, and mentioning the default value. This adds significant value beyond the bare schema.

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 tool's purpose with specific verb ('获取') and resource ('当前时间'), and distinguishes it from siblings by specifying it's for current time (not formatting or getting timestamps). It explicitly mentions '指定时区' (specified timezone), making the scope clear.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use ('当AI需要知道当前时间时可以调用此工具') and includes a default behavior ('默认使用中国标准时间'). It distinguishes from siblings by focusing on current time rather than timestamp manipulation or formatting.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_timestampA

获取当前Unix时间戳（秒）

返回从1970年1月1日00:00:00 UTC至今的秒数。
这个值在全球任何时区都是相同的。

Returns:
    当前的Unix时间戳（整数，单位为秒）

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It effectively discloses key behavioral traits: it's a read-only operation (implied by '获取'/'get'), returns an integer in seconds, is globally timezone-agnostic, and references the Unix epoch. It doesn't mention rate limits or errors, but for a simple timestamp tool, this is adequate.

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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by clarifying details about the timestamp's nature and return value. Every sentence adds value without redundancy, and the bilingual format (Chinese/English) is efficient for clarity.

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

Completeness5/5

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, no annotations, but has an output schema), the description is complete. It explains what the tool does, the return value (integer seconds), and key behavioral aspects. With an output schema, it doesn't need to detail return structure further.

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

Parameters4/5

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

The input schema has 0 parameters with 100% coverage, so the baseline is 4. The description correctly indicates no parameters are needed, aligning with the schema. No additional parameter semantics are required.

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 tool's purpose with a specific verb ('获取'/'get') and resource ('当前Unix时间戳'), and distinguishes it from siblings by specifying it returns seconds (vs. format_timestamp which likely formats, and get_current_time which might return a different representation). It explicitly mentions the Unix epoch reference point.

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

Usage Guidelines4/5

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

The description provides clear context for when to use this tool: to get the current Unix timestamp in seconds, globally consistent across time zones. It doesn't explicitly state when not to use it or name alternatives, but the context is sufficient for basic differentiation from siblings.

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 updatesJan 14, 2026
- First observedformat_timestamp
- First observedget_current_time
- First observedget_timestamp

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

A4.7/5.0

Scored 2026-04-18 06:50 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: format_timestamp converts a given timestamp to a readable format, get_current_time retrieves the current time in a specified timezone, and get_timestamp returns the current Unix timestamp. There is no overlap in functionality, making it easy for an agent to select the correct tool based on the need.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (format_timestamp, get_current_time, get_timestamp) using snake_case. The naming is predictable and readable, with no deviations or mixed conventions.

Tool Count5/5

With 3 tools, the server is well-scoped for its utility purpose focused on time-related operations. Each tool earns its place by covering distinct aspects of time handling, avoiding bloat or thinness.

Completeness5/5

The tool set provides complete coverage for time-related utilities: formatting timestamps, getting current time in timezones, and obtaining Unix timestamps. There are no obvious gaps, and agents can handle common time queries without dead ends.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

tick-mcp A
io.github.Cocabadger
A time server that keeps your AI honest about time. Real clock + drift guard, zero dependencies.
Developer Tools
226
mcp-time B
io.github.mcpcentral-io
Time MCP server via HTTP
Search
22
stamp A
io.github.theoddden
Concierge MCP for agentic workflows: verified time + drift, uuid, diff, calc, attest, verify.
Developer Tools Security Autonomous Agents
61
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2

Related MCP Servers

Time Tools MCP Server
Code Execution Developer Tools
t-shiratori
A
license
A
quality
D
maintenance
A Model Context Protocol server for time manipulation tasks, enabling AI models to get the current date/time and calculate duration between timestamps.
Updated a year ago (2025-05-08 13:12 UTC)
7
2
MIT
Time
Developer Tools App Automation
TheoBrigitte
A
license
Not graded
quality
C
maintenance
The Time MCP Server is a Model Context Protocol (MCP) server that provides AI assistants and other MCP clients with standardized tools to perform time and date-related operations. This server acts as a bridge between AI tools and a robust time-handling back
Updated 6 months ago (2026-03-30 10:02 UTC)
88 npm
25
MIT
Simple MCP Server
Shell Access Command Line Developer Tools
TrueBad0ur
A
license
Not graded
quality
D
maintenance
A self-contained, dependency-free MCP server that provides utility tools for time, date, mathematical calculations, and shell command execution. It supports remote connectivity through SSE and is designed for easy deployment via Docker.
Updated 8 months ago (2026-01-17 22:39 UTC)
GPL 3.0
datetime-mcp
Developer Tools Command Line
joshuaboys
A
license
D
quality
C
maintenance
A lightweight MCP server that provides date and time tools, including the ability to retrieve current timestamps and parse date strings with IANA timezone support. It enables AI models to interact with the host OS clock and perform temporal calculations via stdio transport.
Updated 6 months ago (2026-03-18 16:06 UTC)
3
9 npm
7
MIT

MCP Server - 通用功能服务器

✨ 功能

🕐 时间工具

📊 ChatBI 数据分析工具

🔭 Langfuse 链路观测

🚀 快速开始

安装依赖

本地模式运行

远程模式运行（默认推荐）

SSE 兼容模式

🔌 客户端集成

本地模式配置

远程模式配置

ChatBI / LangChain4j

兼容 mcp-remote 的 SSE 客户端

🐳 Docker 部署

使用 Docker Compose（推荐）

手动 Docker 命令

🔐 Langfuse 配置

🧪 开发测试

📖 架构说明

📄 许可证

Available Tools

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

兼容 `mcp-remote` 的 SSE 客户端