Alibaba Cloud Observability MCP Server

repository·master·Indexed 41 days ago

https://github.com/aliyun/alibabacloud-observability-mcp-server

An official Model Context Protocol (MCP) server that provides AI models with structured access to Alibaba Cloud observability data. It enables AI agents in environments like Cursor, Cline, and Windsurf to query logs, metrics, and traces using natural language. Supported products include Log Service (SLS), Application Real-Time Monitoring Service (ARMS), CloudMonitor, and Prometheus monitoring. Version 1.x.x introduces the umodel_* toolset based on Observability 2.0.

Tokens
33.6K
Snippets
94
Records
144
Agent score
50%

What's inside Alibaba Cloud Observability MCP Server

  1. What is the Alibaba Cloud Observability MCP Server

    master

    The Alibaba Cloud Observability MCP Server is an official service designed to provide AI models with observability-driven interaction capabilities. It enables natural language access and analysis of multi-modal observability data.

    It is designed to integrate seamlessly with AI development environments and agent frameworks such as:

    • Cursor
    • Cline
    • Windsurf
    • Various other Agent frameworks
  2. Understanding the Alibaba Cloud Observability MCP Server

    master

    The Alibaba Cloud Observability MCP Server is an official service that provides AI interaction capabilities for observability data. It allows AI models (via the Model Context Protocol) to access, query, and analyze multi-modal observability data using natural language.

    Key capabilities include:

    • Multi-source Data Collaboration: Query data from multiple products simultaneously, including Log Service (SLS), Application Real-Time Monitoring Service (ARMS), CloudMonitor, and Prometheus.
    • Natural Language Driven: Users can retrieve logs, traces, and metrics using natural language instead of writing manual query statements.
    • Enterprise-grade Security: Uses Alibaba Cloud AccessKey authentication and strictly validates tool inputs/outputs to ensure data security.
  3. Configure tool descriptions for LLMs

    master

    Tool descriptions are critical for LLM discovery and usage. You can add descriptions using the description parameter in @self.server.tool() or via Python docstrings. A high-quality description should include:

    • Function Overview: What the tool does.
    • Usage Scenarios: When the LLM should call this tool.
    • Return Data Structure: A breakdown of the fields returned.
    • Query Examples: Natural language examples of how to trigger the tool.
    • Args/Returns: Detailed parameter and return type documentation.
    """
    列出阿里云日志服务中的所有项目。
    
    ## 功能概述
    该工具可以列出指定区域中的所有SLS项目...
    
    ## 使用场景
    - 当需要查找特定项目是否存在时...
    
    ## 返回数据结构
    - project_name: 项目名称
    - description: 项目描述
    - region_id: 项目所在区域
    
    ## 查询示例
    - "有没有叫 XXX 的 project"
    
    Args:
        ctx: MCP上下文
        project_name_query: 项目名称查询字符串
        limit: 返回结果的最大数量
        region_id: 阿里云区域ID
    
    Returns:
        包含项目信息的字典列表
    """
  4. Define tool naming, parameters, and return values

    master

    When defining a new MCP tool, adhere to these technical standards:

    Naming Convention

    Use the format {product_name}_{function_name} (e.g., sls_describe_logstore, arms_search_apps) to prevent ambiguity when multiple tools are integrated.

    Parameter Design

    • Complexity: Keep the number of parameters to 5 or fewer. If more are needed, split the tool.
    • Consistency: Use consistent field names across different tools (e.g., don't mix project_name and project).
    • Types: Use basic Python types (str, int, list, dict). Avoid custom types.
    • Validation: Use Pydantic Field for detailed descriptions, examples, and constraints (like ge, le). For fixed enums, specify allowed values in the description and add validation in the code.

    Return Value Design

    • Types: Prefer basic types over custom objects.
    • Payload Size: Control length by using pagination for data-heavy queries to avoid exhausting LLM context.
    • Clarity: Convert data classes into clear key-value dictionaries.
    • Empty States: For queries with no results, return a helpful text string like "没有找到相关数据" (No relevant data found) instead of an empty list to assist the LLM.
  5. Key advantages of the Observable MCP Server

    master

    The service provides three core advantages for enterprise observability workflows:

    1. Multi-source Data Synergy: A single integration allows simultaneous querying of SLS, ARMS, CloudMonitor, and Prometheus, providing a unified view of logs, metrics, and traces.
    2. Natural Language Driven: Users can retrieve logs, traces, and metrics using natural language instead of writing manual query statements, receiving structured answers in return.
    3. Enterprise-grade Security: The server uses the Alibaba Cloud AccessKey authentication mechanism. It does not collect data externally and performs strict validation on every tool's input and output to ensure data security and control.
  6. How the Model Context Protocol (MCP) works with Observability

    master

    The Model Context Protocol (MCP) establishes a unified context interaction standard between AI models and development environments.

    In this implementation, the Observable MCP Server maps natural language requirements to standardized tool calls. It then transparently schedules underlying observability product interfaces (such as logs, traces, and metrics) to provide structured results to the AI agent without requiring manual adaptation.

    Supported products currently include:

    • Log Service (SLS)
    • Application Real-Time Monitoring Service (ARMS)
    • CloudMonitor
    • Prometheus monitoring
  7. Version Compatibility: 1.x.x vs 0.3.x

    master

    The repository has undergone a significant version split:

    • Version 1.x.x (Current master branch): Contains significant feature upgrades based on Observability 2.0. It features a different tool design compared to the older version.
    • Version 0.3.x (Legacy branch): Contains the original master history and code. Use this branch only if you specifically require the older tool design and versioning.
  8. Warning: Paid AI Tools and Cost Management

    master

    Some AI-powered tools in this server incur STAROps fees per call.

    Paid Tools:

    • sls_text_to_sql (Natural language to SQL)
    • sls_text_to_spl (Natural language to SPL)
    • sls_sop (SLS Intelligent O&M Assistant)
    • cms_natural_language_query (Natural language data query)

    How to avoid unexpected costs: To use only free tools, edit your config.yaml and specify only the free tools in the enabled_tools section.

  9. Version migration notice: 0.3.x vs 1.x.x

    master

    The repository has undergone a significant structural change:

    • master branch: Now uses version 1.x.x. This version is based on Observability 2.0 and features significant functional upgrades and different tool designs compared to the previous version.
    • 0.3.x branch: Contains the original master branch history and code. Use this branch if you need to continue using the legacy version.

    Users should note that the tool shapes in 1.x.x differ significantly from 0.3.x.

  10. How the Model Context Protocol (MCP) works with Observability data

    master

    The Model Context Protocol (MCP) acts as a unified standard between AI models and development environments (like Cursor, Cline, or Windsurf).

    In this implementation, the Observable MCP Server maps natural language requirements to standardized tool calls. It then transparently schedules the underlying interfaces for observability products (SLS, ARMS, CloudMonitor, Prometheus, etc.), allowing AI agents to receive structured results without needing custom adaptations for each product.

  11. Handle tool exceptions and errors

    master

    Error handling strategy for MCP tools:

    1. Transparent Errors: If calling an API returns a clear error, let the original error log propagate. This helps the LLM understand what went wrong and potentially correct its own parameters.
    2. Opaque Errors: For generic errors like SYSTEM_ERROR, catch them and return a user-friendly, actionable hint.
    3. Resilience: Implement retry mechanisms for transient issues like network jitter or server-side rate limiting to prevent the LLM from failing due to temporary infrastructure issues.