Skip to main content
Glama
5hahiL

Tideways MCP Server

by 5hahiL
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Tideways MCP Server

CI/CD Pipeline Release Security Pipeline npm version npm downloads

A Model Context Protocol (MCP) server that enables AI assistants to query Tideways performance monitoring data and provide conversational performance insights for PHP applications.

About Tideways: Tideways is a powerful application performance monitoring (APM) platform designed specifically for PHP applications. For technical details, see the REST API documentation.

Forked from abuhamza/tideways-mcp-server by Mouhammed Diop.

Features

  • Conversational Performance Insights: Get performance data in natural language format optimized for AI assistants

  • AI Assistant Integration: Works with Claude Desktop, Cursor, Claude Code, and other MCP-compatible tools

  • Real-time Performance Metrics: Query current performance data with configurable rate limiting

  • Trace Analysis: List and filter traces with layer breakdown, bottleneck detection, and response time analysis

  • Issue Analysis: Retrieve and analyze errors, exceptions, and performance issues

  • Robust Error Handling: Comprehensive error handling with user-friendly messages

Repository: 5hahiL/tideways-mcp-server License: MIT

Related MCP server: Datadog MCP Server

Prerequisites

  • Tideways account with a valid API token

  • API token with appropriate scopes (metrics, issues, traces) - see API documentation

  • Access to a Tideways organization and project

AI Integration Setup

This is an MCP (Model Context Protocol) server designed exclusively for AI assistants. It cannot be used as a standalone CLI tool.

The server integrates with AI assistants through MCP configuration using the npm package tideways-mcp.

Environment Variables

Variable

Required

Default

Description

TIDEWAYS_TOKEN

✅

-

Tideways API access token (see Security section)

TIDEWAYS_ORG

✅

-

Tideways organization name

TIDEWAYS_PROJECT

✅

-

Tideways project name

TIDEWAYS_BASE_URL

❌

https://app.tideways.io/apps/api

Tideways API base URL

TIDEWAYS_RATE_LIMIT

❌

2500

API requests per hour — match to your plan (Team/Pro: 2500, Standard: 1000, Basic: 250)

TIDEWAYS_MAX_RETRIES

❌

3

Maximum API retry attempts

TIDEWAYS_REQUEST_TIMEOUT

❌

30000

API request timeout (ms)

LOG_LEVEL

❌

info

Log level (debug, info, warn, error)

AI Assistant Integration

This server only works with MCP-compatible AI assistants. It uses stdio transport.

Claude Desktop

Add to your Claude Desktop MCP configuration file:

Location:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

  • Linux: ~/.config/claude/claude_desktop_config.json

Configuration (Recommended - using npx):

{
  "mcpServers": {
    "tideways": {
      "command": "npx",
      "args": ["tideways-mcp"],
      "env": {
        "TIDEWAYS_TOKEN": "your_token",
        "TIDEWAYS_ORG": "your_org",
        "TIDEWAYS_PROJECT": "your_project"
      }
    }
  }
}

Alternative (if installed globally):

{
  "mcpServers": {
    "tideways": {
      "command": "tideways-mcp",
      "env": {
        "TIDEWAYS_TOKEN": "your_token",
        "TIDEWAYS_ORG": "your_org",
        "TIDEWAYS_PROJECT": "your_project"
      }
    }
  }
}

Cursor IDE

Cursor supports MCP through its settings. Add the server configuration in Cursor's MCP settings:

  1. Open Cursor Settings

  2. Tools & Integration

  3. Add a new server with:

{
  "mcpServers": {
    "tideways": {
      "command": "tideways-mcp",
      "env": {
        "TIDEWAYS_TOKEN": "your_token",
        "TIDEWAYS_ORG": "your_org",
        "TIDEWAYS_PROJECT": "your_project"
      }
    }
  }
}

VS Code with MCP Extension

If using VS Code with an MCP-compatible extension:

{
  "mcp.servers": {
    "tideways": {
      "command": "npx",
      "args": ["tideways-mcp"],
      "env": {
        "TIDEWAYS_TOKEN": "your_token",
        "TIDEWAYS_ORG": "your_org",
        "TIDEWAYS_PROJECT": "your_project"
      }
    }
  }
}

