newrelic-mcp-nerdgraph
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NEW_RELIC_REGION | No | `US` or `EU` | US |
| NEW_RELIC_API_KEY | Yes | User API key | |
| NEW_RELIC_ACCOUNT_IDS | No | Comma-separated defaults, e.g. `123,456` | |
| NEW_RELIC_MAX_RETRIES | No | Retries on 429/5xx | 3 |
| NEW_RELIC_DEFAULT_SINCE | No | Time window added to NRQL without one | 30 MINUTES AGO |
| NEW_RELIC_MAX_RESULT_ROWS | No | `LIMIT` added to NRQL without one | 200 |
| NEW_RELIC_ENABLE_MUTATIONS | No | Allow write operations | false |
| NEW_RELIC_MAX_RESPONSE_CHARS | No | Byte budget per tool response | 100000 |
| NEW_RELIC_ENABLE_RAW_NERDGRAPH | No | Expose the arbitrary-GraphQL tool | false |
| NEW_RELIC_QUERY_TIMEOUT_SECONDS | No | Server-side NRQL timeout | 30 |
| NEW_RELIC_REDACT_SENSITIVE_VALUES | No | Mask credential-shaped strings in output | true |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| run_nrqlA | Run a NRQL query against one or more New Relic accounts. This is the general-purpose data tool: anything stored as events, metrics, logs or spans can be reached from here. Prefer the dedicated tools (search_logs, get_trace, get_recent_errors) when they fit, because they return a shape tuned for that use case. |
| run_nrql_asyncA | Run a NRQL query that exceeds the synchronous timeout, polling until it finishes. Use this for wide time windows (days or weeks) or heavy aggregations. It is slower than run_nrql, so it is not the default choice. |
| validate_nrql_queryA | Check a NRQL query against the server guardrails without running it. Returns the query as it would actually be sent, including the SINCE and LIMIT clauses that get appended automatically. |
| search_entitiesA | Find entities (services, hosts, lambdas, browsers) by name, type or tag. Start here when you only know a service name: the returned GUID is the key for get_entity, logs and alert lookups. |
| get_entityA | Get one entity with its tags, golden metrics and relationships. The golden metrics include the NRQL New Relic itself uses for that entity type, which you can run as-is through run_nrql. |
| list_open_issuesA | List alert issues, by default the ones currently active. Each issue carries the entity GUIDs involved, which is the usual entry point for an on-call investigation. |
| list_alert_policiesC | List alert policies for an account. |
| list_nrql_conditionsB | List NRQL alert conditions, including their queries and thresholds. Reading the condition's own NRQL is the fastest way to reproduce what an alert saw at the time it fired. |
| search_logsA | Search logs by service, level, trace id or message content. Returns the newest matches first. Credential-shaped values in log messages are masked before the result leaves the server. |
| summarize_log_errorsA | Group error logs by message pattern to show what is failing most. Prefer this over search_logs when the question is "what is broken" rather than "show me this specific request". |
| get_traceA | Get the spans of one distributed trace, in chronological order. Pair this with search_logs on the same trace_id to see the request path and its log lines together. |
| get_recent_errorsC | Show recent transaction errors grouped by error class. |
| list_deploymentsA | List recent deployments, newest first. Use this to check whether an incident lines up with a release before digging into traces. |
| compare_metric_windowsB | Compare an aggregate against the same window in the past. The baseline makes a regression visible as a delta, which is usually more conclusive than an absolute value taken on its own. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| investigate_incident | Guide an end-to-end investigation of an alert, service or trace id. |
| write_nrql | Turn a plain-language question into a validated NRQL query. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| nrql_cheatsheet | NRQL syntax, common event types and query patterns. |
| investigation_playbook | Step-by-step incident investigation flow using this server's tools. |
| server_config | Non-sensitive view of the active configuration. |
TDQS
Scored across 14 tools
Most tools target clearly distinct resources or actions (entities, traces, logs, deployments, alerts). The main overlap is between general-purpose run_nrql/run_nrql_async/validate_nrql_query and specialized tools like search_logs, summarize_log_errors, and get_recent_errors, but the descriptions give useful selection guidance.
All tool names follow a predictable snake_case verb_noun pattern: get_entity, run_nrql, search_logs, list_open_issues, compare_metric_windows, etc. There are no mixed conventions or ambiguous abbreviations.
With 14 tools, the set is well-scoped for New Relic investigation workflows. Each tool appears to earn its place across entity lookup, NRQL execution, logs, traces, errors, alerts, deployments, and metric comparison.
The surface covers the core read-oriented investigation lifecycle: entities, NRQL, logs, traces, errors, alerts, deployments, and metric baselines. Some administrative or authoring operations (e.g. creating/updating alert policies or dashboards) are absent, but those may be outside this server's intended scope.