New Relic
New Relic is a comprehensive observability platform that helps developers and operations teams monitor, debug, and improve their entire stack, including applications, infrastructure, and customer experience.
Verdict
Common use cases
- Check alert policy status during incidents
- Create notification channels from standup chat
- List all monitored apps before deployments
- Delete obsolete alert policies in bulk
- Audit alert conditions across environments
Integration
- Vendor
- New Relic
- Category
- other
- Auth
- API_KEY
- Tools
- 9
- Composio slug
new_relic
Tools
- Create Alert Notification Channel
Tool to create an alert notification channel. use when you need to register a new endpoint (email, webhook, etc.) for alert notifications.
- Create Alert Policy
Tool to create an alert policy. use when you need to programmatically set up a new alert policy in new relic.
- Delete alert policydestructive
Tool to delete an existing alert policy via rest api. use when you have the policy id and want to remove it via new relic's rest api. use after confirming the policy id exists.
- Get Alert Channels
Tool to retrieve a list of alert notification channels. use when you need to list all configured channels after verifying your api key.
- Get Alert Conditions
Tool to retrieve alert conditions for a specified policy. use after you have the policy id.
- Get Alert Policies
Tool to retrieve a list of alert policies. use when you need to list existing alert policies with optional filtering and pagination.
- Get Applications
Tool to retrieve a list of new relic applications. use when you need to list all applications or filter by name, host, or ids after authenticating your api key.
- Get Browser Applications
Tool to list new relic browser applications. use when you need to retrieve all browser applications or filter by name after authenticating your api key.
- Update Alert Notification Channel
Tool to update an existing new relic alert notification channel. use when you need to modify channel settings after verifying its id.
Setup
Setup guide
- 11. In Switchy, open your workspace settings and navigate to the MCP Integrations page. 2. Click 'Add Integration' and select New Relic from the catalog. 3. In a separate tab, log into New Relic and go to Account Settings → API Keys. 4. Generate a new REST API key with permissions for Alerts and APM (both read and write if you plan to create or delete policies). 5. Copy the key and paste it into the API Key field in Switchy, then click 'Connect'. 6. Switchy will validate the key by fetching your application list; if successful, you'll see a green checkmark. 7. Open any Space, type '@New Relic get applications', and send — you should see a list of your monitored apps confirming the connection works. 8. From there, @mention New Relic anytime you need to inspect alerts or update policies in conversation.
What teammates see: by default, memories from New Relic are scoped to the Project (PROJECT visibility) - you can mark any memory PRIVATE or share it ORG-wide.
Works well with
Top models
Compatibility data appears once enough Projects have used this MCP together with a given model.
How Switchy teams use it
Starter prompts
List Active Alert Policies
@New Relic get alert policies and show me the policy names and IDs for all active policies in our account
Create Incident Notification Channel
@New Relic create an alert notification channel named 'Oncall Slack' with type 'slack' and webhook URL https://hooks.slack.com/services/example
Inspect App Performance Metrics
@New Relic get applications and include the application name, health status, and last reported timestamp for each
Retrieve Conditions for Policy
@New Relic get alert conditions for policy ID 123456 and list the condition names, types, and thresholds
Clean Up Deprecated Policy
@New Relic delete alert policy with ID 789012 and confirm once the deletion is complete
Example outputs
Illustrative - representative of the model's voice and quality, not literal recordings.
@newrelic list all alert policies currently active in our account, and show me which ones have conditions targeting our production apps
Found 12 alert policies in your New Relic account. Five policies target production applications: 'Production API Latency' (3 conditions on checkout-api), 'Database Performance' (2 conditions on postgres-prod), 'Frontend Error Rate' (4 conditions on web-app-prod), 'Memory Threshold Alerts' (1 condition on worker-pool-prod), and 'Transaction Failures' (2 conditions on payment-service). The remaining seven policies monitor staging and development environments. Each policy ID and its associated application IDs are included in this summary.
This example demonstrates read-heavy querying across policies and conditions. The MCP requires a valid API key with read permissions for alerts and applications. Response time depends on the number of policies in your account; accounts with 100+ policies may see slower retrieval.
@newrelic create a new alert policy called 'API Gateway Overload' with an email notification channel to ops@company.com whenever response time exceeds 2 seconds
Created alert policy 'API Gateway Overload' (policy ID: 8472639). Registered email notification channel 'ops-team-email' targeting ops@company.com (channel ID: 3847261). Note that you'll need to separately create an alert condition linking this policy to a specific application and defining the 2-second response time threshold—this MCP handles policy and channel setup, but condition creation requires additional tool calls with application IDs and metric specifications.
This write-heavy example shows policy and channel creation. The MCP performs two API calls but does not automatically create the condition itself—you must follow up with a condition-creation request. API key needs write permissions for alert policies and channels. Changes take effect immediately in New Relic's alerting system.
@newrelic review all browser applications we're monitoring and identify which ones have no associated alert policies, then recommend what alerts we should set up
Retrieved 8 browser applications. Four have no alert policies: 'marketing-landing-page', 'customer-portal-beta', 'docs-site', and 'internal-dashboard'. Based on typical browser monitoring needs, I recommend creating policies for: (1) JavaScript error rate thresholds on marketing-landing-page and customer-portal-beta, since user-facing apps benefit from error alerting; (2) Page load time alerts on docs-site to catch performance regressions; (3) AJAX failure rate monitoring on internal-dashboard to detect API connectivity issues. Each recommendation includes suggested thresholds based on New Relic's best practices for browser application monitoring.
This synthesis example pairs the MCP's data retrieval with AI reasoning to surface gaps and generate recommendations. The MCP fetches raw application and policy data; the AI interprets coverage gaps and suggests actionable next steps. Recommendations are illustrative—actual thresholds should reflect your application's baseline performance metrics.
Use-case deep-dives
When New Relic MCP streamlines on-call transitions
A 6-person SRE team runs 24-hour on-call rotations across three time zones. At shift change, the outgoing engineer needs to brief the incoming one on active alerts, policy changes, and which services are flapping. The New Relic MCP wins here because it lets the AI pull current alert policies, list notification channels, and surface application health in one conversational pass—no context-switching between Slack, the New Relic UI, and a handoff doc. The 9 tools cover the full alert lifecycle, so the AI can answer "what policies did we add this week" or "which channels fire for the payments service" without the engineer opening a browser. This works best when your alert catalog is under 50 policies; beyond that, the list-all tools get noisy and you'll want filtered queries the MCP doesn't yet expose. If your team does structured handoffs twice a day and alert hygiene matters, this MCP cuts 10 minutes per transition.
New Relic MCP for cleaning up alert noise after incidents
A 5-person product team ships weekly and inherits a messy alert setup—duplicate policies, orphaned notification channels, conditions that fire on every deploy. After a customer-facing incident, the PM wants to audit what fired, delete stale policies, and consolidate channels before the next sprint. The New Relic MCP is the right call because it exposes the full CRUD surface for policies and channels, so the AI can list everything, compare against the team's Notion runbook, and execute deletions in a single thread. The "Get Alert Conditions" and "Delete Alert Policy" tools mean you're not clicking through the New Relic UI to find policy IDs or second-guessing which webhook still matters. This scenario assumes you have API key access and fewer than 30 policies to review; if you're managing hundreds of policies across business units, you need New Relic's Terraform provider instead. For small teams doing quarterly alert cleanups, this MCP turns a 2-hour chore into a 20-minute AI-guided session.
When New Relic MCP helps support look up service health
A 3-person support team at a B2B SaaS company fields tickets about slow page loads and API timeouts. They don't have New Relic UI access—only the eng team does—but they need to know if an alert fired or if a specific application is degraded before escalating to engineering. The New Relic MCP is borderline useful here. It lets the AI query "Get Applications" and "Get Browser Applications" to confirm service status, and "Get Alert Policies" to check if engineering already knows about the issue. The limitation: the MCP has no read-only observability tools (no metrics, no traces, no error rates), so the AI can only report on alert state, not actual performance data. If your support team needs to say "yes, checkout latency spiked 10 minutes ago," this MCP won't get you there. But if the question is "did an alert fire for the payments service," it works. Best fit: small teams where support needs alert awareness, not full observability access.
Frequently asked
What can the New Relic MCP do in Switchy?
It lets your team create and manage New Relic alert policies, notification channels, and conditions without leaving the AI workspace. You can also list applications and browser apps to see what's being monitored. Think of it as programmatic access to New Relic's alerting setup — useful when you're troubleshooting incidents or adjusting thresholds based on conversation context.
Do I need admin access to connect New Relic?
You need a New Relic API key with permissions to read applications and manage alerts. The MCP uses API_KEY auth, so whoever connects it must generate a key from their New Relic account settings. If your team restricts who can create or delete alert policies, make sure the key's owner has those rights — otherwise tool calls will fail.
Can the New Relic MCP query APM metrics or logs?
No. This MCP focuses on alert policy management and listing applications. It won't fetch transaction traces, error rates, or NRQL query results. If you need to pull metrics or logs into Switchy, you'll have to use New Relic's GraphQL API separately or wait for a more comprehensive MCP.
Why use this instead of the New Relic web UI?
The MCP is faster when you're already in a Switchy conversation about an incident. Instead of context-switching to the New Relic UI, you can create a notification channel or adjust a policy threshold in the same thread where you're diagnosing the problem. It's not a replacement — it's a shortcut for the tasks you do repeatedly during on-call.
Who on the team should connect the New Relic MCP?
Whoever owns your on-call runbooks or manages alerting config. They'll need to generate the API key and keep it valid. If multiple people need access, connect it once in a shared Switchy workspace — everyone in that workspace can then invoke the tools without needing their own key.