Using with AI Assistants

Once configured, you can ask your AI assistant questions like:

Basic Performance Queries

  • "What's the current performance of my application?"

  • "Show me recent errors in the last 24 hours"

  • "How is my API performing compared to yesterday?"

  • "What are the slowest transactions right now?"

Advanced Trace Analysis & Optimization

  • "Analyze the /api/users/{id} endpoint and identify bottlenecks"

  • "Find the root cause of slow performance in my checkout process"

  • "Detect N+1 queries in my product listing endpoint and suggest fixes"

  • "Analyze traces for /dashboard and recommend code optimizations"

  • "Identify database query bottlenecks in my user authentication flow"

  • "Find memory leaks or inefficient code paths in my API endpoints"

  • "Analyze dependency injection overhead in my application"

  • "Detect redundant database calls and suggest caching strategies"

Performance Optimization Suggestions

  • "Recommend performance improvements for my slowest endpoints"

  • "Analyze my SQL queries and suggest indexing strategies"

  • "Identify opportunities for query batching or lazy loading"

  • "Find inefficient loops or recursive calls in my traces"

  • "Suggest code refactoring based on performance bottlenecks"

  • "Analyze memory usage patterns and recommend optimizations"

Available MCP Tools

All tools return raw JSON from the Tideways API. The AI assistant (Claude, Cursor, etc.) performs the actual analysis and interpretation of this data.

get_performance_metrics

Retrieve aggregate performance metrics and system-wide statistics.

Parameters:

  • ts (optional): End timestamp in Y-m-d H:i format (e.g., "2025-08-12 18:30")

  • m (optional): Number of minutes backward from timestamp (e.g., 60 for 1 hour, 1440 for 24 hours)

  • env (optional): Filter by specific environment

  • s (optional): Filter by specific service name

Conversational Examples:

"What's the current performance of my application?"
"Show me performance metrics for the last 6 hours"
"Get metrics for the API service in production"
"How is my web service performing in the staging environment?"
"Compare today's metrics with the last 24 hours"

Returns: Raw performance data from Tideways including response times, throughput, error rates, and transaction breakdowns.

get_performance_summary

Retrieve time-series performance summary data in 15-minute intervals for trend analysis.

Parameters:

  • s (optional): Service name to filter by (e.g., "web", "api", "worker"). Default: "web"

Conversational Examples:

"Show me performance trends over the last few hours"
"Get the performance summary for my API service"
"How has my web service been performing recently?"
"Display trends for the worker service"
"Show me response time patterns for today"

Returns: Raw time-series data with 15-minute intervals showing response times, request counts, and error rates.

get_issues

Retrieve and analyze recent errors, exceptions, and performance issues.

Parameters:

  • issue_type (optional): "error", "slowsql", "deprecated", "all" (default: "all")

  • status (optional): "open", "new", "resolved", "not_error", "ignored", "all" (default: "open")

  • page (optional): Page number for pagination (default: 1)

Conversational Examples:

"What errors are currently happening in my application?"
"Show me all open errors from the last 24 hours"
"Get slow SQL queries that need attention"
"Are there any new performance issues I should know about?"
"List all deprecated function calls in my code"
"Show me resolved errors to understand what was fixed"

Returns: Raw issue data from Tideways including error types, occurrence counts, affected endpoints, and stack traces where available.

get_traces

Analyze individual trace samples for detailed bottleneck identification and performance debugging.

Parameters:

  • env (optional): Environment name (e.g., "production", "staging")

  • s (optional): Service name (e.g., "web", "api", "worker")

  • transaction_name (optional): Filter by specific transaction/endpoint name

  • has_callgraph (optional): Only return traces with detailed callgraph data

  • search (optional): Word-based search on transaction_name, host, and URL

  • min_date (optional): Minimal date in YYYY-MM-DD HH:MM format (requires max_date)

  • max_date (optional): Maximal date in YYYY-MM-DD HH:MM format (requires min_date)

  • min_response_time_ms (optional): Minimum response time filter

  • max_response_time_ms (optional): Maximum response time filter

  • sort_by (optional): "response_time", "date", "memory" (default: "response_time")

  • sort_order (optional): "ASC", "DESC" (default: "DESC")

