Skip to main content
Glama
xelber

New Relic MCP Server

by xelber
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

New Relic MCP Server

A Model Context Protocol (MCP) server that provides AI agents like Claude Code with access to New Relic logs and APM data through the NerdGraph API.

Features

Log Tools

  • query-logs: Execute custom NRQL queries against New Relic logs

  • search-logs: Search logs with keyword filtering and optional attributes

  • get-recent-logs: Retrieve the most recent log entries

APM Tools

  • query-apm: Execute custom NRQL queries against APM data (transactions, metrics, etc.)

  • get-apm-metrics: Get application performance metrics (response time, throughput, error rate, Apdex)

  • get-transaction-traces: Retrieve transaction traces with optional filtering for slow transactions

Related MCP server: New Relic NerdGraph MCP Server

Prerequisites

Installation

  1. Clone this repository:

git clone https://github.com/xelber/newrelic-mcp.git
cd newrelic-mcp

  1. Install dependencies:

npm install

  1. Build the project:

npm run build

Configuration

Set the following environment variables:

export NEW_RELIC_API_KEY="your-user-api-key"
export NEW_RELIC_ACCOUNT_ID="your-account-id"

Or create a .env file in the project root (not committed to git):

NEW_RELIC_API_KEY=your-user-api-key
NEW_RELIC_ACCOUNT_ID=your-account-id

Usage with Claude Desktop and Claude Code

Step 1: Configure in Claude Desktop

First, add this server to your Claude Desktop configuration file:

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

Add the following configuration:

{
  "mcpServers": {
    "newrelic": {
      "command": "node",
      "args": ["/absolute/path/to/newrelic-mcp/dist/index.js"],
      "env": {
        "NEW_RELIC_API_KEY": "your-user-api-key",
        "NEW_RELIC_ACCOUNT_ID": "your-account-id"
      }
    }
  }
}

Important:

  • Replace /absolute/path/to/newrelic-mcp with the actual path to this project

  • Replace your-user-api-key with your New Relic User API Key

  • Replace your-account-id with your New Relic Account ID

Example (macOS):

{
  "mcpServers": {
    "newrelic": {
      "command": "node",
      "args": ["/Users/yourusername/newrelic-mcp/dist/index.js"],
      "env": {
        "NEW_RELIC_API_KEY": "NRAK-XXXXXXXXXXXXXXXXXXXXX",
        "NEW_RELIC_ACCOUNT_ID": "1234567"
      }
    }
  }
}

After updating the configuration:

  1. Save the file

  2. Restart Claude Desktop completely (Quit and reopen)

  3. Look for the 🔌 icon in Claude Desktop to verify the MCP server is connected

Step 2: Import into Claude Code

Once configured in Claude Desktop, you can import the server into Claude Code:

  1. Open Claude Code in your terminal or IDE

  2. The MCP server will be automatically available if you have Claude Desktop configured

  3. Alternatively, you can add it directly to Claude Code's MCP settings

For Claude Code direct configuration, create/edit the file at:

  • macOS/Linux: ~/.config/claude-code/mcp_settings.json

With the same configuration format as above.

Available Tools

1. query-logs

Execute custom NRQL queries for complex filtering and aggregations.

Example queries:

query-logs with query: "SELECT * FROM Log WHERE message LIKE '%error%' SINCE 1 HOUR AGO LIMIT 100"

query-logs with query: "SELECT count(*) FROM Log WHERE level = 'ERROR' FACET host SINCE 1 DAY AGO"

query-logs with query: "SELECT * FROM Log WHERE service.name = 'api-server' AND response.status >= 500 SINCE 30 MINUTES AGO"

2. search-logs

Simplified search with keyword and attribute filtering.

Parameters:

  • keywords (optional): Text to search for in log messages

  • timeRange (default: "1 HOUR AGO"): Time range for the search

  • limit (default: 100): Maximum number of results

  • attributes (optional): Key-value pairs for filtering

Example:

search-logs with keywords: "database timeout", timeRange: "2 HOURS AGO", limit: 50

search-logs with keywords: "authentication failed", attributes: { "service.name": "auth-service" }

3. get-recent-logs

Quick access to the most recent log entries.

Parameters:

  • limit (default: 50): Number of recent entries

  • timeRange (default: "1 HOUR AGO"): Time window to search

Example:

get-recent-logs with limit: 100

get-recent-logs with limit: 25, timeRange: "30 MINUTES AGO"

4. query-apm

Execute custom NRQL queries against APM data for advanced analysis.

Example queries:

