The New Relic MCP Server provides comprehensive integration with New Relic's observability platform, enabling you to monitor, query, and manage your entire infrastructure through a unified interface.
Data Querying & Analysis
Execute NRQL queries to analyze metrics, events, and logs
Run custom NerdGraph GraphQL queries for direct API access
Retrieve metric timeslice data for application hosts with customizable time ranges and aggregations
List available metric names and values for specific hosts
APM (Application Performance Monitoring)
List applications via NerdGraph or REST v2 APIs with filtering by name, host, IDs, or language
View application hosts with filtering capabilities
Manage deployments: create, list, and delete deployment markers to track releases
Monitor application health and performance through entity queries
Entity Management
Search and inspect entities by name, type, or tags across your infrastructure
Get detailed entity information using entity GUIDs
Filter by entity type (applications, hosts, databases, etc.)
Retrieve account details and metadata
Alerts & Incident Management
List alert policies via NerdGraph or REST v2 APIs
View open incidents with filtering by priority (CRITICAL, HIGH, MEDIUM, LOW)
Acknowledge incidents to manage alert workflows
Synthetics Monitoring
List Synthetics monitors with filtering by type (SIMPLE, BROWSER, SCRIPT_API, SCRIPT_BROWSER)
Create browser-based monitors to track website availability and performance
Configure monitoring locations and frequencies
Advanced Features
Multi-region support (US and EU data centers)
Auto-pagination for large result sets
Flexible filtering on multiple dimensions
Account-level isolation with optional multi-account targeting
Provides comprehensive integration with New Relic's observability platform, enabling NRQL queries, APM application monitoring, alert and incident management, entity search across infrastructure, synthetics monitoring, deployment tracking, and access to both NerdGraph GraphQL and REST v2 APIs for complete observability stack management.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@New Relic MCP Server show me the top 5 slowest transactions from the last hour"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides seamless integration with New Relic's observability platform. Query metrics, manage alerts, monitor applications, and interact with your entire observability stack through a simple, unified interface.
Disclaimer: This is an unofficial community project and is not affiliated with, endorsed by, or supported by New Relic, Inc. All trademarks are the property of their respective owners.
📊 NRQL Queries - Execute powerful queries to analyze your data
🚀 APM Integration - Monitor application performance and health
🔔 Alert Management - View and acknowledge alerts and incidents
🔍 Entity Search - Discover and inspect entities across your infrastructure
📈 Synthetics Monitoring - Manage synthetic monitors and checks
🔧 NerdGraph API - Direct access to New Relic's GraphQL API
🌐 REST v2 Tools (2.0+) - High‑value REST endpoints for deployments, APM apps, metrics, and alerts
Related MCP server: New Relic NerdGraph MCP Server
To install or deploy via Smithery, see the official docs: Deployments, Project Configuration, and smithery.yaml Reference.
To install New Relic MCP for Claude Desktop automatically via Smithery:
npx @smithery/cli install @cloudbring/newrelic-mcp --client claudeWe recommend the Smithery CLI for local development, inspection, and deployment flows. Benefits:
Unified dev/build/deploy workflow, client‑agnostic
Dev server with hot‑reload and playground (optional tunnel)
Build bundles for stdio or shttp transports
Inspect a server interactively; run with supplied config
Simple install per client
Examples:
# Hot‑reload dev server
npx @smithery/cli dev src/server.ts --port 8181 --no-open
# Build production bundle (shttp transport)
npx @smithery/cli build src/server.ts --out .smithery/index.cjs --transport shttp
# Inspect a published server
npx @smithery/cli inspect @cloudbring/newrelic-mcp
# Run with config (env via JSON)
npx @smithery/cli run @cloudbring/newrelic-mcp --config '{"NEW_RELIC_API_KEY":"...","NEW_RELIC_ACCOUNT_ID":"...","NEW_RELIC_REGION":"US"}'
# Install into a specific client
npx @smithery/cli install newrelic-mcp --client claude
# Open playground
npx @smithery/cli playground --port 3001Notes:
This repo includes a minimal smithery.yaml with runtime: "typescript" to align with TypeScript‑first deployments.
See the CLI reference for all commands and flags: smithery-ai/cli.
Add to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"newrelic": {
"command": "npx",
"args": [
"-y",
"newrelic-mcp"
],
"env": {
"NEW_RELIC_API_KEY": "your-api-key-here",
"NEW_RELIC_ACCOUNT_ID": "your-account-id",
"NEW_RELIC_REGION": "US"
}
}
}
}Add to your Cline settings in VS Code:
{
"cline.mcpServers": [
{
"name": "newrelic",
"command": "npx",
"args": ["-y", "newrelic-mcp"],
"env": {
"NEW_RELIC_API_KEY": "your-api-key-here",
"NEW_RELIC_ACCOUNT_ID": "your-account-id",
"NEW_RELIC_REGION": "US"
}
}
]
}Add to your Zed configuration file at ~/.config/zed/settings.json:
{
"language_models": {
"mcp": {
"servers": {
"newrelic": {
"command": "npx",
"args": ["-y", "newrelic-mcp"],
"env": {
"NEW_RELIC_API_KEY": "your-api-key-here",
"NEW_RELIC_ACCOUNT_ID": "your-account-id"
}
}
}
}
}
}Add to your Windsurf Cascade configuration:
{
"mcpServers": {
"newrelic": {
"command": "npx",
"args": ["-y", "newrelic-mcp"],
"env": {
"NEW_RELIC_API_KEY": "your-api-key-here",
"NEW_RELIC_ACCOUNT_ID": "your-account-id",
"NEW_RELIC_REGION": "US"
}
}
}
}Clone the repository:
git clone https://github.com/cloudbring/newrelic-mcp.git
cd newrelic-mcpInstall dependencies and build:
npm install
npm run buildAdd to your MCP client configuration:
{
"mcpServers": {
"newrelic": {
"command": "node",
"args": ["/path/to/newrelic-mcp/dist/server.js"],
"env": {
"NEW_RELIC_API_KEY": "your-api-key-here",
"NEW_RELIC_ACCOUNT_ID": "your-account-id",
"NEW_RELIC_REGION": "US"
}
}
}
}NEW_RELIC_API_KEY - Your New Relic User API Key (required)
NEW_RELIC_ACCOUNT_ID - Your New Relic Account ID (optional, can be provided per tool call)
NEW_RELIC_REGION - New Relic data center region: US (default) or EU (optional)
API Key:
Log in to New Relic
Navigate to API Keys in the left sidebar
Create a new User API Key with appropriate permissions
Account ID:
Find your Account ID in the URL when logged into New Relic
Or navigate to Administration → Access management → Accounts
Region:
Set NEW_RELIC_REGION=US for US data center (default)
Set NEW_RELIC_REGION=EU for EU data center
If not specified, defaults to US
For detailed setup instructions, see docs/new-relic-setup.md.
Once configured, you can interact with New Relic through your MCP client:
"Show me the average response time for my web application over the last hour"
"What are the top 10 slowest database queries today?"
"Display error rate trends for the production environment""List all my APM applications and their current status"
"Show me the health of my Node.js services"
"Which applications have active alerts?""Show me all open incidents"
"What critical alerts fired in the last 24 hours?"
"Acknowledge incident #12345""Find all Redis databases in production"
"Show me entities with high CPU usage"
"List all synthetic monitors and their success rates"Below is a concise catalog of all MCP tools exposed by this server. See the docs folder for detailed stories/specs.
Tool | Summary |
| Execute NRQL queries (requires |
| Execute raw NerdGraph GraphQL queries |
| List APM applications via NerdGraph |
| Search entities (name, type, tags) |
| Fetch details for a GUID |
| List alert policies via NerdGraph |
| List open incidents via NerdGraph |
| Acknowledge an incident (NerdGraph only) |
| List Synthetics monitors |
| Create a browser monitor |
| Fetch account metadata |
Tool | Summary | Notes |
| Create deployment marker for an APM application | Inputs: |
| List deployments for an app | Supports |
| Delete deployment marker | Requires |
| List APM apps via REST | Filters: |
| List metric names/values for host | Inputs: |
| Get timeslice metric data for host | Inputs: |
| List hosts for an APM app | Filters: |
| List alert policies via REST | Optional |
| List incidents via REST | Server has no |
References:
Detailed specs and schemas: docs/REST_ENDPOINT_TOOL.md and docs/rest-tools-stories/*
If you're having trouble connecting:
Verify your API key is valid:
For US region:
curl -X POST https://api.newrelic.com/graphql \
-H 'Content-Type: application/json' \
-H 'API-Key: YOUR_API_KEY' \
-d '{"query":"{ actor { user { email } } }"}'For EU region:
curl -X POST https://api.eu.newrelic.com/graphql \
-H 'Content-Type: application/json' \
-H 'API-Key: YOUR_API_KEY' \
-d '{"query":"{ actor { user { email } } }"}'Check that your Account ID is correct
Ensure your API key has the necessary permissions
Check the MCP client logs for detailed error messages
If you receive permission errors:
Verify your API key has the required permissions:
For NRQL queries: NRQL query permission
For APM data: APM read permissions
For alerts: Alerts read/write permissions
Create a new API key with broader permissions if needed
src/
├── server.ts # Main MCP server implementation
├── client/
│ └── newrelic-client.ts # New Relic API client
└── tools/
├── nrql.ts # NRQL query tool
├── apm.ts # APM applications tool
├── entity.ts # Entity management tools
├── alert.ts # Alert and incident tools
├── synthetics.ts # Synthetics monitoring tools
└── nerdgraph.ts # NerdGraph query toolClone the repository:
git clone https://github.com/cloudbring/newrelic-mcp.git
cd newrelic-mcpInstall dependencies:
npm installCreate a .env file:
NEW_RELIC_API_KEY=your-api-key-here
NEW_RELIC_ACCOUNT_ID=your-account-id
NEW_RELIC_REGION=USBuild the project:
npm run build# Start development server with hot reload
npm run dev
# Build for production
npm run build
# Run tests
npm test
# Run tests with coverage
npm run test:coverage
# Run linting
npm run lint
# Format code
npm run format
# Test server startup
npm run test:serverThe project uses Test-Driven Development (TDD) with:
Vitest for unit testing
Gherkin for BDD testing
Evalite for LLM response validation
# Run all tests
npm test
# Run with coverage
npm run test:coverage
# Run BDD tests only
npm run test:bdd
# Run integration tests with real API
USE_REAL_ENV=true npm testUse the MCP Inspector to test and debug the server:
# Run with MCP Inspector
npm run inspect
# Run with development server
npm run inspect:dev
# Run with environment variables
npm run inspect:envSee docs/mcp-inspector-setup.md for detailed instructions.
The server follows a modular architecture with:
Client Layer: Handles New Relic API communication
Tools Layer: Implements MCP tool specifications
Server Layer: Manages MCP protocol and tool routing
Each tool:
Has a single, focused purpose
Validates inputs using Zod schemas
Returns structured, typed responses
Includes comprehensive error handling
We welcome contributions! Please see our Contributing Guidelines for details.
Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Write tests first (TDD approach)
Implement your feature
Ensure all tests pass (npm test)
Maintain >90% code coverage
Run linting (npm run lint)
Commit your changes (commits will be auto-formatted)
Push to your branch
Open a Pull Request
This project uses:
Biome for linting and formatting
TypeScript with strict mode
2 spaces for indentation
Single quotes for strings
Semicolons always
New Relic Setup Guide - Detailed credential setup
MCP Inspector Setup - Testing and debugging
Logging & Telemetry - Test monitoring
Implementation Details - Architecture deep dive
REST tools overview - High‑level design for REST v2 tools
REST tool stories - Per‑tool specs, schemas, and test plans
We researched other public New Relic MCP servers and did not find any actively maintained, feature‑complete alternatives at the time of writing. If you know of one, please open an issue to add it here.
Project | Status | Transport(s) | Deployments | APM Apps | Metrics | Alerts | Synthetics | Notes |
This project (newrelic-mcp) | Active | NerdGraph + REST v2 | Create/List/Delete | List (NerdGraph + REST) | Host names + timeslices (REST) | Policies + Incidents (NG + REST) | List/Create (browser) | Comprehensive tests and docs |
Planned enhancements (based on REST v2 catalog and user demand):
Alerts: violations and conditions management via REST where available
Metrics: broader app‑level metrics endpoints (names/data) beyond per‑host
Additional REST coverage: labels, key transactions, mobile apps (prioritized by feedback)
This project is licensed under the MIT License - see the LICENSE file for details.
This project is not affiliated with, endorsed by, or supported by New Relic, Inc. It is an independent open-source project that uses New Relic's public APIs.
Built on the Model Context Protocol specification
Integrates with New Relic's observability platform APIs
Inspired by the broader MCP ecosystem
Made with ❤️ by @cloudbring using Cursor and Claude Code
Acknowledge an open incident
| Name | Required | Description | Default |
|---|---|---|---|
| incident_id | Yes | The ID of the incident to acknowledge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral transparency. It only states 'acknowledge' without detailing side effects (e.g., state changes, notifications) or permissions needed. This is insufficient for an action that likely modifies state.
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?
The description is a single efficient sentence with no wasted words. However, it could incorporate additional useful context without becoming verbose. Still, it is appropriately sized for a simple tool.
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?
Given no output schema and lack of behavioral details, the description is incomplete. It does not explain return values (e.g., success confirmation, error messages) or authentication/authorization prerequisites, leaving the agent underinformed.
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?
The schema covers 100% of parameters with descriptions, so baseline is 3. The description adds no additional meaning beyond what the schema already provides for 'incident_id'. It merely restates the tool's purpose.
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 'Acknowledge an open incident' clearly specifies the action (acknowledge) on a resource (incident), distinguishing it from sibling tools like list_open_incidents which list incidents. It is concise and unambiguous.
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?
The description provides no guidance on when to use this tool versus alternatives, such as when to acknowledge vs. close an incident, or any prerequisites. The agent receives no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new browser-based Synthetics monitor
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the monitor | |
| url | Yes | URL to monitor | |
| frequency | Yes | Check frequency in minutes | |
| locations | Yes | Location codes for monitoring | |
| target_account_id | No | Optional New Relic account ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose behavioral traits like side effects, idempotency, or authentication requirements. Simply stating it creates a monitor is insufficient.
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?
The description is a single, clear sentence with no wasted words. It is front-loaded with the verb and object.
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?
The description omits important details like return values, prerequisites, or error conditions. For a creation tool with no output schema, more context is needed.
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 description coverage is 100%, so the description adds no extra meaning beyond the parameter descriptions. Baseline score of 3 is appropriate.
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 clearly states the action ('Create') and the specific resource ('browser-based Synthetics monitor'), distinguishing it from sibling tools like list_synthetics_monitors.
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?
No guidance is provided on when to use this tool versus alternatives, such as other monitor creation tools or modification tools. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a deployment marker for an APM application (REST v2).
| Name | Required | Description | Default |
|---|---|---|---|
| application_id | Yes | ||
| revision | Yes | ||
| changelog | No | ||
| description | No | ||
| user | No | ||
| region | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must reveal behavioral traits. It only indicates creation, omitting side effects, idempotency, authorization needs, or output details. The lack of disclosure is a significant gap.
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?
The description is a single sentence, which is concise, but it omits critical information about parameters and usage. It is not front-loaded effectively, and the brevity comes at the cost of informativeness.
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?
Given the tool's complexity (6 parameters, no output schema, no annotations), the description is severely incomplete. It fails to cover parameter meanings, expected behavior, or any operational context necessary for correct invocation.
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%, and the description does not explain any of the six parameters (application_id, revision, changelog, description, user, region). The region enum is present in schema but unmentioned. The description adds no semantic value beyond the schema.
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 clearly states the tool creates a deployment marker for an APM application, specifying the REST API version. This verb+resource construction differentiates it from sibling tools like delete_deployment or list_deployments_rest.
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?
The description provides no guidance on when to use this tool versus alternatives, such as delete_deployment or list_deployments_rest. No context about prerequisites, limitations, or typical use cases is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a deployment record (REST v2). Requires admin role permissions.
| Name | Required | Description | Default |
|---|---|---|---|
| application_id | Yes | ||
| id | Yes | ||
| confirm | Yes | ||
| region | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Clearly indicates destructive nature ('Delete') and permission requirement. Without annotations, description is transparent about core behavior, though lacks details on reversibility or side effects.
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?
Single sentence with essential information front-loaded; no wasted words.
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?
Given 4 parameters, a required boolean 'confirm', and no output schema, description lacks sufficient detail for an agent to confidently invoke the tool without additional info.
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 description coverage is 0%, and the tool description provides no explanation of parameters (application_id, id, confirm, region). Agents cannot infer parameter meaning from description.
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?
Description clearly states the action ('Delete') and resource ('deployment record'), with API version noted. Distinguishes from siblings like create_deployment and list_deployments_rest.
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?
Mentions required admin role permissions but does not provide guidance on when to use this tool versus alternatives, nor exclusions or prerequisites beyond role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get New Relic account details
| Name | Required | Description | Default |
|---|---|---|---|
| target_account_id | No | Optional account ID to get details for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of explaining behavior. It only states 'Get' without indicating read-only nature, error handling, or permission requirements, which is insufficient for a tool that may have side effects or access controls.
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?
The description is a single, clear sentence with no extraneous content. It is appropriately concise for a simple tool, though it could benefit from slightly more detail without losing conciseness.
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?
Given the tool has one optional parameter and no output schema, the description is minimally adequate. It does not cover expected return values or error conditions, but the overall simplicity makes it sufficient for a basic get operation.
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 description coverage is 100%, so the schema already documents the optional target_account_id. The description adds no extra meaning beyond what the schema provides, earning a baseline score of 3.
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 clearly states the verb 'Get' and the resource 'New Relic account details', making the purpose understandable. It is distinct from siblings like get_entity_details, which targets different data. However, it could be more specific about what details are included.
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?
No guidance is provided on when to use this tool versus alternatives such as get_entity_details. The description does not include any context about prerequisites or typical use cases, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific entity
| Name | Required | Description | Default |
|---|---|---|---|
| entity_guid | Yes | The GUID of the entity |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It only says 'detailed information' without specifying what that includes, or any traits like read-only, idempotency, or performance. For a simple get operation, more detail would help.
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?
The description is elegantly short—one sentence of six words. Every word contributes meaning with no redundancy.
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?
Given the simplicity of the tool (one required parameter, no output schema, no annotations), the description is minimally adequate. It lacks details about return values or error conditions, but for a basic read operation, it may suffice.
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?
The input schema has 100% coverage for the single parameter (entity_guid). The description adds 'detailed information' but not much beyond the schema's own description. Baseline 3 applies since schema covers the parameter.
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 'Get detailed information about a specific entity' clearly states the verb (Get) and resource (entity details). It distinguishes from sibling tools like list_open_incidents or search_entities by implying retrieval of a single entity's full detail. However, 'entity' is broad and could be more specific.
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?
No guidance is provided on when to use this tool versus alternatives like get_account_details or search_entities. The description lacks context for choosing among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metric timeslices for metrics on a host (REST v2).
| Name | Required | Description | Default |
|---|---|---|---|
| application_id | Yes | ||
| host_id | Yes | ||
| names | Yes | ||
| values | No | ||
| from | No | ||
| to | No | ||
| period | No | ||
| summarize | No | ||
| page | No | ||
| auto_paginate | No | ||
| region | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent; the description only mentions 'REST v2' but doesn't disclose pagination, rate limits, or data format, leaving significant behavioral gaps.
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?
The single sentence is concise but too brief for a tool with many parameters; it could include more detail without becoming verbose.
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?
With 11 parameters, no annotations, and no output schema, the description fails to provide essential context like return format, pagination behavior, or interpretation of results.
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 description coverage is 0%, and the description provides no explanation for any of the 11 parameters, forcing the agent to rely solely on parameter names.
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 clearly states it retrieves metric timeslices for a host, distinguishing it from sibling tools like list_metric_names_for_host and run_nrql_query.
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?
No guidance on when to use this tool versus alternatives, such as run_nrql_query for custom queries or listing metrics first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all alert policies in your New Relic account
| Name | Required | Description | Default |
|---|---|---|---|
| target_account_id | No | Optional New Relic account ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description indicates a read operation but does not mention pagination, rate limits, or any other behaviors beyond listing. Insufficient for a non-annotated tool.
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?
Single sentence, no unnecessary words, front-loaded key information. Efficient.
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 simple list tool with one optional parameter and no output schema, the description is minimally adequate. Could mention if results are paginated or the default account context.
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 covers the only parameter with a description. Description adds no additional meaning beyond the schema, meeting the baseline for high coverage.
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?
Clearly states the action (list) and resource (alert policies) with scope (in your New Relic account). Distinguished from siblings like list_apm_applications or list_synthetics_monitors.
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?
No guidance on when to use this tool versus alternatives like search_entities or list_open_incidents. Implicitly clear from the resource name, but no explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all APM applications in your New Relic account
| Name | Required | Description | Default |
|---|---|---|---|
| target_account_id | No | Optional New Relic account ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It only states it lists applications, with no mention of side effects, authentication, rate limits, or pagination. For a read-only list, minimal transparency is provided.
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?
The description is a single concise sentence (10 words) with no unnecessary details, front-loading the core purpose efficiently.
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?
Given no output schema, the description should explain what the list includes (e.g., IDs, names, metadata). It lacks these details, making the tool's output unclear to the agent.
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?
The single optional parameter is documented in the schema with a description. The tool description adds no further meaning, so with 100% schema coverage, baseline score of 3 is appropriate.
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 clearly states 'List all APM applications in your New Relic account', specifying the verb (list), resource (APM applications), and scope (account). However, it does not differentiate from the sibling tool 'list_apm_applications_rest', which may cause confusion.
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?
No guidance is provided on when to use this tool versus alternatives like 'list_apm_applications_rest' or other listing tools. The description lacks explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List APM applications via REST v2.
| Name | Required | Description | Default |
|---|---|---|---|
| filter_name | No | ||
| filter_host | No | ||
| filter_ids | No | ||
| filter_language | No | ||
| page | No | ||
| auto_paginate | No | ||
| region | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. Description only states it lists applications via REST v2, omitting behavioral details like pagination (via page/auto_paginate parameters), filtering capabilities, or response structure. Minimal transparency.
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?
The description is very concise (one sentence) but underspecified. It lacks any structure like parameter descriptions or examples, making it too terse for a tool with 7 parameters.
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?
With no output schema, no annotations, and 7 parameters, the description is far from complete. It does not explain return values, pagination behavior, or how filters interact. Inadequate for effective use.
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 description coverage is 0%, yet the description adds no information about the 7 parameters (e.g., filter_name, page, region). The tool relies entirely on the schema field names for meaning, which is insufficient.
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?
Description states verb 'List' and resource 'APM applications' via REST v2, making purpose clear. However, it does not explicitly differentiate from sibling 'list_apm_applications', though the 'REST v2' hint implies a distinction.
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?
No guidance on when to use this tool versus alternatives like 'list_apm_applications'. No prerequisites, caveats, or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List hosts for an APM application (REST v2).
| Name | Required | Description | Default |
|---|---|---|---|
| application_id | Yes | ||
| filter_hostname | No | ||
| filter_ids | No | ||
| page | No | ||
| auto_paginate | No | ||
| region | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose pagination, rate limits, or read-only nature; only states it's REST v2.
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?
Single sentence is efficient but lacks necessary detail; not verbose but insufficient.
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?
With 6 parameters and no output schema, description fails to explain pagination, filtering, or return structure.
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%; description adds no meaning beyond parameter names like 'filter_hostname' or 'auto_paginate'.
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?
Clearly states 'List hosts for an APM application' with verb and resource, but doesn't differentiate from sibling tools like list_apm_applications or get_entity_details.
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?
No explicit guidance on when to use this tool versus alternatives; only implies usage context via description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List deployments for an APM application (REST v2).
| Name | Required | Description | Default |
|---|---|---|---|
| application_id | Yes | ||
| page | No | ||
| auto_paginate | No | ||
| region | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'List deployments' implying read-only, but fails to mention pagination behavior, error handling, or any side effects. Key details like pagination parameters are omitted.
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?
The description is a single sentence with no structure. While concise, it is under-specified and lacks bullet points, examples, or organization. It could be more informative without adding length.
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?
Given 4 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain output format, pagination, region selection, or error behavior. The agent has insufficient context to use the tool effectively.
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 description coverage is 0%; the description adds no meaning to any parameter. It does not explain application_id, page, auto_paginate, or region. The agent has no semantic guidance beyond the schema's type/enum constraints.
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 clearly states the verb 'list' and resource 'deployments', specifying scope 'for an APM application'. It distinguishes from sibling tools like create_deployment, delete_deployment, and list_apm_applications.
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?
No guidance on when to use this tool versus alternatives such as search_entities or run_nrql_query. No mention of prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List metric names and values for a specific application host (REST v2).
| Name | Required | Description | Default |
|---|---|---|---|
| application_id | Yes | ||
| host_id | Yes | ||
| name | No | ||
| page | No | ||
| auto_paginate | No | ||
| region | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks behavioral details like authentication, rate limits, or pagination behavior. Only states a simple list operation.
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?
Single sentence is concise and front-loaded, but too terse given the tool has 6 parameters. Could be more informative without adding length.
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?
Description lacks essential context: no mention of optional pagination, filtering by name, region selection, or output format. Incomplete for a tool with 6 parameters and no output schema.
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 description coverage is 0%, and the description adds no meaning to parameters. It does not explain the purpose of 'name', 'page', 'auto_paginate', or 'region' beyond their types.
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?
Description clearly states the action 'List' and resource 'metric names and values for a specific application host'. It distinguishes from siblings like 'list_application_hosts' and 'get_metric_data_for_host', but does not explicitly differentiate. Slight inconsistency: name says 'metric_names' but description adds 'and values'.
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?
No guidance on when to use this tool versus alternatives such as 'get_metric_data_for_host'. Does not mention context for pagination or filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all open incidents in your New Relic account
| Name | Required | Description | Default |
|---|---|---|---|
| target_account_id | No | Optional New Relic account ID | |
| priority | No | Filter by incident priority |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries the full burden. It does not disclose that the operation is read-only, nor does it mention any authentication requirements, rate limits, or potential side effects. The word 'list' implies read-only but is not explicit.
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?
The description is a single concise sentence that front-loads the core purpose. However, it could be slightly expanded with minimal context without losing conciseness.
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?
No output schema is provided, and the description does not mention return format, pagination, or limits. For a list tool, this is a significant gap. The description is too minimal for complete context.
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?
Input schema coverage is 100%, so the schema fully describes both parameters. The description adds no extra meaning or usage context beyond what the schema provides. Baseline score of 3 is appropriate.
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 clearly states the action (list), the resource (open incidents), and the scope (your New Relic account). It is specific and distinguishes from sibling tools like acknowledge_incident or search_entities, as it focuses on listing open incidents.
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?
The description provides no guidance on when to use this tool versus alternatives, such as when to use acknowledge_incident for acknowledging incidents or search_entities for broader search. No contextual exclusions or recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Synthetics monitors in your New Relic account
| Name | Required | Description | Default |
|---|---|---|---|
| target_account_id | No | Optional New Relic account ID | |
| monitor_type | No | Filter by monitor type |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like pagination or rate limits. It only says 'list all', without addressing potential large result sets or limitations.
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?
The description is a single, efficient sentence that covers the essential purpose with no extraneous words.
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?
Given no output schema and no annotations, the description is adequate for a simple list operation but lacks details on return format, pagination, or error handling.
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 100%, so baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions, which are already clear.
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 clearly states the verb 'List' and the resource 'all Synthetics monitors', effectively distinguishing it from sibling tools like list_alert_policies or list_apm_applications.
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?
No guidance is provided on when to use this tool versus alternatives, nor any exclusions or conditions. It simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a custom NerdGraph GraphQL query
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The GraphQL query to execute | |
| variables | No | Optional GraphQL variables to supply to the query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so description must cover behavior. It only states 'execute' without noting that it supports both queries and mutations, requires authentication, or may have rate limits. Does not disclose potential destructive actions if mutations are allowed.
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?
Single sentence with no redundant words. Immediately conveys the core action and target.
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?
Despite high schema coverage and no output schema, the description lacks critical context: it does not explain that the response is a GraphQL result, mention any error handling, or note that queries/mutations target New Relic data. For a flexible custom query tool, this is insufficient.
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 description coverage is 100%, with 'query' and 'variables' fields clearly described. The tool description adds no additional meaning beyond what the schema provides, so baseline 3 applies.
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?
Description clearly states 'Execute a custom NerdGraph GraphQL query', providing a specific verb and resource. It distinguishes from siblings like 'run_nrql_query' by naming the query language (NerdGraph vs NRQL).
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?
No guidance on when to use this tool versus alternatives such as 'run_nrql_query' for NRQL queries or other tools. Does not state prerequisites, limitations, or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute NRQL queries against New Relic data to analyze metrics and events
| Name | Required | Description | Default |
|---|---|---|---|
| nrql | Yes | The NRQL query to execute | |
| target_account_id | No | Optional New Relic account ID to query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states the action without disclosing whether it is read-only, destructive, has rate limits, or the nature of the results. This lack of detail makes it insufficient for safe agent decision-making.
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?
The description is a single sentence of 12 words, highly concise and front-loaded with the action 'Execute NRQL queries'. No wasted words.
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?
The tool has a simple schema with two parameters fully described. However, the description omits details about result format, pagination, query limits, or error handling, which are important for a query tool. The lack of output schema and annotations further reduces completeness.
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 100% with descriptions for both parameters (nrql and target_account_id). The description adds minimal value beyond the schema, only contextualizing the target data. The baseline score of 3 applies as the schema already provides parameter semantics.
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 clearly states the tool executes NRQL queries against New Relic data for analyzing metrics and events. This distinguishes it from siblings like run_nerdgraph_query (GraphQL) and others for specific operations like alerts, monitors, and deployments.
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?
The description implies use for querying New Relic data with NRQL but does not provide explicit guidance on when to use this tool versus alternatives, such as run_nerdgraph_query. No 'when not to use' or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for entities in New Relic by name, type, or tags
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for entities | |
| entity_types | No | Filter by entity types (e.g., APPLICATION, HOST) | |
| target_account_id | No | Optional New Relic account ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It does not mention pagination, rate limits, result limits, or any side effects. The description is too brief to inform the agent about important behavioral traits.
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?
The description is a single efficient sentence that front-loads the action and resource. Every word adds value with no redundancy.
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?
With no output schema, the description should hint at return format or result structure. It does not. The tool is a search operation with three parameters, but the description lacks details like default behavior, result limits, or error conditions.
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?
The input schema has 100% description coverage for all parameters. The description adds modest value by summarizing the filtering dimensions ('by name, type, or tags'), but does not provide additional meaning beyond what the schema already offers.
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 clearly states the action 'Search' and the resource 'entities', with specific filters 'by name, type, or tags'. It distinguishes from sibling tools like 'get_entity_details' which retrieves a single entity.
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?
No guidance on when to use this tool versus alternatives like 'list_apm_applications' or 'get_entity_details'. The description does not provide context or exclusions for its usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
acknowledge_incidentcreate_browser_monitorcreate_deploymentdelete_deploymentget_account_detailsget_entity_detailsget_metric_data_for_hostlist_alert_policieslist_apm_applicationslist_apm_applications_restlist_application_hostslist_deployments_restlist_metric_names_for_hostlist_open_incidentslist_synthetics_monitorsrun_nerdgraph_queryrun_nrql_querysearch_entitiesMost tools have distinct purposes, but the presence of both list_apm_applications and list_apm_applications_rest creates ambiguity as they both list APM applications via different APIs. Similarly, get_metric_data_for_host and list_metric_names_for_host are closely related but distinct. Overall, the set is mostly clear with a few overlapping pairs.
Tool names generally follow a verb_noun pattern, using verbs like acknowledge, create, delete, get, list, run, search. However, inconsistency arises with the 'rest' suffix on some tools (list_apm_applications_rest, list_deployments_rest) while others lack it, and mixing 'get' and 'list' for similar operations. The pattern is mostly consistent with minor deviations.
With 18 tools, the server covers a broad but focused set of New Relic functionalities including incidents, alerts, APM, synthetics, deployments, entities, and queries. The count is well-scoped for a general-purpose MCP server, providing a comprehensive yet manageable tool surface without being overwhelming.
The tool set covers many essential operations but lacks CRUD completeness for several domains. Missing operations include updating alert policies, updating or deleting synthetics monitors, and managing other entity types beyond APM. The powerful query tools (nerdgraph and nrql) can compensate for some gaps, but notable missing CRUD actions will cause agents to reach dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Access New Relic observability data through MCP - query metrics, logs, traces, entities, and more
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
n8n MCP — query your own n8n instance (BYO).
Query metrics, targets, entities, and team data in your Steep workspace via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/cloudbring/newrelic-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
