Skip to main content
Glama
jamesbrink

MCP Server for Coroot

get_application_traces

Retrieve distributed tracing data to analyze request flow through applications and dependencies, with optional time filters and trace-specific queries.

Instructions

Get distributed traces for an application.

Retrieves distributed tracing data showing request flow through the application and its dependencies.

⚠️ WARNING: This endpoint can return very large responses (100k+ tokens) when retrieving many traces. Consider using time filters or trace_id to limit the response size.

Args: project_id: Project ID app_id: Application ID (format: namespace/kind/name) from_timestamp: Start timestamp (optional, recommended to limit data) to_timestamp: End timestamp (optional, recommended to limit data) trace_id: Specific trace ID to retrieve (optional, returns single trace) query: Search query (optional)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idYes
app_idYes
from_timestampNo
to_timestampNo
trace_idNo
queryNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • Primary MCP tool handler for 'get_application_traces', decorated with @mcp.tool() for automatic registration and schema inference from signature. Delegates to internal impl.
    @mcp.tool()
    async def get_application_traces(
        project_id: str,
        app_id: str,
        from_timestamp: int | None = None,
        to_timestamp: int | None = None,
        trace_id: str | None = None,
        query: str | None = None,
    ) -> dict[str, Any]:
        """Get distributed traces for an application.
    
        Retrieves distributed tracing data showing request flow
        through the application and its dependencies.
    
        ⚠️ WARNING: This endpoint can return very large responses (100k+ tokens)
        when retrieving many traces. Consider using time filters or trace_id
        to limit the response size.
    
        Args:
            project_id: Project ID
            app_id: Application ID (format: namespace/kind/name)
            from_timestamp: Start timestamp (optional, recommended to limit data)
            to_timestamp: End timestamp (optional, recommended to limit data)
            trace_id: Specific trace ID to retrieve (optional, returns single trace)
            query: Search query (optional)
        """
        return await get_application_traces_impl(  # type: ignore[no-any-return]
            project_id, app_id, from_timestamp, to_timestamp, trace_id, query
        )
  • Internal helper implementation that encodes app_id and calls CorootClient.get_application_traces
    @handle_errors
    async def get_application_traces_impl(
        project_id: str,
        app_id: str,
        from_timestamp: int | None = None,
        to_timestamp: int | None = None,
        trace_id: str | None = None,
        query: str | None = None,
    ) -> dict[str, Any]:
        """Get application traces."""
        # URL encode the app_id since it contains slashes
        encoded_app_id = quote(app_id, safe="")
    
        traces = await get_client().get_application_traces(
            project_id, encoded_app_id, from_timestamp, to_timestamp, trace_id, query
        )
        return {
            "success": True,
            "traces": traces,
        }
  • CorootClient method implementing the core logic: constructs query params and makes HTTP GET request to Coroot API endpoint /api/project/{project_id}/app/{app_id}/tracing to fetch distributed traces data.
    async def get_application_traces(
        self,
        project_id: str,
        app_id: str,
        from_timestamp: int | None = None,
        to_timestamp: int | None = None,
        trace_id: str | None = None,
        query: str | None = None,
    ) -> dict[str, Any]:
        """Get application distributed traces.
    
        Args:
            project_id: Project ID.
            app_id: Application ID.
            from_timestamp: Start timestamp.
            to_timestamp: End timestamp.
            trace_id: Specific trace ID.
            query: Search query.
    
        Returns:
            Distributed traces data.
        """
        params = {}
        if from_timestamp:
            params["from"] = str(from_timestamp)
        if to_timestamp:
            params["to"] = str(to_timestamp)
        if trace_id:
            params["trace_id"] = trace_id
        if query:
            params["query"] = query
    
        response = await self._request(
            "GET",
            f"/api/project/{project_id}/app/{app_id}/tracing",
            params=params,
        )
        data: dict[str, Any] = response.json()
        return data
  • @mcp.tool() decorator registers the function as an MCP tool, auto-generates schema from signature.
    @mcp.tool()
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 warns about potential large responses (100k+ tokens) and provides practical guidance about using filters to manage response size. This adds valuable context beyond what the input schema provides about the tool's behavior and performance characteristics.

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 and front-loaded with the core purpose, followed by important warnings, then parameter details. Every sentence earns its place: the first establishes purpose, the second elaborates, the warning is crucial for performance awareness, and the parameter section provides essential semantics. No wasted words.

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 complexity (6 parameters, potential for large responses) and the presence of an output schema (which means return values don't need explanation), the description is quite complete. It covers purpose, usage guidance, behavioral warnings, and parameter semantics. The only minor gap is not explicitly mentioning authentication requirements or rate limits, though these might be covered elsewhere.

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?

With 0% schema description coverage, the description compensates excellently by providing semantic explanations for all 6 parameters. It clarifies the format for app_id ('namespace/kind/name'), explains the purpose of timestamp parameters ('recommended to limit data'), and distinguishes between trace_id ('returns single trace') and query ('Search query'). This adds substantial 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 verbs ('Get', 'Retrieves') and resources ('distributed traces for an application', 'distributed tracing data showing request flow through the application and its dependencies'). It distinguishes itself from sibling tools like 'get_traces_overview' by focusing on detailed trace data rather than overview information.

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 about when to use this tool (to retrieve distributed tracing data) and includes a warning about large responses with recommendations to use time filters or trace_id to limit data. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the sibling tools.

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/jamesbrink/mcp-coroot'

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