Connect New Relic to Claude: Control Monitoring and Team Access

If you need to give your AI assistants access to observability data, system telemetry, and incident management controls, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between an AI model's JSON-RPC tool calls and New Relic's underlying API infrastructure. If your team uses ChatGPT, check out our guide on connecting New Relic to ChatGPT or explore our architectural overview on connecting New Relic to AI Agents.

Giving a Large Language Model (LLM) read and write access to a sprawling observability platform like New Relic is an engineering challenge. You are not just building a simple REST wrapper - you are dealing with fragmented data models, complex GraphQL schemas, and strict entity identification rules. Every time an endpoint changes or you need to expose a new metric type, you have to update your custom server code, test the tool schemas, and redeploy.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for New Relic, connect it natively to Claude, and execute complex DevOps and IT administration workflows using natural language.

The Engineering Reality of the New Relic API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, the reality of implementing it against New Relic is painful.

If you decide to build a custom MCP server for New Relic, you own the entire API lifecycle. Here are the specific challenges you will face:

The NerdGraph GraphQL Divide New Relic has aggressively pushed developers toward NerdGraph, their central GraphQL API. Exposing a GraphQL API to an LLM via MCP is notoriously difficult. LLMs struggle to reliably generate valid GraphQL abstract syntax trees (ASTs) or complex nested mutations from scratch. If you build this yourself, you have to write an entire translation layer that takes flat JSON inputs from the LLM and dynamically constructs syntactically perfect GraphQL queries. Truto solves this by exposing New Relic's resources as flattened, REST-like proxy operations, allowing Claude to interact with simple query and body schemas while Truto handles the complex NerdGraph translations behind the scenes.

Complex Entity GUIDs and Typology New Relic relies heavily on Entity GUIDs - massive base64-encoded strings that dictate the domain, type, and specific identifier of a monitored resource. An LLM cannot simply ask for "Dashboard 12". It needs the exact entity GUID. Building a custom MCP means you have to write custom search and retrieval logic to ensure the LLM can resolve human-readable names into strict GUIDs before executing operations. Truto's standardized search and list methods give Claude the explicit instructions it needs to fetch and retain these GUIDs across context windows.

Strict NRQL Validation Rules When querying metrics or configuring dashboards, New Relic requires valid New Relic Query Language (NRQL). If an LLM passes malformed NRQL in a JSON payload, New Relic returns highly specific parsing errors. A custom MCP server must parse these errors and return them to the LLM in a format it can understand to self-correct.

Rate Limits and 429 Handling New Relic enforces strict rate limits across its APIs, particularly for heavy analytical queries or bulk entity requests. It is critical to understand that Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream New Relic API returns an HTTP 429 Too Many Requests error, Truto passes that error directly to the caller. Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. The caller (in this case, your AI agent framework or Claude client logic) is fully responsible for implementing retry and exponential backoff mechanisms. Do not assume the integration layer will absorb these errors for you.

Instead of building and maintaining this infrastructure from scratch, you can use Truto to dynamically generate a secure, authenticated MCP server URL that maps New Relic's capabilities into predictable, LLM-ready tools.

How to Generate a New Relic MCP Server with Truto

Truto dynamically generates MCP tools from an integration's resource definitions and schema documentation. Tools are never cached or pre-built. They are derived in real-time based on the exact configuration you request.

Each MCP server is scoped to a single connected New Relic account. The server URL contains a cryptographically hashed token that encodes the account routing, the allowed tools, and the expiration window.

You can generate this server via the Truto UI or programmatically via the API.

Method 1: Via the Truto UI

If you are setting up an internal agent for your DevOps team, generating the server from the dashboard is the fastest path.

1. Navigate to the Integrated Accounts page in your Truto dashboard and select your connected New Relic account.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Configure your server constraints. You can name it (e.g., "Production Ops Agent"), filter by methods (e.g., allowing only read methods to prevent accidental deletions), and set an expiration date.
5. Click Create and immediately copy the generated MCP server URL. You will need this to configure Claude.

Method 2: Via the API

If you are building an AI product and need to provision New Relic MCP servers dynamically for your users, you should use the Truto API. The API generates a secure token, registers it in a distributed key-value store, and returns a ready-to-use endpoint.

Make a POST request to /integrated-account/:id/mcp:

curl -X POST https://api.truto.one/integrated-account/<NEW_RELIC_ACCOUNT_ID>/mcp \
  -H "Authorization: Bearer <YOUR_TRUTO_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "New Relic Triage Agent",
    "config": {
      "methods": ["read", "list"],
      "tags": ["observability", "dashboards"]
    },
    "expires_at": "2025-12-31T23:59:59Z"
  }'

The response contains the secure URL you will pass to your MCP client:

{
  "id": "mcp-nr-789",
  "name": "New Relic Triage Agent",
  "config": { 
    "methods": ["read", "list"], 
    "tags": ["observability", "dashboards"]
  },
  "expires_at": "2025-12-31T23:59:59Z",
  "url": "https://api.truto.one/mcp/t8k2m5n9p4q1r7s..."
}

Connecting the MCP Server to Claude

Once you have your Truto MCP URL, connecting it to Claude is a matter of configuration. The MCP server operates as an SSE (Server-Sent Events) endpoint, handling the JSON-RPC 2.0 protocol natively.

Method A: Via the Claude UI

If you are using the Claude desktop or web application with custom connector support:

1. Open Claude and navigate to Settings.
2. Locate the Integrations or Connectors section.
3. Click Add MCP Server or Add custom connector.
4. Enter a name for your connection (e.g., "New Relic Systems").
5. Paste the URL you copied from Truto.
6. Click Add.

Claude will immediately execute an initialize handshake and request the tools/list endpoint. The available New Relic tools will populate in the Claude interface automatically.

Method B: Via Manual Config File (Claude Desktop)

For developers running Claude Desktop locally who want strict control over their environment, you can modify the claude_desktop_config.json file directly.

Locate your configuration file:

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json

Add the Truto server using the official MCP SSE transport command:

{
  "mcpServers": {
    "new_relic_ops": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/t8k2m5n9p4q1r7s..."
      ]
    }
  }
}

Restart Claude Desktop. The application will boot the SSE client and discover the New Relic tool schema.

Security and Access Control

Giving an LLM access to your observability stack requires strict boundaries. Truto provides four mechanisms to lock down your MCP servers:

• Method Filtering: Restrict tools by their REST equivalent. Setting methods: ["read"] exposes only get and list tools, preventing the LLM from deleting workloads or creating faulty alert policies.
• Tag Filtering: Group tools functionally. Setting tags: ["users", "teams"] restricts the agent to identity and access management tools, completely blinding it to dashboards or synthetic monitors.
• Expiration Windows: The expires_at field enforces a hard time-to-live. Once the timestamp passes, the distributed key-value store purges the token, and the URL instantly returns a 401 Unauthorized.
• API Token Enforcement: By setting require_api_token_auth: true during creation, the server URL alone is no longer enough to execute tools. The MCP client must also pass a valid Truto API token in the Authorization header. This prevents leaked URLs from being exploited in unauthorized environments.

Hero Tools for New Relic Automation

The true power of this integration lies in the normalized proxy endpoints Truto provides. These endpoints handle pagination natively via cursors and flatten complex nested schemas into predictable JSON objects.

Here are the highest-leverage tools available to Claude when connected to New Relic.

List All Dashboards

Tool Name: list_all_new_relic_dashboard

Dashboards are the visual source of truth for system health. This tool retrieves the GUIDs, names, and account associations for every dashboard visible to the authenticated user. Because New Relic environments often contain hundreds of dashboards, Truto normalizes the pagination limits to prevent context window overflow.

"Fetch the first 20 dashboards in our New Relic account and return their names and GUIDs. If there is a dashboard with 'Production API' in the name, tell me."

Get Specific Dashboard Configuration

Tool Name: get_single_new_relic_dashboard_by_id

Once Claude identifies a dashboard GUID, it can pull the full configuration matrix using this tool. This includes metadata, page layouts, widget details, and the underlying NRQL queries powering the visualizations. This is incredibly useful for auditing what a dashboard is actually measuring.

"Look up the dashboard with GUID 'MzQ1Njc4OXxWSVp8REFTSEJPQVJEfDEyMzQ1' and analyze the NRQL queries used in its widgets. Are any widgets querying the old 'TransactionError' events instead of 'Log'?"

List All Alert Policies

