New Relic MCP Server
New Relic MCP 服务器
一个简单的模型上下文协议 (MCP) 服务器,用于使用 NRQL 查询 New Relic 日志。此服务器支持 Claude 等大型语言模型 (LLM) 与您的 New Relic 数据进行交互。
特征
使用 NRQL 查询 New Relic 日志和指标
详细的错误日志记录
轻松与 Claude Desktop 集成
人类可读的输出格式
可配置的 New Relic 帐户 ID
Related MCP server: Datadog MCP Server
设置说明
先决条件
Python 3.10 或更高版本
New Relic 帐户和 API 密钥
Claude桌面应用程序
安装步骤
安装
uv包管理器:
# On macOS/Linux
curl -LsSf https://astral.sh/uv/install.sh | sh
# On Windows (PowerShell)
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"创建并设置项目:
# Create directory
mkdir newrelic-mcp
cd newrelic-mcp
# Create virtual environment
uv venv
# Activate virtual environment
source .venv/bin/activate # On Unix/macOS
.venv\Scripts\activate # On Windows
# Install dependencies
uv pip install "mcp[cli]" httpx使用提供的代码创建服务器文件
newrelic_logs_server.py。配置环境变量:
# On Unix/macOS
export NEW_RELIC_API_KEY="your-api-key-here"
export NEW_RELIC_ACCOUNT_ID="your-account-id-here"
# On Windows (CMD)
set NEW_RELIC_API_KEY=your-api-key-here
set NEW_RELIC_ACCOUNT_ID=your-account-id-here
# On Windows (PowerShell)
$env:NEW_RELIC_API_KEY = "your-api-key-here"
$env:NEW_RELIC_ACCOUNT_ID = "your-account-id-here"Claude 桌面集成
通过编辑配置文件来配置 Claude Desktop:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
添加以下配置:
{
"mcpServers": {
"newrelic": {
"command": "uv",
"args": [
"--directory",
"/absolute/path/to/newrelic-mcp",
"run",
"newrelic_logs_server.py"
],
"env": {
"NEW_RELIC_API_KEY": "your-api-key-here",
"NEW_RELIC_ACCOUNT_ID": "your-account-id-here"
}
}
}
}用法
NRQL 查询示例
基本交易查询:
SELECT * FROM Transaction SINCE 1 hour ago错误分析:
SELECT * FROM Transaction WHERE error IS TRUE SINCE 1 hour ago LIMIT 10性能分析:
SELECT average(duration) FROM Transaction FACET name ORDER BY average(duration) DESC LIMIT 5克劳德提示示例
您可以向 Claude 询问以下问题:
“显示过去一小时的所有交易”
“我们的申请中有什么错误吗?”
“我们最慢的端点是什么?”
调试
查看日志
# On macOS/Linux
tail -f ~/Library/Logs/Claude/mcp-server-newrelic.log
# On Windows
type %APPDATA%\Claude\logs\mcp-server-newrelic.log使用 MCP Inspector 进行测试
使用以下方法测试您的服务器功能:
npx @modelcontextprotocol/inspector uv run newrelic_logs_server.py常见问题
身份验证错误:
检查 NEW_RELIC_API_KEY 是否设置正确
验证 API 密钥具有正确的权限
确保 API 密钥有效
查询错误:
验证 NRQL 语法
检查代码中的帐户ID是否与您的帐户相符
确保查询的数据存在于该时间范围内
连接问题:
检查网络连接
验证 GraphQL 端点是否可访问
确保没有防火墙阻止连接
安全说明
切勿将 API 密钥提交到版本控制
使用环境变量来存储敏感数据
保持依赖项更新
监控查询模式和访问日志
发展
本地测试
设置环境变量:
export NEW_RELIC_API_KEY="your-api-key-here"
export NEW_RELIC_ACCOUNT_ID="your-account-id-here"运行服务器:
uv run newrelic_logs_server.py代码结构
服务器实现:
单一 NRQL 查询工具
可配置的 New Relic 帐户 ID
全面的错误处理
详细日志记录
响应格式
测试变更
根据需要修改代码
使用 MCP Inspector 进行测试
重新启动 Claude Desktop 以应用更改
故障排除指南
服务器未启动:
检查 Python 版本
验证所有依赖项均已安装
确保虚拟环境已激活
查询不起作用:
检查日志以获取详细的错误消息
验证 NRQL 语法
确保查询的时间范围内存在数据
克劳德未连接:
验证配置文件语法
检查路径是否绝对
重启Claude桌面
贡献
分叉存储库
创建功能分支
提交拉取请求
执照
该项目已获得 MIT 许可。
支持
如果您遇到问题:
检查日志
查看常见问题部分
使用 MCP Inspector 进行测试
在 GitHub 上提交问题
Available Tools
1 toolquery_logsB
Query New Relic logs using NRQL.
Args: query: NRQL query string (e.g., "SELECT * FROM Transaction") account_id: New Relic account ID (default from env var)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| account_id | No | 1234567 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and largely drops it. It never states that this is a read-only operation, whether results are limited or paginated, what time range NRQL defaults to, or what auth/scope is required for the account.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and front-loaded with the core action in the first sentence, followed by a compact arg list. The docstring-style 'Args:' block is a bit ceremonial but each line carries parameter information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter query tool with no output schema and no annotations, the description covers the parameters adequately but omits result shape, row/result limits, and pagination behavior. It is minimally viable rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does: 'query' is explained as an NRQL string with a concrete example, and 'account_id' is described as taking a default from an environment variable. This is meaningful context the bare schema lacks, though the example query targets 'Transaction' rather than a log table, which is slightly off for a log tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Query New Relic logs using NRQL'), which is unambiguous about what the tool does. There are no sibling tools to differentiate from, so 5 is not reachable, but the purpose itself is crisp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says the tool uses NRQL but gives no guidance on when to use it versus other retrieval tools, no prerequisites, and no exclusions. An agent gets the mechanism but not the selection criteria.
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.
1 tool update
v0.1.0- First observed
query_logs
TDQS
Scored across 1 tool
With only one tool, there is no possibility of overlap or misselection; its purpose (querying logs via NRQL) is unambiguous.
The single name query_logs follows a clean verb_noun snake_case convention that would scale predictably if more tools were added.
One tool is far too few for a platform like New Relic, which spans logs, metrics, APM, alerts, and dashboards; the surface feels like a stub rather than a server.
Only log querying is exposed, with no metric queries, APM data, alert/incident retrieval, or account/resource listing, leaving major observability workflows unreachable.
Maintenance
Related MCP Connectors
A Model Context Protocol server for Wix AI tools
Access New Relic observability data through MCP - query metrics, logs, traces, entities, and more
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
Related MCP Servers
- FlicenseCqualityDmaintenanceA Model Context Protocol server that enables searching and retrieving information from DevRev using its APIs with Claude.23-
- AlicenseBqualityNot gradedmaintenanceA Model Context Protocol server that enables AI assistants to interact with Datadog's observability platform through natural language.72MIT
- AlicenseBqualityCmaintenanceEnables natural language access to New Relic for monitoring, querying, and managing dashboards, entities, alerts, and deployments via the Model Context Protocol.529MIT
- FlicenseCqualityDmaintenanceMCP server allowing AI agents to query New Relic for debugging incidents.2-