Skip to main content
Glama
agarwalvivek29

OpenTelemetry MCP Server

by agarwalvivek29
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

list_log_label_values

Retrieve all distinct values for a specific log label to discover namespaces, jobs, or applications with available logs for investigation.

Instructions

Get all values for a specific log label. Common labels: 'namespace', 'job', 'app'. Use this to discover what namespaces/services have logs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
labelYesLabel name to get values for (e.g., 'namespace', 'job', 'app')
startNoStart time for value discovery
endNoEnd time for value discovery

Implementation Reference

  • src/tools/loki_tools.py:175-217 (handler)
    The handler function 'list_log_label_values' that executes the request to Loki to fetch label values.
    async def list_log_label_values(
    client: LokiClient,
    label: str,
    start: Optional[str] = None,
    end: Optional[str] = None
) -> Dict[str, Any]:
    """
    Get all values for a specific log label.
    
    Args:
        client: Loki client
        label: Label name (e.g., 'namespace', 'job')
        start: Start time for value discovery
        end: End time for value discovery
        
    Returns:
        List of label values
    """
    try:
        # Parse time range if provided
        start_ns = None
        end_ns = None
        if start or end:
            start_dt, end_dt = parse_time_range(start, end)
            start_ns = to_loki_time(start_dt)
            end_ns = to_loki_time(end_dt)
        
        result = await client.label_values(label, start_ns, end_ns)
        
        if result.get("status") == "success":
            values = result.get("data", [])
            return {
                "success": True,
                "label": label,
                "count": len(values),
                "values": values
            }
        else:
            return {
                "success": False,
                "error": "Failed to fetch label values"
            }
    except Exception as e:

Tool Definition Quality

A3.7/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It describes a read operation ('Get all values') which implies it's non-destructive, but doesn't mention authentication requirements, rate limits, or what happens when no values are found. The time range parameters suggest temporal filtering behavior, but this isn't explicitly explained.

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 perfectly concise with two sentences that each serve distinct purposes: the first states the core functionality, the second provides usage context and examples. There's zero wasted language, and the most important information comes first.

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

Completeness3/5

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

For a read-only tool with 3 parameters and no output schema, the description provides adequate but minimal context. It explains what the tool does and why to use it, but doesn't describe return format, pagination, error conditions, or how the time parameters affect results. Given the lack of annotations and output schema, more behavioral detail would be helpful.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds value by providing concrete examples of label values ('namespace', 'job', 'app') and explaining the tool's purpose in discovering namespaces/services, which gives context for the 'label' parameter. However, it doesn't add significant semantic information beyond what the schema provides.

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

Purpose4/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: 'Get all values for a specific log label.' It specifies the resource (log label values) and provides examples of common labels. However, it doesn't explicitly distinguish this tool from its sibling 'list_label_values' which appears to have a similar function.

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: 'Use this to discover what namespaces/services have logs.' It gives practical examples of labels to query. While it doesn't explicitly state when NOT to use it or name alternatives, the context is sufficiently clear for basic usage.

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

Install Server

Other Tools

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/agarwalvivek29/opentelemetry-mcp'

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