query-apm with query: "SELECT average(duration) FROM Transaction WHERE appName = 'MyApp' SINCE 1 HOUR AGO"

query-apm with query: "SELECT count(*) FROM Transaction WHERE error IS true FACET appName SINCE 1 DAY AGO"

query-apm with query: "SELECT percentile(duration, 95) FROM Transaction WHERE transactionType = 'Web' SINCE 30 MINUTES AGO TIMESERIES"

5. get-apm-metrics

Get comprehensive application performance metrics including response time, throughput, error rate, and Apdex score.

Parameters:

  • appName (optional): Filter metrics for a specific application. If not provided, returns aggregated metrics across all applications.

  • timeRange (default: "1 HOUR AGO"): Time range for metrics

  • metrics (default: ["responseTime", "throughput", "errorRate"]): Array of metrics to retrieve

    • Options: "responseTime", "throughput", "errorRate", "apdex"

Behavior:

  • With appName: Returns time-series metrics for the specified application

  • Without appName: Returns aggregated metrics across all applications (not broken down by app)

Examples:

get-apm-metrics with appName: "MyApp", timeRange: "2 HOURS AGO"

get-apm-metrics with metrics: ["responseTime", "errorRate", "apdex"]

get-apm-metrics with appName: "EcommerceApp", metrics: ["throughput", "responseTime"], timeRange: "1 DAY AGO"

Note: To get metrics for multiple specific applications, call this tool separately for each application name.

6. get-transaction-traces

Retrieve transaction traces to identify performance bottlenecks and slow operations.

Parameters:

  • appName (optional): Filter transactions for a specific application

  • minDuration (optional): Minimum transaction duration in seconds to filter slow transactions

  • limit (default: 10): Maximum number of transaction traces to return

  • timeRange (default: "1 HOUR AGO"): Time range to search

Examples:

get-transaction-traces with appName: "MyApp", minDuration: 2.0, limit: 20

get-transaction-traces with minDuration: 5.0, timeRange: "30 MINUTES AGO"

get-transaction-traces with appName: "APIService", limit: 50

Development

Run tests:

npm test

Run tests with coverage:

npm run test:coverage

Run tests in watch mode:

npm run test:watch

Run in development mode (builds and starts):

npm run dev

Watch mode for auto-rebuilding:

npm run watch

Build the project:

npm run build

Example Interactions

Once configured, you can ask Claude (in Claude Desktop or Claude Code):

Log Queries

  • "Show me recent errors from New Relic logs"

  • "Search for logs containing 'payment failed' in the last 2 hours"

  • "Query New Relic for all logs from the api-gateway service with 500 status codes"

  • "Get the last 100 log entries from New Relic"

  • "Find all logs with response time > 5000ms in the last hour"

  • "Show me error logs grouped by service name"

APM Queries

  • "Show me the response time and throughput for MyApp in the last hour"

  • "Get APM metrics for all applications including error rates"

  • "Find slow transactions that took longer than 3 seconds"

  • "What's the error rate for MyApp over the past 2 hours?"

  • "Show me the slowest 20 transactions from the EcommerceApp"

  • "Get the Apdex score and response time for all my applications"

  • "Find all transactions that resulted in errors in the last 30 minutes"

Troubleshooting

MCP Server Connection Issues

Server not showing in Claude Desktop:

  • Verify the config file path is correct for your OS

  • Check that the JSON syntax is valid (no trailing commas, proper quotes)

  • Ensure the path to dist/index.js is absolute, not relative

  • Restart Claude Desktop completely (Quit, not just close window)

  • Check Claude Desktop logs: View > Developer > Show Logs

"Cannot find module" errors:

  • Make sure you ran npm install in the project directory

  • Verify you ran npm run build to compile TypeScript

  • Check that the dist/ folder exists and contains the compiled files

New Relic API Issues

"Configuration error" on startup:

  • Ensure NEW_RELIC_API_KEY and NEW_RELIC_ACCOUNT_ID are set correctly

  • Verify your API key has the necessary permissions (User key, not Ingest key)

  • Get your User API key from: https://one.newrelic.com/api-keys