Conversational Examples:

"Analyze traces for the /api/products endpoint and find bottlenecks"
"Show me the slowest requests from the last hour with details"
"Find traces with callgraph data for the checkout process"
"What's causing slow response times in my user registration flow?"
"Detect N+1 query problems in my product listing page"
"Analyze memory usage patterns in my API endpoints"
"Find database bottlenecks in the /dashboard endpoint"
"Show me traces where response time is over 2 seconds"

Returns: Raw trace data from Tideways including per-request timing, layer breakdown (SQL, Redis, HTTP, etc.), bottleneck flags, and callgraph data when has_callgraph: true is set. Use has_callgraph: true for the deepest debugging detail.

get_historical_data

Retrieve historical performance data for specific dates with configurable granularity.

Parameters:

  • date (required): Date in YYYY-MM-DD format

  • granularity (optional): "day", "week", "month" (default: "day")

Conversational Examples:

"Get historical performance data for August 1st, 2025"
"Show me weekly performance trends for last Monday"
"Compare this month's performance with last month"
"How did my application perform on 2025-07-15?"
"Get daily performance data for the past week"
"Show me monthly trends for the last quarter"

Returns: Raw historical performance data from Tideways for the specified date and granularity.

Development

Project Structure

├── src/
│   ├── config/           # Configuration management
│   ├── lib/              # Core libraries
│   │   ├── errors.ts     # Error handling utilities
│   │   ├── logger.ts     # Structured logging
│   │   └── tideways-client.ts  # Tideways API client
│   ├── tools/            # MCP tool implementations
│   │   ├── definitions.ts # Tool schema definitions
│   │   ├── registry.ts   # Tool execution registry
│   │   └── handlers/     # Individual tool handlers
│   ├── types/            # TypeScript type definitions
│   ├── utils/            # Utility functions
│   ├── server.ts         # Main MCP server implementation
│   └── index.ts          # Application entry point
├── tests/                # Test suites
└── dist/                 # Compiled JavaScript (generated)

Running Tests

# Run all tests
npm test

# Run tests with coverage
npm run test:coverage

# Run tests in watch mode
npm run test:watch

# Run type checking
npm run typecheck

Building

# Build TypeScript to JavaScript
npm run build

# Clean build artifacts
npm run clean

Code Quality

# Run linter
npm run lint

# Fix linting issues
npm run lint:fix

# Format code
npm run format

Architecture

Core Components

  1. MCP Server (src/server.ts): Main server implementing MCP protocol, handles tool definitions and routing

  2. Tideways API Client (src/lib/tideways-client.ts): HTTP client with rate limiting, retry logic, and security measures

  3. Tool Registry (src/tools/): Modular tool system with individual handlers for each MCP tool

  4. Error Handler (src/lib/errors.ts): Centralized error handling with user-friendly messages

  5. Logger (src/lib/logger.ts): Structured JSON logging for monitoring and debugging

  6. Configuration (src/config/index.ts): Environment-based configuration management

Data Flow

AI Assistant ←→ MCP Protocol (stdio) ←→ TidewaysMCPServer → TidewaysClient → Tideways API
                                               ↓
                                        Raw JSON Response → AI Assistant

Response Format Philosophy

This server uses a raw JSON approach for optimal performance:

  • Direct API-to-LLM Pipeline: Tools return JSON.stringify(apiData, null, 2) without formatting

  • Zero Processing Overhead: No complex formatting, caching, or interpretation logic

  • Complete Data Preservation: LLM receives all available data for flexible analysis

  • Minimal Maintenance: No formatter or caching logic to maintain or debug

Rate Limiting Strategy

  • Configurable Rate Limiter: Set TIDEWAYS_RATE_LIMIT to match your Tideways plan (default: 2500/hr)

  • Direct API Calls: All requests go directly to Tideways API without caching layer

  • Retry Logic: Automatic retries for transient failures with exponential backoff