Tool Name: list_all_new_relic_alert_policies

Alert policies define how incidents are grouped and triggered. This tool lists all configured policies, allowing an AI agent to audit incident preferences or search for specific alerting rules without requiring manual UI navigation.

"Retrieve all alert policies in the account. Filter the list to show me only the policies that have their incident preference set to 'PER_CONDITION_AND_TARGET'."

Manage Synthetic Monitors

Tool Name: list_all_new_relic_synthetic_monitors

Synthetic monitors (pings, API tests, browser scripts) validate system uptime. This tool extracts the configuration state of all synthetic monitors. By feeding this data into Claude, you can quickly identify disabled monitors or check coverage gaps across specific geographies.

"List all of our synthetic monitors. Identify any monitors that are checking the '/healthz' endpoint and verify if they are currently enabled."

Audit User Directory

Tool Name: list_all_new_relic_users

New Relic licensing is often tied to user tiers (Basic, Core, Full). Managing these tiers is a tedious administrative chore. This tool allows Claude to pull the entire user directory, making it trivial to audit who has elevated access or generate compliance reports for offboarding.

"Generate a list of all active users in the New Relic account. Group them by their user type tier (e.g., BASIC_USER_TIER vs FULL_USER_TIER) so we can review our licensing costs."

For the complete inventory of available New Relic tools, including data partition rules, team management, and metric normalization schemas, refer to the New Relic integration page.

Workflows in Action

MCP tools transform Claude from a passive chatbot into an active participant in your engineering operations. Here is how these tools chain together to execute real-world tasks.

Scenario 1: Automated Incident Triage

When an alert fires, a DevOps engineer needs to quickly assess the blast radius. Instead of clicking through five different New Relic screens, they can ask Claude to synthesize the context.

User: "We just received an alert about elevated latency. Check our synthetic monitors to see if any API tests are failing, then look up the 'Core API Health' dashboard to see what the NRQL queries are reporting."

Execution Steps:

1. Claude calls list_all_new_relic_synthetic_monitors to check the configuration and status of the ping and API monitors.
2. Claude calls list_all_new_relic_dashboard and filters the response to find the GUID for "Core API Health".
3. Claude calls get_single_new_relic_dashboard_by_id using that GUID to read the widget logic.
4. Claude interprets the data and replies: "Your synthetic monitor 'Checkout API Ping' is currently reporting issues. I reviewed the 'Core API Health' dashboard (GUID: MzQ...), and the NRQL query for the latency widget shows a spike in the p99 metric over the last 10 minutes."

graph TD
    A[User Prompt] --> B[Claude parses intent]
    B --> C{MCP Tool Call}
    C --> D[list_all_new_relic_synthetic_monitors]
    C --> E[list_all_new_relic_dashboard]
    E --> F[Extract Dashboard GUID]
    F --> G[get_single_new_relic_dashboard_by_id]
    D --> H[Synthesize Data]
    G --> H
    H --> I[Final LLM Response]

Scenario 2: IT Access Offboarding

When an employee leaves, IT administrators must revoke access across dozens of platforms. New Relic is often overlooked until an audit occurs. Claude can automate this safely.

User: "We are offboarding Sarah Jenkins. Please find her user record in New Relic, verify her current role, and then delete her account."

Execution Steps:

1. Claude calls list_all_new_relic_users to retrieve the directory and filters for "Sarah Jenkins".
2. Claude extracts Sarah's internal New Relic User ID.
3. Claude calls get_single_new_relic_user_by_id to confirm her email and current user tier to log the historical state before deletion.
4. Claude calls delete_a_new_relic_user_by_id passing the confirmed ID.
5. Claude replies: "I have located Sarah Jenkins (sarah@company.com). She was on a FULL_USER_TIER. I have successfully executed the deletion command. Her access is revoked."

Moving Past Manual Observability Ops

Connecting Claude to New Relic via MCP fundamentally changes how engineering teams interact with observability data. You no longer have to navigate complex UIs to check licensing tiers, audit alert policies, or hunt down the specific NRQL query breaking a dashboard.

By leveraging Truto's managed infrastructure, you bypass the friction of writing GraphQL parsers, managing OAuth tokens, and writing pagination loops. You get immediate, LLM-ready tool schemas that adhere strictly to the constraints you define.