"Failed to query New Relic":

  • Check your API key is valid and not expired

  • Verify your account ID is correct (find it at https://one.newrelic.com/admin-portal)

  • Ensure you have access to the Logs product in New Relic

  • Test your credentials using the NerdGraph API Explorer

No results returned:

  • Verify you have log data in New Relic for the specified time range

  • Check your NRQL syntax is valid

  • Try a broader time range (e.g., "1 DAY AGO" instead of "1 HOUR AGO")

  • Use the New Relic UI to confirm logs exist for your query

NRQL Resources

License

MIT

Available Tools

6 tools
get-apm-metricsB

Get APM performance metrics for applications including response time, throughput, error rate, and Apdex. This provides a comprehensive overview of application performance.

ParametersJSON Schema
NameRequiredDescriptionDefault
appNameNoApplication name to filter metrics (optional)
timeRangeNoTime range (e.g., "1 HOUR AGO", "30 MINUTES AGO", "1 DAY AGO")1 HOUR AGO
metricsNoMetrics to retrieve

TDQS

B3.2/5.0
Behavior2/5

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

No annotations provided, so description bears full burden. It only states 'comprehensive overview' without disclosing behavioral traits like read-only nature, data aggregation details, or default behavior when appName is omitted.

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 with no extraneous information. Directly states purpose and key included metrics.

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

Completeness2/5

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

With 3 optional parameters and no output schema, description lacks details on return format, default behavior (e.g., what happens if appName omitted), or how metrics are computed. Incomplete for full agent decision-making.

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 descriptions for all 3 parameters. Description repeats enum values already in schema, adding no extra meaning or constraints beyond what is already structured.

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?

Clearly states verb 'Get', resource 'APM performance metrics', and lists specific metrics (response time, throughput, error rate, Apdex), distinguishing it from sibling tools like get-recent-logs or query-apm.

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 like query-apm or get-transaction-traces. Does not mention when not to use or provide decision criteria.

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

get-recent-logsB

Get the most recent log entries from New Relic. Useful for quickly checking the latest logs without specific filters.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of recent log entries to retrieve
timeRangeNoTime range to search within1 HOUR AGO

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits; it does not mention pagination, rate limits, authorization, or what happens with no results.

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?

Two concise sentences, front-loaded with purpose and use case, no extraneous information.

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 low parameter count and no output schema, the description covers the core purpose and use case, but lacks behavioral details that would make it fully 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% and descriptions in schema are adequate; the tool description adds nothing beyond the schema for parameters.

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 the most recent log entries from New Relic, distinguishing it from siblings like search-logs that allow filtering.

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?

It implies use for quick checks without filters but provides no explicit guidance on when not to use or which sibling tool to choose instead.

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

get-transaction-tracesA

Get transaction traces from APM, optionally filtering for slow transactions. Useful for identifying performance bottlenecks and slow database queries.

ParametersJSON Schema
NameRequiredDescriptionDefault
appNameNoApplication name to filter transactions
minDurationNoMinimum transaction duration in seconds to filter slow transactions
limitNoMaximum number of transaction traces to return
timeRangeNoTime range to search within1 HOUR AGO

TDQS

A3.6/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 filtering behavior but omits details like authorization requirements, rate limits, or response format. Since it's a read operation, the lack of side effects disclosure is acceptable but not complete.

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, front-loaded with the core action, no redundant words. Every sentence adds value.

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 4 parameters and no output schema, the description covers the use case and filtering capability. However, it does not mention pagination or the return structure, leaving some gaps for a complete understanding.

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?

Input schema has 100% description coverage for all 4 parameters, so baseline is 3. The description adds 'optionally filtering for slow transactions', which maps to minDuration, but does not provide additional semantics beyond the schema.

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 retrieves transaction traces from APM and optionally filters for slow ones. It distinguishes from siblings like get-apm-metrics (metrics vs traces) and query-apm (general query), though indirectly.

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 mentions usefulness for performance bottleneck identification, but lacks explicit when-to-use vs alternatives or when-not-to-use guidance. Sibling tools are not compared.

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

query-apmA

Execute a custom NRQL query against New Relic APM data. Use this for complex queries against Transaction, Metric, or other APM event types. Example: "SELECT average(duration) FROM Transaction WHERE appName = 'MyApp' SINCE 1 HOUR AGO"

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesNRQL query to execute against APM data

TDQS

A4.1/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 mentions executing a custom NRQL query, which implies read-only behavior, but does not disclose rate limits, permissions, or error handling. The example gives some transparency 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: first states purpose, second provides an example and usage context. No wasted words, essential information is front-loaded.

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 hint at the return value (e.g., a dataset). It only describes the input and purpose, leaving the agent uncertain about the output format. For a simple tool with one parameter, this is adequate but not complete.

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?

With 100% schema coverage, the baseline is 3. The description adds value by providing an example and specifying event types (Transaction, Metric) that the schema's terse 'NRQL query' does not capture, making the parameter's scope clearer.

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 executes custom NRQL queries against New Relic APM data. It distinguishes from siblings like get-apm-metrics (specific metrics) and query-logs (logs) by specifying APM event types.

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 explicitly says 'Use this for complex queries against Transaction, Metric, or other APM event types', providing clear usage context. It doesn't explicitly mention when not to use it, but the example and sibling tools provide enough differentiation.

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

query-logsA

Execute a custom NRQL query against New Relic logs. Use this for complex queries with specific filtering and aggregations. Example: "SELECT * FROM Log WHERE message LIKE '%error%' SINCE 1 HOUR AGO LIMIT 100"

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesNRQL query to execute against New Relic logs

TDQS

A4/5.0
Behavior3/5

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

No annotations provided, so description must disclose behavior. It explains input but does not mention output format, error handling, or rate limits. For a query tool, this is minimal but acceptable.

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?

Very concise: one sentence for purpose, one for usage, one example. No wasted words. Front-loaded with action.

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?

For a simple tool with one parameter and full schema coverage, the description is sufficient. Missing output format, but not critical given simplicity.

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 covers the single param with a description. Description adds an example query, which adds value. Baseline 3 is appropriate due to full coverage.

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?

Clearly states it executes a custom NRQL query against New Relic logs. Differentiates from siblings like get-recent-logs and search-logs, which are simpler or less flexible.

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?

Explicitly says use for complex queries with filtering and aggregations, and provides a concrete example. Does not explicitly state when not to use, but context implies simpler tasks can use sibling tools.

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

search-logsA

Search New Relic logs with keyword filtering and optional attributes. This is a simpler alternative to query-logs for basic searches.

ParametersJSON Schema
NameRequiredDescriptionDefault
keywordsNoKeywords to search for in log messages
timeRangeNoTime range (e.g., "1 HOUR AGO", "30 MINUTES AGO", "1 DAY AGO")1 HOUR AGO
limitNoMaximum number of results to return
attributesNoAdditional attributes to filter by (key-value pairs)

TDQS

A3.9/5.0
Behavior2/5

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

No annotations provided; description doesn't disclose side effects, permissions, output format, or other behavioral traits beyond basic search. Only says 'search' and 'simpler alternative'.

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, efficient: first sentence states action, second provides context. 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?

Lacks description of return format, pagination, or behavior for nested attributes. Adequate for basic searches but incomplete for full context, especially without output schema.

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?

All parameters have schema descriptions (100% coverage). Description adds 'optional attributes' but that's already implied. No extra semantic value beyond 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?

States clearly: 'Search New Relic logs with keyword filtering and optional attributes.' Distinguishes from sibling query-logs by calling itself a simpler alternative.

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?

Explicitly says 'simpler alternative to query-logs for basic searches,' guiding when to use vs. query-logs.

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. 6 tool updatesv1.0.0
    • First observedget-apm-metrics
    • First observedget-recent-logs
    • First observedget-transaction-traces
    • First observedquery-apm
    • First observedquery-logs
    • First observedsearch-logs
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

Each tool targets a distinct data source or operation: APM metrics, logs, transaction traces, and custom queries differentiate by data type (APM vs logs) and complexity (query vs search).

Naming Consistency5/5

All tool names use snake_case with consistent verb-noun pattern: get- for retrievals, query- for custom queries, search- for simple search.

Tool Count5/5

6 tools is well-scoped for a New Relic integration, covering the most common monitoring data types without unnecessary overlap.

Completeness4/5

Core read operations for APM, logs, and traces are present. Missing listing of apps/entities or alerting tools, but these are not essential for the main use case.

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

  • New Relic MCP Server

    piekstra
    A
    license
    B
    quality
    B
    maintenance
    Enables AI assistants to interact with New Relic monitoring and observability data through programmatic access to New Relic APIs. Supports APM management, NRQL queries, alert policies, synthetic monitoring, dashboards, infrastructure monitoring, and deployment tracking.
    26
    6
    MIT

  • New Relic NerdGraph MCP Server

    ulucaydin
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables users to query and manage New Relic account data and features through natural language or specific commands, including NRQL queries, entity search, APM, Synthetics, and alerts management.
    3
    -

  • newrelic-mcp

    kavingas
    F
    license
    Not graded
    quality
    B
    maintenance
    Executes NRQL queries against New Relic via the NerdGraph API, enabling monitoring and observability data retrieval through natural language.
    -

  • newrelic-mcp-server

    vickykr26941
    F
    license
    Not graded
    quality
    D
    maintenance
    Provides New Relic observability tools for AI assistants, enabling discovery, data access, alerting, incident response, and performance analytics via natural language queries.
    -

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/xelber/newrelic-mcp'

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