🛡️ Security

  • API tokens stored securely in environment variables

  • Authorization headers automatically redacted in logs as Bearer [REDACTED]

  • Rate limiting to respect Tideways API constraints

  • Input validation on all MCP function parameters

  • No sensitive data logged or exposed in error messages

  • Automated security scanning: CodeQL, Snyk, TruffleHog, GitLeaks

📊 Monitoring

The server provides structured JSON logs for monitoring:

{
  "timestamp": "2025-08-09T10:00:00.000Z",
  "level": "info",
  "message": "Tool called",
  "context": {
    "toolName": "get_performance_metrics",
    "arguments": {"time_range": "24h"}
  }
}

🔧 Troubleshooting

Common Issues

Authentication Error

Error: Authentication failed. Please check your API token.

  • Verify TIDEWAYS_TOKEN is correct and has required scopes (metrics, issues, traces)

  • Check token hasn't expired

  • Ensure organization and project names are correct

Rate Limit Exceeded

Error: Rate limit exceeded. Please try again later.

  • Set TIDEWAYS_RATE_LIMIT to match your actual plan limit

  • Wait for rate limit reset (shown in error message)

  • Built-in rate limiting respects your configured limit

Connection Issues

Error: Network error: Unable to connect to Tideways API.

  • Check internet connection

  • Verify Tideways API is accessible from your network

  • Check if corporate firewall blocks API access to app.tideways.io

  • Test with curl: curl -H "Authorization: Bearer YOUR_TOKEN" https://app.tideways.io/apps/api/_token

MCP Integration Issues

Error: MCP server not responding or connection failed

  • Restart your AI assistant (Claude Desktop, Cursor, etc.)

  • Verify MCP configuration file syntax is correct

  • Check that the server command path is correct

  • Ensure environment variables are properly set in MCP config

  • Try running the server manually first: npx tideways-mcp

Debug Mode

Enable debug logging for detailed troubleshooting:

# When running directly
LOG_LEVEL=debug npx tideways-mcp

# In MCP configuration, add to env:
{
  "env": {
    "LOG_LEVEL": "debug",
    "TIDEWAYS_TOKEN": "your_token",
    ...
  }
}

Getting Help

  1. Check the logs: Debug mode provides detailed information about requests and responses

  2. Verify configuration: Double-check all environment variables and MCP settings

  3. Test API access: Use curl to verify your Tideways API credentials work

  4. Report issues: GitHub Issues with debug logs and configuration details

Contributing

Contributions welcome!

  1. Create a feature branch: git checkout -b your-feature

  2. Make changes and add tests: npm test

  3. Submit a pull request

License

This project is licensed under the MIT License - see the LICENSE file for details.

Available Tools

5 tools
get_historical_dataA

Retrieve historical performance data in JSON format for a specific date with configurable granularity. Analyze daily, weekly, or monthly performance trends, transaction reports, and time-series metrics.

ParametersJSON Schema
NameRequiredDescriptionDefault
dateYesDate in YYYY-MM-DD format for the historical data
granularityNoGranularity for data aggregation. Day shows hourly breakdown, week/month show daily breakdown.day

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description must convey behavioral traits. It specifies JSON format and granularity options but does not disclose read-only nature explicitly, auth requirements, or error handling. The verb 'Retrieve' hints at idempotency but lacks depth.

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?

Two sentences that are front-loaded: the first states core function, the second elaborates use cases. No superfluous text, every sentence is purposeful.

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?

Given 2 parameters and no output schema, the description covers the retrieval purpose but lacks detail on return structure (beyond JSON) and does not fully differentiate from sibling performance tools. Adequate but not complete.

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 coverage is 100% with parameter descriptions. The description adds 'JSON format' and mentions 'trends, transaction reports, time-series metrics', but the schema already details granularity options. The added value is moderate.

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 retrieves historical performance data for a specific date with configurable granularity, using specific verbs like 'Retrieve' and 'Analyze'. It distinguishes from siblings like get_issues and get_performance_summary by focusing on historical data with granularity options.

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 implies usage for analyzing historical trends but does not explicitly state when to use this tool versus alternatives like get_performance_summary. No exclusions or when-not guidance is provided.

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

