Skip to main content
Glama
Spyglass-AI

Spyglass AI MCP Server

Official
by Spyglass-AI
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Spyglass AI MCP Server

The Spyglass AI MCP server provides a simple interface for LLMs to query the Spyglass AI agent. The agent analyzes your telemetry data and provides intelligent insights about application performance, errors, and bottlenecks.

To install the MCP server for Cursor click the button below. It should open Cursor and prompt you to add your API Key.

Install MCP Server

Alternatively, add the following to your ~/.cursor/mcp.json file (create it if you need to) and substitute your Spyglass API Key. Then restart Cursor to apply the change.

{
  "mcpServers": {
    "spyglass-ai": {
      "command": "uvx",
      "args": ["spyglass-mcp"],
      "env": {
        "SPYGLASS_API_KEY": "your-key-here"
      }
    }
  }
}

Note that you need to have uv installed first, see the docs for that here

Available Tools

call_spyglass_agent

Calls the Spyglass AI agent with a natural language query about your telemetry data.

Parameters:

  • query (string, required): Natural language query about your application's telemetry data

Example queries:

  • "What are the slowest endpoints in the last hour?"

  • "Show me all errors in the checkout service"

  • "Which services have the highest error rate?"

  • "What's causing high latency in my API?"

  • "How many requests has my app had in the last day?"

Returns:

  • Natural language analysis of the telemetry data

Related MCP server: Datadog MCP Server

Configuration

Environment Variables

Variable

Required

Default

Description

SPYGLASS_API_KEY

Yes

N/A

API Key for authentication with Spyglass agent

SPYGLASS_AGENT_ENDPOINT

No

https://agent.spyglass-ai.com

Agent endpoint URL (useful for local testing)

Command Line Arguments

Argument

Required

Default

Description

--endpoint

No

https://agent.spyglass-ai.com

Spyglass agent endpoint URL

--transport

No

stdio

Transport type (stdio or http)

--port

No

8000

Port for HTTP transport

Example: Using with an MCP Client

import asyncio
from fastmcp import Client

client = Client("http://localhost:8000/mcp")

async def analyze():
    async with client:
        result = await client.call_tool("call_spyglass_agent", {
            "query": "What are the slowest endpoints?"
        })
        print(result)

asyncio.run(analyze())

Logging

The MCP server logs to both stderr (captured by Cursor) and a file for debugging:

Log file location:

~/.spyglass/logs/mcp-server-YYYYMMDD.log

View logs in real-time:

tail -f ~/.spyglass/logs/mcp-server-$(date +%Y%m%d).log

The logs include:

  • Server startup and configuration

  • Incoming queries and responses

  • API call details (with truncated tokens for security)

  • Error messages and stack traces

Development

Prerequisites

  • Python 3.11 or higher

  • uv package manager

Setup

  1. Clone the repository and navigate to the project directory:

cd spyglass-mcp

  1. Install dependencies:

uv sync

This will create a virtual environment and install all required dependencies.

  1. Copy the example environment file and configure your API key:

cp env.example .env
# Edit .env and add your SPYGLASS_API_KEY

Running Locally

Run the MCP server in stdio mode (default):

uv run spyglass-mcp

Run with a custom endpoint (useful for testing against a local agent):

uv run spyglass-mcp --endpoint http://localhost:8080

Run in HTTP transport mode:

uv run spyglass-mcp --transport http --port 8000

Running Tests

Run all tests:

uv run pytest

Run tests with verbose output:

uv run pytest -v

Run a specific test file:

uv run pytest tests/test_mcp_server.py

Run tests with coverage:

uv run pytest --cov=spyglass_mcp --cov-report=term-missing

Building

Build the package for distribution:

uv build

This will create wheel and source distribution files in the dist/ directory.

Project Structure

spyglass-mcp/
├── .github/
│   └── workflows/
│       └── publish.yaml
├── src/
│   └── spyglass_mcp/
│       ├── __init__.py
│       └── main.py
├── tests/
│   ├── __init__.py
│   ├── conftest.py
│   └── test_mcp_server.py
├── CHANGELOG.md
├── env.example
├── LICENSE
├── pyproject.toml
├── README.md
└── uv.lock

Available Tools

1 tool
call_spyglass_agentA

Call the Spyglass AI agent with a natural language query about your telemetry data.

Args: query: Natural language query about telemetry data (e.g., "What are the slowest endpoints?")

Returns: Analysis result from the Spyglass AI agent

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It only mentions returning an analysis result but lacks details on side effects, authentication, rate limits, or whether the call is synchronous. This is insufficient for an agent invocation.

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

Conciseness4/5

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

The description is concise with a brief sentence followed by structured Args and Returns sections. No waste, but could be slightly more structured (e.g., bullet points).

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?

The description covers purpose and parameter semantics adequately, but lacks details on return format, output schema, and behavioral characteristics. Given the tool is an agent call, more context (e.g., response format, latency) would be beneficial.

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?

Schema coverage is 0%, but the description adds meaning by describing the query parameter as 'natural language query about telemetry data' and provides an example. This compensates well for the schema's lack of description.

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?

Description clearly states the tool calls the Spyglass AI agent with a natural language query about telemetry data. Verb and resource are specific, and the purpose is unambiguous.

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

Usage Guidelines3/5

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

The description gives an example query but does not explicitly state when to use this tool vs. alternatives or provide conditions for use. With no sibling tools, it is adequate but not explicit.

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. Dates show when Glama detected each change.

  1. 1 tool updatev0.1.0
    • First observedcall_spyglass_agent
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation5/5

Only one tool exists, so there is no possibility of ambiguity between tools.

Naming Consistency5/5

The single tool name 'call_spyglass_agent' follows a clear verb_noun pattern, which is consistent and descriptive.

Tool Count3/5

A single tool for telemetry data analysis feels thin; typical telemetry servers offer multiple operations (e.g., list, get, query).

Completeness2/5

The tool only allows querying via an AI agent, with no tools for data exploration, configuration, or management, leaving significant gaps in the expected functionality.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • datadog-mcp

    Vicks9070
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI assistants to query and manage Datadog observability data including metrics, logs, traces, and monitors through natural language. Supports read-only operations by default for security.
    MIT

  • Datadog MCP Server

    bhayanak
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI assistants to interact with Datadog's observability platform via natural language, covering metrics, logs, APM, monitors, dashboards, incidents, and infrastructure.
    1,106
    1
    MIT

  • otel-mcp-server

    shiftyp
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables natural language querying and analysis of OpenTelemetry traces, metrics, and logs stored in Elasticsearch/OpenSearch, allowing AI assistants to investigate performance issues, find root causes, and explore system behavior.
    16
    14
    MIT

  • Datadog MCP Server

    TANTIOPE
    A
    license
    A
    quality
    B
    maintenance
    Enables AI assistants to access full Datadog observability, including log search, APM trace filtering, smart sampling, and cross-correlation between logs, traces, and metrics.
    23
    1,106
    5
    Apache 2.0

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/Spyglass-AI/spyglass-mcp'

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