AppDynamics MCP Server

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation4/5
Most tools have clear distinct purposes, but there is some overlap between appd_add_widget_to_dashboard, appd_create_dashboard, and appd_update_dashboard regarding widget management. Descriptions help differentiate them, so only minor ambiguity remains.
Naming Consistency5/5
All tools follow a consistent 'appd_verb_noun' pattern (e.g., appd_get_applications, appd_create_dashboard). There are no deviations or mixed conventions.
Tool Count3/5
With 30 tools, the server is on the heavy side. While each tool serves a specific purpose for a comprehensive monitoring platform, the count exceeds the typical 3-15 range and may feel overwhelming.
Completeness4/5
The tool surface covers core CRUD operations for dashboards and health rules, plus extensive querying capabilities. Minor gaps exist (e.g., no tools to create/delete applications or modify business transactions), but major workflows are well-supported.
Average 4.3/5 across 30 of 30 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. Description adds that output is suitable for import, but doesn't disclose any potential edge cases, authentication needs, or limitations. Adds marginal 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?
Three concise sentences, front-loaded with the main action. No redundant or extraneous information. Every sentence earns its place.
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?
Covers essential: what it does, why (backup/transfer), and what it returns (JSON for import). No detail on output schema, but given simple tool and existing annotations, it's adequate. Minor gap: no mention of validation or error handling.
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% with a single parameter (dashboardId) already described. Description repeats the parameter info without adding new meaning such as how to obtain the ID or format constraints. Baseline 3 due to high coverage.
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?
Clearly states it exports a dashboard as a portable JSON definition, with explicit purpose: backup or recreate in another controller. Distinguishes from siblings like appd_get_dashboard and appd_save_dashboard_file by focusing on portable JSON for reuse.
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?
Implies usage for backup or transfer, but lacks explicit when-to-use or when-not-to-use compared to sibling tools like appd_save_dashboard_file or appd_get_dashboard. No direct alternatives mentioned.
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?
Annotations (readOnlyHint, idempotentHint, destructiveHint) already indicate safe, read-only behavior. Description adds no contradictions and states return format, but does not elaborate on behavioral details beyond 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?
Concise, front-loaded with purpose, followed by contextual explanation, argument list, and return summary. Five sentences with zero redundant information.
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?
Covers purpose, parameters, return structure sufficiently. No output schema, but return description is clear. Lacks mention of pagination or limits, but acceptable for a simple list tool.
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%, so description adds minimal value beyond schema (repeats parameter types and filter purpose). No additional constraints or examples provided.
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?
Description explicitly states 'List service endpoints (SEPs) for an application' and explains they provide granular performance data versus business transactions, aiding differentiation from sibling tools like get_business_transactions.
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?
Provides clear use case: to see specific URL paths or service methods that are slow. Implicitly contrasts with business transactions for broader view, but does not mention alternatives like get_service_endpoint_performance.
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?
Annotations clearly mark the tool as readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds additional behavioral insight: 'reveals what metrics and entities the dashboard monitors' and describes the return object. This goes beyond annotations without contradicting them.
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 extremely concise: 5 lines including Args and Returns sections. Every sentence serves a purpose, and the main action is front-loaded. No unnecessary repetition.
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 simple read tool with one parameter and no output schema, the description adequately explains the return value (complete dashboard object with widgets, layout, and data source configuration). It also provides the ID source. While it could mention permissions or rate limits, annotations cover the safety profile.
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 input schema already describes 'dashboardId' as a numeric ID. The description adds the origin hint ('from appd_get_dashboards'), which adds context beyond the schema. Given 100% schema coverage, this is a meaningful addition.
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 'Get the full definition of a specific dashboard' with explicit verb and resource. It mentions 'including all widgets and their configurations' for specificity. However, it does not explicitly differentiate from sibling tools like appd_get_dashboards (which lists dashboards) or other get tools, though the context of retrieving a single dashboard is implied.
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 context: 'useful for understanding what a team cares about, or for cloning/modifying dashboards.' It also hints at the appropriate source of the ID ('from appd_get_dashboards'). However, it does not explicitly state when not to use this tool or suggest alternatives among the many sibling tools.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds context about return event types and fields (severity, summary, timestamp), which supplements the annotations without contradiction.
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 structured with sections (Args, Returns) but is somewhat verbose with bullet points. It is clear and well-organized, though slightly longer than necessary.
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 no output schema, the description provides return field names (severity, summary, timestamp, affected entity), which is helpful. It covers purpose and parameters adequately for a read-only query tool, though does not mention pagination or limits.
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%, so schema already documents parameters. The description adds minor value by specifying the default for durationInMins and confirming application accepts both name and ID, but does not significantly enhance understanding beyond the schema.
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 tool retrieves error and exception events, listing specific types (ERROR, APPLICATION_ERROR, APPLICATION_CRASH). It distinguishes from sibling tools that handle different entities like dashboards or health rules.
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 does not explicitly guide when to use this tool versus alternatives like appd_get_health_violations or appd_get_snapshots. It implies usage for error events but lacks 'when not to use' or comparisons.
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?
Annotations provide safety profile (non-readOnly, non-destructive, non-idempotent). Description adds that it copies all widgets and returns a new dashboard with new ID. No contradictions.
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?
Concise two-sentence summary followed by args list and return statement. No unnecessary words, well-organized.
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?
Adequate for a simple clone operation. Mentions return value despite no output schema. Could mention prerequisites like permissions, but not essential.
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 covers 100% of parameters with descriptions. Description restates parameter meanings with slight rephrasing, adding minimal value beyond schema.
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?
Description clearly states it clones a dashboard, creating an exact copy with a new name. It distinguishes from siblings like create_dashboard (new from scratch) or update_dashboard (modify existing).
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?
No explicit guidance on when to use or not use this tool versus alternatives like create_dashboard. Usage is implied but not contrasted with similar operations.
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?
Annotations already declare readOnlyHint and idempotentHint. Description adds value by detailing the response structure (array of tiers with nested nodes, including machine details and IP addresses). No contradictions.
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?
Extremely concise: one line for purpose, one for content details, then structured Args and Returns. Front-loaded with key information. No unnecessary words.
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?
Covers main purpose, parameters, and return structure. Lacks mention of pagination, error handling, or dynamic nature (openWorldHint), but for a simple retrieval tool it is largely 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?
Only one parameter 'application', schema already describes it as name or numeric ID. Description repeats this without adding new semantic information. High schema coverage (100%) means baseline 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?
Clearly specifies the verb 'retrieve' and resource 'tiers and nodes', and distinguishes from sibling 'get' tools by focusing on infrastructure topology. Adds detail about tier types and node attributes.
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?
Implies usage for retrieving application topology, but no explicit guidance on when to use this vs sibling tools like get_applications or get_backends. No exclusions or alternatives mentioned.
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?
Annotations already indicate readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds value by detailing return fields (id, name, creator, timestamps) and filtering behavior, which is beyond the annotation scope. No contradictions.
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?
Three sentences efficiently convey purpose, return value, and optional parameter. No wasted words; front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations covering safety and idempotence, the schema covering the parameter, and the description covering return fields, the tool definition is complete for a simple list operation. No output schema needed as return values are described.
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% with a clear description of the nameFilter parameter. The description reiterates the parameter's purpose but does not add new 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Title 'List Dashboards' and description 'List all custom dashboards' clearly state the action and resource. The description specifies what is returned (summaries with id, name, creator, timestamps) and the optional filtering, distinguishing it from other dashboard tools like create, delete, or clone.
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?
Description mentions using nameFilter to search for specific dashboards, but does not explicitly state when to use this tool over siblings (e.g., appd_get_dashboard for a single dashboard, or other get tools). Usage context is implied but not differentiated.
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?
Annotations show readOnlyHint=false and destructiveHint=false, meaning it writes to file system but is not destructive. The description states it saves to a file and does not create anything in AppDynamics, but does not disclose potential side effects like overwriting existing files, file system permissions needed, or the exact path resolution behavior (slugified name). This is adequate but could be improved.
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 front-loaded with purpose and workflow. It uses bullet points for widget types and a clear list for args. However, it is somewhat verbose and repeats some schema details (e.g., widget parameter descriptions). Overall well-structured but could be trimmed slightly.
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 complexity (6 parameters, no output schema), the description covers the core workflow, widget types, grid layout, and relationships with sibling tools (e.g., appd_browse_metric_tree, appd_import_dashboard). The return value (absolute path and widget summary) is mentioned but not detailed, which is acceptable without an output schema.
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?
Schema description coverage is 100%, but the description adds significant value: it explains widget types with exact names, grid layout constraints (max width 12, height 1-4 typical), default file path behavior (slugified name), and references appd_browse_metric_tree for metric paths. This goes beyond the schema definitions.
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 tool's purpose: building a dashboard JSON definition and saving it to a local file without creating anything in AppDynamics. It distinguishes from siblings like appd_import_dashboard and appd_create_dashboard by emphasizing the offline, file-based workflow.
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 explains when to use this tool (offline dashboard creation and later import) and contrasts with appd_export_dashboard. It references appd_browse_metric_tree for metric discovery. It could be more explicit about when not to use (e.g., if you want immediate creation), but the context from sibling tools provides clear alternatives.
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?
Annotations already flag destructiveHint=true; description reinforces permanence with 'PERMANENT and cannot be undone' and mentions return value. Adds context beyond 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?
Extremely concise: one sentence for purpose, a caution, and a brief Args section. No unnecessary words.
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 simple deletion tool with one parameter, the description covers purpose, parameter, return type, and a precaution. Adequate given no output schema and annotations present.
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 parameter description is clear. Description repeats schema info without adding new semantics. Baseline 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?
Clearly states 'Delete a custom dashboard' with specific verb and resource. Distinct from sibling tools like get, update, clone, import, export.
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?
Suggests using appd_export_dashboard first for backup, providing explicit context. No explicit when-not-to-use but the guidance is helpful.
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?
Adds that the action is permanent and returns a confirmation message, complementing annotations (destructiveHint, readOnlyHint, idempotentHint). No contradictions.
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?
Very concise: 6 lines covering purpose, warning, args, and return. Front-loaded main action.
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 simple delete-by-ID tool with 2 params and no output schema, the description covers essentials: what, irreversibility, how to find ID, return type. 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?
Schema coverage is 100% and descriptions in schema already cover the parameters. The description repeats the schema info without adding new semantic detail.
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 verb 'delete' and the resource 'health rule', and distinguishes from sibling tools like create, update, enable, and get.
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?
Explicitly warns about irreversibility and advises using appd_get_health_rules to confirm the ID before deletion. Could further mention when not to use, but guidance is clear.
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?
Annotations already declare readOnlyHint and destructiveHint semantics. Description adds that it returns an array with id, name, tierName, entryPointType, and frames the tool as a discovery step for performance queries. No contradictions.
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?
Concise two-paragraph structure: purpose, context, usage guidance, then args and returns. Every sentence adds value; no 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?
Covers purpose, usage, parameters, return structure, and links to sibling. Lacks info on pagination, sorting, or any limits, but is adequate for a simple list tool with good annotations.
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 both parameters are well-described in the schema. Description repeats param details but does not add significant meaning beyond what is already provided in the schema.
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?
Clearly states it lists business transactions for an application, with specific verb and resource. Distinguishes from siblings by noting it provides BT IDs needed by appd_get_bt_performance.
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?
Explicitly advises using this tool to discover BT IDs for appd_get_bt_performance, providing clear context. Does not mention when not to use or list alternatives, but the guidance is direct and helpful.
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?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds behavioral details: returns summary list vs full configuration, explains what fields are returned in each case, and provides background on health rules. No contradictions.
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?
Description is concise and well-structured: purpose sentence, background, mode-specific behavior, parameter list, expected output. No redundant sentences; all information earns its place.
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 no output schema, description compensates by explaining return content (summary vs detailed) and mentions fields like id, name, type. Sufficient for a 2-parameter tool with clear behavior.
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 covers both parameters with descriptions (100% coverage). Description repeats parameter info almost identically, adding minimal new semantic value beyond clarifying the behavior difference.
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?
Clearly states it can list health rules or get details of a specific rule. The two modes are explained with different outcomes, distinguishing it from sibling tools like create/delete/update health rules.
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?
Provides explicit context for when to use each mode ('Without healthRuleId' vs 'With healthRuleId'). Mentions that understanding health rules is essential for interpreting violations, but does not explicitly state when not to use or alternatives.
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?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's verb 'retrieve' is consistent. The description adds useful context beyond annotations by stating the return format: 'Array of health rule violations with severity, status, affected entity, and timestamps.' It does not contradict annotations. A higher score would require disclosure of potential limitations like pagination or rate limits.
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 very concise: two short paragraphs and a bulleted list of arguments. It is front-loaded with the main purpose and immediately provides essential usage details. Every sentence adds value, and there is no extraneous information.
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 (2 optional parameters, no nested objects or output schema), the description is sufficiently complete. It explains the return format and key fields. It does not cover edge cases or error responses, but the annotations (readOnlyHint, etc.) provide safety assurances. A score of 5 would require addressing potential errors or performance implications.
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 baseline is 3. The description's parameter section essentially restates the schema descriptions (e.g., 'App name or ID. Omit for all apps.' and 'Lookback window in minutes (default: 1440 = 24h)'). It adds no new meaning beyond what is already in the schema, so no points above baseline.
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 tool's purpose: 'Retrieve health rule violations for a specific application or all applications.' It specifies the resource (health rule violations) and the action (retrieve), and distinguishes from siblings like appd_get_health_rules (which retrieves rules, not violations). The optional application parameter and default behavior are explicitly mentioned.
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 provides clear context on when to use the tool, including the optional application parameter and default lookback window. It explains that omitting application returns violations for all apps. However, it does not explicitly mention when not to use it or suggest alternative tools, though the sibling list and name make the distinction clear.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value beyond these by explicitly listing the specific metrics retrieved (average response time, calls per minute, errors per minute) and noting the default duration. This enriches the agent's understanding of the tool's behavior.
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 concise: two sentences for purpose and return, one for prerequisite, then a clean Args section. No extraneous information. Every sentence adds value, and the structure is clear and easy to parse.
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?
Despite no output schema, the description lists the three returned metrics (average response time, calls/min, errors/min), providing sufficient context. It also includes the prerequisite step. It lacks details on error handling or edge cases (e.g., invalid sepId), but for a straightforward read-only metrics tool, this is reasonably 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 coverage is 100% with descriptions for all three parameters (application, sepId, durationInMins). The description repeats these in an Args section, adding the default for durationInMins but no deeper semantic meaning beyond what the schema provides. Thus, it meets the baseline for high-coverage schemas.
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 tool retrieves performance metrics (average response time, calls per minute, errors per minute) for a specific service endpoint. It uses a specific verb ('Get') and identifies the resource ('service endpoint performance'), distinguishing it from sibling tools like appd_get_bt_performance or appd_get_backends.
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 provides a clear prerequisite: 'Use appd_get_service_endpoints first to find the SEP ID.' It implies when to use this tool (after obtaining SEP ID) but does not explicitly contrast with alternatives or state when not to use it. The context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint. The description adds significant behavioral context beyond those: snapshots are deep diagnostic captures showing call graphs, SQL, HTTP calls, and return an array with timing and error details. No contradictions exist.
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?
Description is short, front-loaded with purpose, and well-structured with an Args list. Every sentence adds value with no waste. Efficient use of space.
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 7 parameters and no output schema, the description covers purpose, snapshot content, and return type. However, it lacks guidance on how data collector filters interact or parameter relationships. Minor gap but mostly 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 baseline is 3. The description repeats parameter info and adds default/max values (e.g., maxResults defaults to 20, max 100) already present in schema. No additional semantics beyond what schema provides.
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 explicitly states 'Retrieve transaction snapshots (slow, error, stall) for an application,' using a specific verb and resource. It clearly distinguishes from sibling tools by focusing on diagnostic captures rather than health rules, dashboards, or other entities.
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 explains what snapshots are but provides no guidance on when to use this tool versus alternatives like appd_get_errors or appd_get_health_violations. Usage context is implied through resource type, but no explicit when-to-use or when-not-to-use is given.
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?
Annotations indicate readOnlyHint=false and destructiveHint=false. Description adds that the original ID is always discarded and a new one is assigned, which is key behavioral info beyond annotations. No contradictions.
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?
No fluff: one sentence purpose, a paragraph on function and workflow, then args list. Well-structured and efficient.
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?
Covers inputs, workflow, and return value (new dashboard with new ID). No output schema, but description addresses it. Could be slightly more explicit about when to use vs siblings, but 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?
Schema coverage is 100% with detailed descriptions. The description's 'Args' section largely repeats schema, adding minimal extra value. Baseline 3 is appropriate as schema carries the burden.
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?
Clearly states 'Create a new dashboard from a JSON definition string' and explains it uses JSON output from export tools, distinguishing it from siblings like appd_create_dashboard (create from scratch) and appd_clone_dashboard (duplicate existing). Discarding original ID reinforces purpose.
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?
Describes typical workflow with export-edit-import, and accepts 'JSON output of appd_export_dashboard or any saved dashboard JSON file'. Provides usage context but does not explicitly compare with alternatives like appd_create_dashboard for 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral trait beyond annotations: a two-step fetch-merge-put process, ensuring idempotency (annotations idempotentHint=true). It aligns with all annotations (readOnlyHint=false, destructiveHint=false) and adds value by explaining how partial updates are handled.
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 front-loaded with the core operation and merge logic, then lists args. While clear, the arg list is redundant given the schema. Minor waste could be trimmed, but overall it is 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?
Given many sibling health rule tools and no output schema, the description lacks details about the return object structure (only 'Updated health rule object'). Prerequisites like existence of the rule and application are implied but not stated. Completeness is adequate but has gaps.
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 baseline is 3. The description's arg list merely reiterates parameter names and types from the schema without adding new meaning or usage hints. It does not compensate beyond what the schema already provides.
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 'Update an existing health rule by ID' with a specific verb (update) and resource (health rule). It distinguishes from siblings like create_health_rule and delete_health_rule by focusing on modification of an existing rule.
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 explains the merge pattern ('Only fields you supply are changed') and the read-modify-update process. However, it does not explicitly state when to use this tool vs alternatives like enable/disable or create, leaving usage context implicit rather than explicit.
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?
Annotations already indicate non-readOnly and non-destructive. The description adds behavioral context by explaining widget creation flow, grid layout constraints, and that the tool returns the created dashboard object with new ID. No contradictions with annotations.
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?
Well-structured with bullet points for widget types and grid layout. Front-loaded with main purpose. Efficient but somewhat lengthy due to detailed widget explanations; every sentence serves a purpose.
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?
Covers essential aspects: widget types, grid layout, references to sibling tools, and return value. Lacks error handling or prerequisites information, but for a creation tool with rich annotations, it is fairly complete.
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?
Schema description coverage is 100%, but the description adds significant value beyond schema by explaining widget types with examples, grid layout (max 12), and referencing appd_browse_metric_tree. It clarifies optionality and provides usage patterns not in schema.
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 'Create a new custom dashboard in AppDynamics' with specific verb (create) and resource (dashboard). It distinguishes from sibling tools like appd_add_widget_to_dashboard and appd_auto_build_dashboard by explaining how to provide widgets upfront or create a blank dashboard for later addition.
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?
Provides clear guidance on when to use this tool (to create a dashboard) and mentions alternatives (use appd_add_widget_to_dashboard for adding widgets later, appd_browse_metric_tree for metric paths). Lacks explicit 'when not to use' statements, but differentiation from siblings is effective.
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?
Annotations indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description adds behavioral details: it creates a new rule, returns the object with ID, requires at least one condition, and explains metric path differences per entity type. No contradictions. Could mention permissions, but overall good.
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 somewhat long but well-structured with sections for APM, SIM, operators, and an example. It front-loads the core purpose and requirements (application, name, entity type, critical conditions). Every sentence serves a purpose, though could be slightly tightened.
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 13 parameters and no output schema, the description covers creation details well: return value, entity types, metric path rules, and conditions structure. It addresses both common and edge cases (CUSTOM entity for SIM). Missing error handling (e.g., duplicate name) but covers essential context for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3), but the description adds significant value beyond the schema. It explains metric path formats for APM (relative) vs SIM (absolute), provides an example, clarifies that affectedNode overrides affectedTier, and notes which entity types require which parameters. This substantially aids correct parameter usage.
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 'Create a new health rule for an application' with specific supported entity types (APM, SIM) and a clear requirement for at least one critical condition. It distinguishes from siblings like update/enable/delete health rules, making the tool's purpose unambiguous.
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 provides extensive guidance: it explains when to use different entity types (APM vs SIM), how to construct metric paths for each, and includes examples. While it doesn't explicitly state when not to use the tool, the context of creation vs updating is clear from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds extensive behavioral detail beyond annotations: it explains the two-phase process (parallel topology fetch then metrics with baseline comparison), the use of percentage degradation for anomaly flags (with concrete example), and the absence of hardcoded thresholds. No contradiction with annotations.
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 fairly long but well-structured with clear phase breakdowns and an example. It front-loads the core purpose and phases. Every sentence provides useful information (purpose, phases, mechanism, return format). Could be slightly more concise by merging redundant statements about default focus, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, lack of output schema, and absence of nested objects, the description thoroughly covers what the tool does and what it returns (structured diagnostic report with causalityChain, tierMetrics, etc.). It explains the algorithm, anomaly detection method, and even includes an example. This is more than adequate for an agent to understand the tool's behavior and outputs.
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 parameter descriptions in the schema are already clear. The tool description restates these parameters without adding significant new semantic value. It recites defaults (e.g., durationInMins defaults to 60) and explains focus options, but these are already in the schema. Baseline score 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 explicitly states the tool performs a two-phase automated root cause analysis for applications, clearly distinguishing it from sibling tools that are individual data-fetching tools (like appd_get_anomalies, appd_get_errors). The verb 'diagnose' combined with 'root cause analysis' precisely conveys the tool's purpose.
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 advises using this tool 'when you need to quickly understand why an application is behaving badly without manually calling many separate tools.' This provides a clear use case. It does not explicitly state when not to use it, but the context of the sibling tools implies it is for comprehensive analysis rather than single-metric queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the internal fetch-modify-PUT process, which adds context beyond the annotations. It confirms idempotentHint and non-destructive behavior, and contradicts nothing in 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 four sentences with no wasted words: purpose, mechanism, arguments, return. Front-loaded with the main action, clear and efficient.
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 simple toggle operation and complete schema coverage, the description adequately covers behavior and return. It could mention error conditions or prerequisites, but overall it's sufficient for an agent to use correctly.
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 already has 100% parameter description coverage. The description repeats the parameter types but adds no new semantic information beyond the schema. Baseline score 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 clearly states the tool enables or disables a health rule without changing other settings. It uses a specific verb-resource pair and distinguishes from sibling tools like appd_update_health_rule, which modifies other settings.
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 implies when to use this tool by stating 'without changing any other settings,' differentiating it from update_health_rule. However, it does not explicitly name the alternative tool or provide guidance on when not to use it.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds context about types of backends (databases, HTTP, etc.) and the return format, providing additional behavioral clarity beyond 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 well-structured with a clear purpose, bulleted args, and return format. Every sentence adds value without redundancy.
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 there is no output schema, the description adequately specifies the return structure. However, it lacks details on pagination or limits, which would be helpful but not critical for a simple list tool.
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?
Schema coverage is 100%, so baseline is 3. The description adds value by providing examples (e.g., 'HTTP', 'JDBC', 'CACHE') for typeFilter and clarifying that application accepts name or ID.
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 uses a specific verb ('List') and resource ('backend dependencies'), and clearly distinguishes from sibling tools (like get_business_transactions) by stating it lists external services called by the application.
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 implies usage for dependency mapping and troubleshooting backend slow performance, but does not explicitly state when not to use this tool or provide specific alternatives.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint; the description adds value by enumerating the specific metrics returned (e.g., errors per minute, stall count) and clarifies it is a read operation. No contradictions.
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?
Description is compact, starts with the core purpose, uses a clear bullet-style for args, and every sentence adds value. No extraneous text.
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?
No output schema, but description summarizes return value as BT details plus metric data for each listed metric. It omits the structure of BT details but is adequate for a simple data retrieval tool with 3 parameters.
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?
Schema coverage is 100%, so baseline 3. The description adds context for each parameter: application can be name or ID, btId comes from lookup, durationInMins defaults to 60. This goes beyond schema descriptions.
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 tool retrieves performance metrics for a specific business transaction, listing the exact metrics (average response time, calls per minute, etc.) and differentiating it from sibling like appd_get_business_transactions which finds the BT ID.
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?
It explicitly advises to use appd_get_business_transactions first to obtain the BT ID, providing a clear prerequisite. However, it does not directly contrast with alternatives like appd_get_metric_data, leaving some ambiguity.
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?
Annotations indicate write behavior (readOnlyHint=false) and non-idempotent (idempotentHint=false). The description adds context by explaining the automatic discovery and creation process. It does not mention potential duplicate dashboards due to non-idempotency, but the core behavior is well disclosed.
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 concise and structured: a one-sentence intro, a bullet-style list of focus modes, and a clear arg list. Every sentence adds value, and the key purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool of this complexity (4 parameters, multiple focus modes, no output schema), the description covers all essential aspects: what it does, how to configure it, and what is returned. It is complete enough for an agent to use correctly.
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?
Schema coverage is 100%, and the description enhances this by explaining defaults (dashboardName defaults to '{AppName} - Auto Dashboard', timeRangeMinutes defaults to 60) and the focus enum options with use-case descriptions. This adds value beyond the schema.
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 tool's purpose: 'automatically build a complete monitoring dashboard for an application'. It details what it discovers (tiers, BTs, health rules) and the outcome (multi-section dashboard), which distinguishes it from sibling tools like appd_create_dashboard that likely create empty dashboards.
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 provides focus modes and default values, giving context on when to use different configurations. However, it does not explicitly state when not to use this tool or suggest alternatives, so the guidance is clear but not exhaustive.
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?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds value by specifying return fields (id, name, description) and filter behavior (case-insensitive partial match), which are not in 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 succinct (5 sentences), each sentence adds unique value. The main purpose is front-loaded, and there is no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional parameter, no output schema), the description fully covers its purpose, return structure, and usage context. Annotations provide safety guarantees, and the description adds enough detail for an agent to use it correctly.
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?
Schema description coverage is 100% for the single parameter. The description adds the detail that filtering is 'case-insensitive partial match', providing additional semantic clarity beyond the schema.
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 'List all business applications monitored by AppDynamics' and specifies optional filtering by name. It also distinguishes itself from sibling tools by stating 'Use this tool first to discover application IDs needed by other 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 provides explicit context for when to use this tool ('Use this tool first to discover application IDs needed by other tools') and mentions the optional filter. However, it does not specify when not to use it or mention alternatives.
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?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the tool is clearly non-destructive. The description adds important behavioral context: it retrieves data, explains custom metric storage per-node, and requires specific paths and rollup=false for those. It also describes the return format (array of metric data objects). No contradiction with 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 well-organized with sections, bullet points, and examples. It starts with the core purpose, then provides usage guidance, custom metric details, and a parameter list. Every sentence is informative. Despite length, it remains focused and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return values (timestamps, min, max, avg, count, sum). It covers both standard and custom metrics, references the sibling discovery tool, and provides navigation patterns. For a tool with 4 parameters and good annotations, this is a complete and informative description.
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?
Schema coverage is 100%, so baseline is 3. The description adds value by providing concrete examples for metricPath (including wildcard patterns), explaining the default duration (60 minutes), and clarifying the rollup parameter's effect on aggregation and custom metrics. These details go beyond the schema descriptions.
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 'Query any metric from the AppDynamics metric tree.' It distinguishes itself from sibling tools like appd_browse_metric_tree (which discovers paths) and appd_get_anomalies (which retrieves anomalies). The tool is presented as a generic, all-encompassing metric retrieval tool.
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 explicitly recommends using appd_browse_metric_tree first to discover metric paths. It also explains when to use rollup=true vs false, especially for custom metrics. While it doesn't list explicit alternatives or exclusions, it provides clear context for different scenarios.
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?
Annotations already indicate idempotentHint=true and non-destructive behavior. The description adds valuable context: widget replacement behavior, return value ('Returns: The updated dashboard object'), and parameter semantics. No contradiction with annotations.
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 moderately sized with a clear structure: purpose, important warning, args listing, return value. It is front-loaded with key information. Could be slightly more concise but remains effective.
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 6 parameters, 100% schema coverage, no output schema, the description covers return value and the critical widget replacement behavior. It also mentions an alternative tool. Slightly missing explicit mention of idempotency (covered by annotation) but otherwise complete.
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?
Schema coverage is 100%, so baseline is 3. The description adds extra meaning by summarizing parameters and highlighting the replacement semantics for widgets, which is not fully captured in the schema description. This provides added clarity beyond the schema.
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 'Update an existing dashboard's properties and/or widgets,' using a specific verb and resource. It distinguishes from sibling tool appd_add_widget_to_dashboard by noting that providing widgets replaces all existing ones, making it clear when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns that providing widgets replaces all existing widgets and directs users to appd_add_widget_to_dashboard for adding a single widget without losing others. This provides clear when-to-use and when-not-to-use guidance with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds valuable specifics: default returns open anomalies only, includeAll retrieves closed ones, defaults for severity and duration, and return grouping when querying all apps. No contradictions.
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?
Efficient structure: purpose first, then parameter explanations, then return description. No waste; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All parameters explained with defaults, return value described (array, grouping for all apps). No output schema, but description provides sufficient info. Complete for tool complexity.
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?
Schema covers parameters 100%, but description adds context like 'Omit for all apps' and explains includeAll behavior. Adds meaningful guidance beyond schema definitions.
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?
Clearly states it retrieves anomaly events with scope (specific app or all apps) and default behavior (open only). Distinguishes from sibling tools like appd_get_health_violations or appd_get_errors by focusing on anomalies.
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?
Provides default behavior and explains key parameter (includeAll) that changes scope. Lacks explicit 'when not to use' or direct alternatives, but tool name and sibling context make usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses internal process (fetches, appends, saves) and confirms non-destructive behavior, supplementing annotations. No contradictions.
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?
Well-structured: purpose sentence, process summary, widget type list with requirements, and parameter summary. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: parameters, widget types, process, and returns. References sibling tools. No output schema needed; description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant value beyond schema by explaining widget types, required fields, and referencing sibling tools for metric paths, compensating for nested object complexity.
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?
Clearly states 'Add a single widget to an existing dashboard without replacing existing widgets.' Verb and resource are specific, and it distinguishes from siblings like appd_update_dashboard.
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?
Provides when-to-use context and lists widget types with required fields, implying when each type is appropriate. Could explicitly mention alternatives but is still clear.
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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds value by explaining that browsing reveals metric paths without modifying data, and that rollup controls aggregation behavior. It does not contradict 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 well-structured with bullet points for top-level folders and custom metrics. It is front-loaded with the purpose, and every sentence serves a clear function. There is no redundancy or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description explicitly states what is returned ('Array of child metric nodes with name, type (folder or leaf), and full path'). Combined with thorough parameter guidance and usage context, the tool is fully self-contained for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema already describes the parameters with 100% coverage, the description adds extra meaning: example paths for metricPath, clarification that rollup defaults to true and when to set false, and the structure of custom metrics. This significantly aids correct usage.
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 explicitly states 'Browse the AppDynamics metric tree to discover available metric paths.' This clearly identifies the verb (browse) and resource (metric tree), and distinguishes it from sibling tools like appd_get_metric_data which retrieves data rather than exploring paths.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: call without metricPath for top-level, then drill down with specific paths. It also explains when to set rollup=false (node-level browsing) and lists common top-level folders. This provides clear context for when and how to use the tool.
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:

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

Score Badge

Copy to your README.md:

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

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/asafkiv/appdynamics-mcp-server'

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