get_issuesA

Retrieve and analyze recent errors, exceptions, and performance issues in JSON format for actionable insights

ParametersJSON Schema
NameRequiredDescriptionDefault
issue_typeNoType of issues to retrieve (fixed enum values to match API)all
statusNoIssue status filter (updated to match API statuses)open
pageNoPage number for pagination (replaces limit)

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries full burden. It discloses the output format (JSON) and scope (errors, exceptions, performance issues) but lacks details on pagination behavior, rate limits, or side effects.

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?

Single, front-loaded sentence with no redundant words. Efficiently conveys purpose.

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?

Lacks output schema. Description covers basic purpose and JSON return but does not explain return structure, pagination details, or example usage. Adequate but not thorough.

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 coverage is 100%; all parameters have descriptions. The description adds minimal extra meaning beyond 'issue types' and 'statuses' already covered. Baseline 3 is appropriate.

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 retrieves and analyzes errors, exceptions, and performance issues in JSON format. It uses specific verbs and resources, and distinguishes from sibling tools like get_performance_metrics and get_traces.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as get_traces or get_performance_metrics. Does not specify prerequisites or context.

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

get_performance_metricsA

Retrieve aggregate performance metrics and system-wide statistics in JSON format. Use for monitoring overall application health, trends, and high-level performance overview (use get_traces for detailed individual request analysis).

ParametersJSON Schema
NameRequiredDescriptionDefault
tsNoEnd timestamp in Y-m-d H:i format (e.g., "2025-08-12 18:30"). Specifies the end time of the last minute to include in the query.
mNoNumber of minutes backward from timestamp to retrieve data (e.g., 60 for 1 hour, 1440 for 24 hours).
envNoFilter by specific environment (production, staging, etc.)
sNoFilter by specific service name

TDQS

A4.3/5.0
Behavior4/5

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

Without annotations, the description carries full burden. It states the output is in JSON format and describes the nature of the data (aggregate, system-wide). It implies a read operation, but could explicitly say 'read-only' and mention any limitations like time range.

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 two sentences, both front-loaded: first sentence states purpose, second provides usage guidance. No unnecessary words.

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?

With no output schema, the description should explain the return structure more. It only says 'in JSON format' and 'aggregate performance metrics', which is vague. For a complete understanding, the agent would benefit from knowing what specific metrics are included (e.g., latency, error rate).

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 coverage is 100%, so baseline is 3. The description adds no extra meaning to the parameters beyond what is already in the input schema. It does not explain how 'ts', 'm', 'env', 's' relate to the aggregate metrics.

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 verb 'Retrieve' and the resource 'aggregate performance metrics and system-wide statistics'. It distinguishes the tool from its sibling 'get_traces' by mentioning it is for high-level overview.

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 explicitly says 'Use for monitoring overall application health, trends, and high-level performance overview' and provides an alternative: 'use get_traces for detailed individual request analysis'. This gives clear guidance on when to use this tool.

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

get_performance_summaryB

Retrieve time-series performance summary data in 15-minute intervals in JSON format for trend analysis and historical comparison. Returns data aggregated in 15-minute time buckets showing requests, errors, and 95th percentile response times.

ParametersJSON Schema
NameRequiredDescriptionDefault
sNoService name to filter by (e.g., "web", "api", "worker"). Default: "web"

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations, the description carries the full burden. It discloses format, interval, and data fields (requests, errors, 95th percentile RT), but critically omits how to specify the time range or what the default range is. This is a significant gap for a data retrieval tool.

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 two sentences long, front-loading the main action and output. While efficient, it could be slightly more compact without losing clarity.

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?

Given the tool's simplicity (1 optional param, no output schema), the description explains what is returned and the format. However, it fails to specify the time range of the data, leaving a gap in completeness.

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% for the single parameter 's'. The tool description does not add any additional meaning or context to the parameter, so the baseline score of 3 is appropriate.

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 specifies the verb 'Retrieve' and the resource 'time-series performance summary data', including format and interval. It distinguishes from siblings like 'get_performance_metrics' by emphasizing aggregated summary data, but does not explicitly differentiate from 'get_historical_data'.

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 states 'for trend analysis and historical comparison', implying usage context, but lacks explicit guidance on when not to use or alternatives. No exclusion criteria are provided.

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

