newrelic-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Tools are mostly distinct: nrql_query and nrql_batch_query overlap in purpose but are clearly differentiated by efficiency, and search_entities vs get_entity serve different stages of entity interaction. Other tools each target a unique domain (alerts, incidents, deployments, golden signals, error traces, throughput), leaving little ambiguity.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (e.g., get_entity, search_entities, nrql_query). The two nrql tools deviate slightly from get_ but still maintain the same structural style, making the naming predictable and coherent.
Tool Count5/5
With 10 tools, the server covers a broad but focused set of New Relic operations—querying, entity discovery, alerting, performance metrics, and deployment info. This is well-scoped for a monitoring MCP server, neither too sparse nor overloaded.
Completeness4/5
The surface covers core read-only workflows: flexible NRQL querying, entity lookup, alert/incident awareness, and APM performance details. Minor gaps exist (e.g., no log-specific query but nrql_query handles it, no entity mutation), but for a read-only monitoring server, it covers the essential needs without dead ends.
Average 3.4/5 across 10 of 10 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. Beyond the phrase 'get recent deployments,' it reveals nothing about side effects, permissions, pagination, time ranges, or what 'recent' means. It does not contradict annotations (there are none), but it fails to disclose any behavioral traits, leaving the agent without critical context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. It front-loads the core purpose without fluff. It is appropriately sized for a simple tool with two parameters, though it could have incorporated usage or behavioral hints without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, output schema exists), the description is not complete. It lacks any usage context or behavioral detail that would help an agent decide when to call it. The phrase 'recent deployments' is ambiguous, and without pruning criteria or pagination information, an agent cannot fully anticipate the tool's behavior. This is a minimal viable description at best.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both limit and entity_guid have explicit descriptions. The tool description adds no additional meaning beyond what the schema provides, so it does not elevate the value. With full schema coverage, the baseline of 3 is appropriate; no extra parameter insights are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('get') and resource ('deployments') scoped to an APM application entity, which clearly distinguishes it from sibling tools like get_alert_conditions or get_throughput_timeseries. It is not a tautology and clearly communicates what the tool retrieves. However, it does not explicitly contrast with siblings, so it misses a full distinguishing statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention prerequisites, typical use cases, or contexts where a different tool would be more appropriate. With siblings like search_entities and get_entity, the agent is left to infer when to call get_deployments, so this dimension is weak.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only says 'List,' which implies a read operation, but does not explicitly state read-only behavior, pagination, output format, or any side effects. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It front-loads the verb and resource, making it highly scannable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an output schema, the description is minimally sufficient to invoke it. However, it lacks any context about when to use it relative to siblings or what the result represents, leaving some inference required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter 'policy_id' is fully documented with its optionality and default behavior. The description adds no additional meaning beyond the schema, which is acceptable given the complete schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('List') and a specific resource ('NRQL alert conditions'), which distinguishes it from generic query tools like nrql_query. It is unambiguous about the subject matter, though it does not explicitly exclude other sibling operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description merely states what it does, leaving the agent to infer that it is for retrieving alert conditions rather than querying data. No explicit when/when-not conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states what the tool does (fetch signals) and gives no information about side effects, required permissions, data recency, or any limitations. For a read-only operation this is minimally acceptable, but the absence of any behavioral context makes it insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, compact sentence that front-loads the purpose and enumerates the returned signals. Every word contributes value, and it is easy to scan quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, parameters are fully documented in the schema, and an output schema exists. The description covers the core purpose, but it omits usage context (e.g., when to prefer this over other tools) and any behavioral caveats. For a basic read tool this is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with descriptions for both parameters (app_name, since) and a default for since. The description adds no further meaning beyond restating the resource ('App' and 'golden signals'), so it does not enhance parameter understanding. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('golden signals for an APM app'), listing the four signal types. It is specific enough to distinguish from general query tools like nrql_query, though it does not explicitly differentiate from siblings like get_throughput_timeseries, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention that this tool provides a consolidated summary of the four golden signals in one call, nor does it suggest when one might use get_throughput_timeseries for a specific metric. The description leaves usage decisions entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the full behavioral burden. It implies a read-only operation ('Get') but does not disclose whether it aggregates data, how it handles time ranges beyond the schema default, or what the returned timeseries structure looks like. Without annotation support, this minimal description is insufficient for an agent to predict the tool's behavior beyond trivial retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with a parenthetical use-case hint. It is front-loaded with the core purpose and contains no filler, making it easy to parse. However, it could be slightly more informative without losing conciseness, hence a 4 rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (though not shown), the description doesn't need to detail return values. However, the lack of any behavioral context (e.g., what defines 'throughput', whether it uses NRQL internally, or how it differs from a generic query) leaves gaps for an agent selecting among siblings. It is adequate for a simple tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all parameters (since, app_name, timeseries) with defaults and examples. The description adds no additional parameter-level meaning beyond the high-level purpose. This aligns with the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('throughput over time for an application'), and adds a useful hint about spotting traffic patterns. It is distinct from siblings like nrql_query or get_golden_signals because it specifically targets throughput over time, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical 'useful for spotting traffic patterns' gives some context on when to use it, but provides no explicit guidance on when to prefer this over sibling tools like nrql_query, nor any exclusion criteria. The usage intent is implied rather than stated directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only says 'Search' and does not disclose behavior such as matching semantics, result limits, pagination, case sensitivity, or whether all matches are returned. This is thin behavioral disclosure for a discovery tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and resource. It contains no filler and earns its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has all-optional parameters, fully documented schema, and an output schema, so an agent can construct a valid call from the structured information. The main gap is lack of guidance about when to choose search_entities over get_entity or nrql_query, but for basic invocation the provided context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, and each parameter has a meaningful description including examples and formatting hints. The tool description itself adds no extra parameter semantics, but the schema already handles that burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Search for New Relic entities') and gives concrete examples of entity types. It doesn't explicitly differentiate from the closely related get_entity tool, though the plural 'entities' and 'Search' strongly imply broad lookup versus direct retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool instead of alternatives like get_entity or nrql_query. There are no exclusions, prerequisites, or recommended filter strategies, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state that this is a read-only operation, does not mention any permissions, rate limits, or side effects. While it hints at output content (stack traces, messages), it omits essential behavioral context expected for a tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, instantly understandably, with the core action and outcome front-loaded. Every word earns its place, and there is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a basic sense of what the tool does, but given the presence of siblings like nrql_query and nrql_batch_query, it would benefit from a note on when to use this instead. It also lacks behavioral transparency since there are no annotations. The output schema exists, so return format is not a gap, but usage guidance and behavior are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with clear descriptions for all three parameters. The description adds no extra parameter-related meaning, so it does not exceed the baseline of 3. The schema already documents limit, since, and app_name effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('get'), a precise resource ('recent error traces'), and scope ('for an application'). It clearly distinguishes from generic siblings like nrql_query or search_entities by focusing on error traces. The mention of 'stack traces and messages' adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when error traces are needed, but it does not explicitly state when to use this tool over alternatives like nrql_query (which could also fetch error traces via NRQL). No exclusions or alternative routing is provided, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden. It states that it 'return results', implying a read-only operation, but does not explicitly mention side effects (or lack thereof), authentication requirements, rate limits, or error behavior. While the basic read-only intent is clear, more transparency would be expected for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the core action. The second sentence enumerates data types, which adds context but is somewhat redundant. It is appropriately sized without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter query tool with an output schema present, the description is largely complete. It covers the action, target data, and overall purpose. It lacks details on error handling or limits, but these are not critical for basic usage, and the output schema presumably covers return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a full description of the 'query' parameter (coverage 100%), including an example. The tool description adds no additional meaning about the parameter beyond what the schema states, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Run') and a clear resource ('NRQL query against your New Relic account'), and clarifies the scope ('return results'). It is distinct from most siblings, though it does not explicitly distinguish itself from nrql_batch_query, leaving some ambiguity about single vs. batch queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for use ('query any telemetry data: transactions, errors, spans, etc.'), which implies it is the general-purpose querying tool. However, it does not mention alternatives or when not to use it (e.g., for batch queries), so no explicit exclusions or routing to siblings are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the core behavior — multiple queries executed in one request for efficiency. But it omits meaningful edge behaviors such as maximum query count per request, partial-failure semantics (does one bad query fail the whole batch?), and how errors are surfaced. These matter for a batch tool and are undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that states purpose and benefit with zero waste. Every clause earns its place; it is appropriately sized for the tool's simple surface area.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema and a well-documented parameter schema reduces the burden substantially. However, the one-sentence description leaves genuine gaps for a batch operation: query-count limits, failure isolation between queries, and result-keying behavior are absent, and with no annotations these gaps have nowhere else to be filled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the `queries` parameter is already well-documented with an example dict mapping labels to NRQL strings. The description adds no parameter-level detail beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Run multiple NRQL queries in a single request') and explicitly frames the batch nature, which distinguishes it from the nrql_query sibling. The phrase 'more efficient than individual calls' makes the differentiation concrete without needing to open either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'More efficient than individual calls' gives clear context that this tool is for aggregating multiple queries in one round-trip. However, it does not explicitly name nrql_query as the single-query alternative nor state when NOT to use the batch tool (e.g., for one-off queries or when query-count limits matter), leaving exclusions implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses that the tool returns entity metadata including type-specific info (APM language, host metrics), which conveys expected output. While it doesn't mention error cases or safety guarantees, 'Get' clearly implies a read-only operation, and the stated return value adds useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero fluff. It front-loads the purpose and then adds a brief note on return content. Every word earns its place, and it is easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema (so return values are documented elsewhere), the description covers the essentials. It mentions type-specific info, which is helpful, and no critical usage details are missing. It could note that the GUID must exist, but that is implied by 'specific entity'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter (guid) with a clear description ('The New Relic entity GUID.'). The description's mention of 'by its GUID' adds no new semantic detail beyond the schema's coverage, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a specific resource ('specific entity'), and the identifier ('by its GUID'). It clearly distinguishes itself from siblings like search_entities (which is for searching) and nrql_query (query language), so an agent can tell when to pick this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you already have an entity GUID, but it does not explicitly contrast it with alternatives like search_entities or state when not to use it. There is no exclusion or condition beyond having a GUID, so the guidance is incomplete but not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It states what the tool returns and implies a read-only operation by saying 'Returns issues'. However, it does not mention any limitations such as pagination, maximum result count, or authentication requirements. For a zero-parameter read tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences with no filler. The primary action and scope are front-loaded, and the return fields are listed in a compact, useful way. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple zero-parameter tool. It specifies the scope (currently active) and the return fields, which gives an agent enough context to understand the output. It does not mention pagination or limits, but given the tool's simplicity and the existence of an output schema, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully covers all parameters (100% coverage). The description adds no parameter information because none is needed. The baseline for 0 parameters is 4, and there is no gap to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific resource ('currently active (open) incidents/issues from New Relic AI') and the action ('Get all'). It also lists the return fields, making it unambiguous what the tool does and distinguishing it from siblings like query tools or entity tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the intended use: retrieving current open incidents. While it doesn't explicitly name alternatives or state when not to use it, the wording 'currently active' communicates the scope, and siblings are clearly different domains (queries, entities, conditions). The usage context is clear enough without explicit exclusion clauses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![newrelic-mcp MCP server](https://glama.ai/mcp/servers/MohamedSawahZC/newrelic-mcp/badges/card.svg)](https://glama.ai/mcp/servers/MohamedSawahZC/newrelic-mcp)

Score Badge

Copy to your README.md:

[![newrelic-mcp MCP server](https://glama.ai/mcp/servers/MohamedSawahZC/newrelic-mcp/badges/score.svg)](https://glama.ai/mcp/servers/MohamedSawahZC/newrelic-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MohamedSawahZC/newrelic-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server