get_tracesA

Analyze individual trace samples in JSON format for detailed bottleneck identification and performance debugging. Use for investigating specific slow requests, not system-wide statistics (use get_performance_metrics for aggregate data).

ParametersJSON Schema
NameRequiredDescriptionDefault
envNoEnvironment name (e.g., "production", "staging")
sNoService name (e.g., "web", "api", "worker")
transaction_nameNoFilter by specific transaction/endpoint name
has_callgraphNoOnly return traces with detailed callgraph data
searchNoWord-based search on transaction_name, host, and URL text tokens. This is no fulltext search.
min_dateNoMinimal date for traces in YYYY-MM-DD HH:MM format (e.g., "2024-01-15 14:30"). Convert natural language like "1 hour ago" to this format. Requires max_date.
max_dateNoMaximal date for traces in YYYY-MM-DD HH:MM format (e.g., "2024-01-15 16:30"). Convert natural language like "now" to this format. Requires min_date.
min_response_time_msNoMinimum response time in milliseconds for filtering slow traces
max_response_time_msNoMaximum response time in milliseconds for filtering traces
sort_byNoField to sort traces byresponse_time
sort_orderNoSort order (DESC = slowest/newest first)DESC

TDQS

A3.9/5.0
Behavior2/5

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

No annotations provided, so description carries full burden. It only mentions JSON output and purpose, but lacks details on returned volume, pagination, or potential side effects.

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?

Two concise sentences, front-loaded with purpose and usage, no superfluous text.

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?

Given 11 parameters, no output schema, and no annotations, description covers purpose and usage well but lacks behavioral details like pagination or return format. Schema descriptions fill parameter details, but completeness is moderate.

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 has 100% description coverage, so description adds minimal extra value beyond schema. Baseline 3 is appropriate.

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 analyzes individual traces for bottleneck identification, and explicitly differentiates from get_performance_metrics for aggregate data.

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?

Directly states when to use (specific slow requests) and when not (system-wide statistics), naming the sibling alternative.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0
Disambiguation4/5

Tools are mostly distinct, but get_performance_metrics and get_performance_summary both deal with performance data, requiring careful reading of descriptions to differentiate. get_historical_data also overlaps slightly with time-series data, but descriptions help clarify.

Naming Consistency5/5

All tools follow a consistent 'get_<noun>' pattern in snake_case, making it predictable and easy for an agent to understand the action and resource.

Tool Count5/5

5 tools is a well-scoped set for a performance monitoring server, covering the essential retrievals without unnecessary bloat.

Completeness4/5

Covers all typical retrieval needs for application performance: historical data, issues, aggregate metrics, time-series summary, and individual traces. Minor gap in missing alerting or write operations, but retrieval surface is solid.

Maintenance

ActivityInactive
ResponsivenessSyncing

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

  • teslamate-mcp

    cobanov
    A
    license
    A
    quality
    B
    maintenance
    A Model Context Protocol (MCP) server that provides access to your TeslaMate database, allowing AI assistants to query Tesla vehicle data and analytics.
    18
    134
    MIT

  • Datadog MCP Server

    brukhabtu
    F
    license
    B
    quality
    Not graded
    maintenance
    A Model Context Protocol server that enables AI assistants to interact with Datadog's observability platform through natural language.
    72

  • Prometheus MCP Server

    yanmxa
    A
    license
    B
    quality
    F
    maintenance
    A Model Context Protocol server that enables AI assistants to query Prometheus metrics, discover available data, and analyze system performance through natural language interactions.
    5
    85
    MIT

  • symfony-php-mcp

    maschmann
    A
    license
    A
    quality
    C
    maintenance
    A production-ready Model Context Protocol (MCP) server that bridges your Symfony/PHP project with LLMs such as Claude. It exposes tools that let the AI read your project's routes, services, Twig templates, and PHP source code.
    8
    MIT

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/5hahiL/tideways-mcp-server'

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