Skip to main content
Glama
AppDynamics MCP Server

AppDynamics MCP Server

by asafkiv

AppDynamics MCP Server

A Model Context Protocol server that gives LLM clients (Cursor, Claude Desktop, etc.) full access to your AppDynamics monitoring data — plus the ability to create and manage dashboards and health rules.

Features

30 tools across 8 categories:

  • Discovery: List and search applications by name

  • Health Monitoring: Full health rule CRUD, violations, and anomaly detection

  • Application Performance: Business transactions, service endpoints, and their metrics

  • Infrastructure: Tiers, nodes, and backend/remote service dependencies

  • Diagnostics: Transaction snapshots and error events

  • Root Cause Analysis: Automated composite diagnosis across all signal types

  • Metrics: Browse the metric tree and query any metric with rollup support

  • Dashboards: Full CRUD — list, view, create, update, add widgets, clone, delete, export, import, auto-build, per-rule health status widgets

Key capabilities

  • Natural language friendly: Accept application names, not just IDs

  • Historical time ranges: Query any past window, not just "the last N minutes" — see Time Ranges

  • Metric tree browser: Discover available metrics interactively, including custom/machine-agent metrics

  • Rollup control: Per-widget rollup for time-series vs. aggregate metric views

  • Dashboard auto-builder: Create full multi-section dashboards from a single prompt

  • HealthListWidget scoping: Each widget can be pinned to a specific health rule (not "all rules")

  • Health rule CRUD: Create, update, enable/disable, and delete health rules — including custom metrics scoped to a specific tier or node

  • Smart defaults: Sensible time ranges and result limits out of the box

Related MCP server: Observe MCP Server

Time Ranges

Every time-aware tool accepts durationInMins, startTime, and endTime. Timestamps may be ISO 8601 (2026-08-03T14:00:00Z) or epoch milliseconds; bare epoch-seconds values are detected and converted.

Arguments supplied

Window queried

AppDynamics range type

(none)

The tool's default lookback, ending now

BEFORE_NOW

durationInMins

Last N minutes

BEFORE_NOW

startTime + endTime

Exactly that window

BETWEEN_TIMES

endTime + durationInMins

N minutes before that point

BEFORE_TIME

startTime + durationInMins

N minutes after that point

AFTER_TIME

// "What did response time look like during yesterday's incident?"
{
  "application": "Checkout",
  "metricPath": "Overall Application Performance|Average Response Time (ms)",
  "startTime": "2026-08-02T12:00:00Z",
  "endTime":   "2026-08-02T15:00:00Z"
}

Contradictory input is rejected with an actionable message rather than silently guessing — supplying durationInMins together with both endpoints, an inverted window (endTime before startTime), or an unparseable timestamp all return an error.

Tools supporting time ranges: appd_get_metric_data, appd_get_health_violations, appd_get_anomalies, appd_get_errors, appd_get_snapshots, appd_get_bt_performance, appd_get_service_endpoint_performance, appd_diagnose_issue.

Note: AppDynamics rolls older data into coarser buckets. A narrow window far in the past may return nothing even though a wider window over the same period returns an aggregate — this is controller-side retention granularity, not a query error.

Quick Start

1. Install dependencies

npm install

2. Configure environment

Copy .env.example to .env and fill in your credentials:

cp .env.example .env

Required variables:

Variable

Description

APPD_URL

Controller base URL (e.g., https://mycompany.saas.appdynamics.com)

APPD_CLIENT_NAME

OAuth client name or API key

APPD_CLIENT_SECRET

OAuth client secret

APPD_ACCOUNT_NAME

Account name (for clientName@accountName format)

3. Add to your MCP client

Cursor (~/.cursor/mcp.json):

{
  "mcpServers": {
    "appdynamics": {
      "command": "npx",
      "args": ["tsx", "src/index.ts"],
      "cwd": "/path/to/appdynamics-mcp-server",
      "env": {
        "APPD_URL": "https://your-controller.saas.appdynamics.com",
        "APPD_CLIENT_NAME": "your-client-name",
        "APPD_CLIENT_SECRET": "your-client-secret",
        "APPD_ACCOUNT_NAME": "your-account-name"
      }
    }
  }
}

Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "appdynamics": {
      "command": "npx",
      "args": ["tsx", "/path/to/appdynamics-mcp-server/src/index.ts"],
      "env": {
        "APPD_URL": "https://your-controller.saas.appdynamics.com",
        "APPD_CLIENT_NAME": "your-client-name",
        "APPD_CLIENT_SECRET": "your-client-secret",
        "APPD_ACCOUNT_NAME": "your-account-name"
      }
    }
  }
}

Tools Reference

Discovery

Tool

Description

appd_get_applications

List all monitored applications (with optional name filter)

Health Monitoring

Tool

Description

appd_get_health_rules

List health rules or get details of a specific rule

appd_create_health_rule

Create a new health rule with warning and/or critical conditions. Supports OVERALL_APPLICATION_PERFORMANCE, BUSINESS_TRANSACTION_PERFORMANCE, TIER_NODE_HEALTH, and CUSTOM entity types. Use affectedTier or affectedNode to scope rules to a specific tier/node for custom metrics.

appd_update_health_rule

Update an existing health rule's name, conditions, thresholds, or scope

appd_delete_health_rule

Permanently delete a health rule

appd_enable_health_rule

Enable or disable a health rule

appd_get_health_violations

Get health rule violations for one or all apps

appd_get_anomalies

Get anomaly events (open-only by default)

Application Performance

Tool

Description

appd_get_business_transactions

List BTs for an application

appd_get_bt_performance

Get response time, throughput, errors for a BT

appd_get_service_endpoints

List service endpoints (API-level granularity), discovered via the metric tree

appd_get_service_endpoint_performance

Get performance metrics for a service endpoint (by name, plus optional tier)

Infrastructure

Tool

Description

appd_get_tiers_and_nodes

Get tiers with their nodes (agents, machines, IPs)

appd_get_backends

List backend dependencies (databases, APIs, caches, queues)

Diagnostics

Tool

Description

appd_get_snapshots

Get transaction snapshots (deep diagnostic captures)

appd_get_errors

Get error and exception events

Root Cause Analysis

Tool

Description

appd_diagnose_issue

Automated root cause analysis — fetches violations, anomalies, error events, and snapshots in parallel, then returns ranked candidates, a merged timeline, error breakdown, and investigation steps. Accepts a historical window; the baseline automatically becomes the equivalent window immediately before it

Metrics

Tool

Description

appd_browse_metric_tree

Browse the metric hierarchy to discover available metrics, including custom machine-agent metrics

appd_get_metric_data

Query any metric by path, over any time range. Supports rollup control: true returns a single aggregated value, false returns individual time-series data points

Dashboards

Tool

Description

appd_get_dashboards

List all custom dashboards

appd_get_dashboard

Get full dashboard definition with widgets

appd_create_dashboard

Create a new dashboard with optional widgets

appd_update_dashboard

Update dashboard properties and/or widgets

appd_add_widget_to_dashboard

Add a single widget without replacing existing ones

appd_clone_dashboard

Clone a dashboard with a new name

appd_delete_dashboard

Delete a dashboard (permanent)

appd_export_dashboard

Export dashboard as portable JSON

appd_import_dashboard

Create a new dashboard from a saved JSON definition

appd_save_dashboard_file

Build a complete dashboard JSON file locally without creating anything in AppDynamics — ready to edit and import

appd_auto_build_dashboard

Auto-discover tiers, BTs, and health rules, then create a complete multi-section dashboard in one shot

Dashboard widget types

Widget type

Description

TIMESERIES_GRAPH

Time-series line chart for one or more metrics

METRIC_VALUE

Single aggregated number (gauge tile) — stored as METRIC_LABEL in AppDynamics

GAUGE

Gauge dial

PIE

Pie chart

HEALTH_LIST

Health rule status (green/yellow/red circles). Set healthRuleIds: [id] to pin a widget to specific health rules; omit to show all rules for the application. Display options: showPie: true renders a pie chart, add innerRadius: 30-40 for a donut, showList: false hides the rule list under the chart.

TEXT

Static text / label — stored as LABEL in AppDynamics

Widgets are saved first, then their metric bindings are attached in a second pass using the server-assigned widget ids — this is what makes graphs actually render data. Metric paths are bound in one of three forms (each verified against the dashboard rendering API): Business Transaction metrics with btIds use BT criteria; app-scope metrics (Overall Application Performance, Backends, Service Endpoints, …) use the application-aggregate criteria, optionally scoped per tier via tierIds; node metrics (JVM, Hardware Resources, or Application Infrastructure Performance|Tier|… paths) use node-level criteria with the node-relative path.

Example Conversations

"What's the health status of my production apps?" → Uses appd_get_applications + appd_get_health_violations + appd_get_anomalies

"Show me the slowest business transactions for the Orders app" → Uses appd_get_business_transactions + appd_get_bt_performance

"What databases does the Payment service connect to?" → Uses appd_get_backends with typeFilter="JDBC"

"Create a health rule that fires when Custom Metrics|RequestCount > 1000 on the WebTier" → Uses appd_create_health_rule with affectedEntityType="TIER_NODE_HEALTH", affectedTier="WebTier", metricPath="Custom Metrics|RequestCount"

"Create a dashboard for the Checkout app with response time and error rate" → Uses appd_get_applications → appd_browse_metric_tree → appd_create_dashboard

"Build me a full monitoring dashboard for the Orders app" → Uses appd_auto_build_dashboard — auto-discovers all tiers, BTs, and health rules, creates a complete dashboard in one shot

"Create one health widget per URL Monitor service, each scoped to its own rule" → Uses appd_create_health_rule (one per service) + appd_create_dashboard with healthRuleIds on each HEALTH_LIST widget

"Clone the production monitoring dashboard for staging" → Uses appd_get_dashboards → appd_clone_dashboard

"Why is my Payment app slow? Diagnose the last hour" → Uses appd_diagnose_issue with application="Payment", durationInMins=60 — returns ranked root cause candidates, merged event timeline, error class breakdown, and step-by-step investigation guide

"Are there any errors spiking in the Orders app right now?" → Uses appd_diagnose_issue with application="Orders", focus="errors"

"What went wrong during yesterday's outage between 14:00 and 15:00?" → Uses appd_diagnose_issue with startTime/endTime — degradation is measured against the 14:00-preceding hour, so the report reflects that incident rather than current state

"Pull the snapshots captured during last Tuesday's slowdown" → Uses appd_get_snapshots with startTime/endTime

Health Rules — Custom Metrics

Custom metrics reported by machine agents are stored per-node under:

Application Infrastructure Performance|{Tier}|Individual Nodes|{Node}|Custom Metrics|{MetricName}

When creating health rules for custom metrics, use affectedEntityType=TIER_NODE_HEALTH and provide the relative metric path (not the full absolute path):

affectedEntityType: "TIER_NODE_HEALTH"
affectedNode: "my-server-hostname"          # scope to specific node
metricPath: "Custom Metrics|MyMetric"       # relative path only

Architecture

src/
├── index.ts              # Entry point, registers all tools
├── types.ts              # TypeScript interfaces
├── constants.ts          # Shared constants
├── services/
│   ├── auth.ts           # OAuth2 token management
│   └── api-client.ts     # Authenticated HTTP client
├── utils/
│   ├── error-handler.ts  # Error → MCP response
│   ├── app-resolver.ts   # App name → ID resolution
│   ├── time-range.ts     # Shared time-range parsing → AppD query params
│   ├── concurrency.ts    # Bounded fan-out across apps/tiers
│   └── formatting.ts     # Response formatting
└── tools/                # One file per tool domain
    ├── applications.ts
    ├── health-rules.ts        # CRUD + enable/disable
    ├── health-violations.ts
    ├── anomalies.ts
    ├── business-transactions.ts
    ├── bt-performance.ts
    ├── service-endpoints.ts
    ├── service-endpoint-paths.ts # pure SEP metric-tree paths + matching
    ├── tiers-nodes.ts
    ├── backends.ts
    ├── snapshots.ts
    ├── errors.ts
    ├── metrics.ts             # browse + query with rollup
    ├── dashboards.ts          # full CRUD + auto-build + HealthListWidget scoping
    ├── root-cause.ts
    └── root-cause-analysis.ts # pure correlation, scoring, narration

Development

# Run in dev mode (auto-reload)
npm run dev

# Build TypeScript
npm run build

# Run built version
npm start

# Unit tests — payload builders and root-cause analysis vs. ground-truth
# fixtures, plus SEP metric paths, application resolution, time-range
# resolution, response truncation, token caching, bounded concurrency,
# and error handling
npm test

# End-to-end verification: drives the MCP server against the live controller,
# creates test dashboards, and asserts the persisted widget shapes.
# Requires APPD_* env vars.
node scripts/verify-dashboard-fixes.mjs

CI runs the typecheck, the unit tests, and a server-startup smoke check on every push and pull request, plus a gitleaks secret scan over the full history. See .github/workflows/ci.yml.

Authentication

The server supports two authentication modes:

  1. OAuth2 Client Credentials (recommended): Set APPD_CLIENT_NAME, APPD_CLIENT_SECRET, and optionally APPD_ACCOUNT_NAME. The server acquires and caches tokens automatically.

  2. API Key: Set only APPD_CLIENT_NAME (as the API key). No secret needed.

Token handling details:

  • Tokens are cached until 5 minutes before expiry.

  • Concurrent callers share a single in-flight token request, so a cold start issues one OAuth exchange rather than one per parallel tool call.

  • A 401 invalidates the cached token and retries the request once with a fresh one — a token revoked before its advertised expiry recovers automatically instead of failing every call until the cache times out.

  • Credentials are never written to logs or error messages; OAuth failures log only the HTTP status code.

Never commit credentials. Keep them in .env (gitignored) or your MCP client's env block. If a secret is ever committed, rotate it in the AppDynamics controller — removing it from git history alone does not invalidate it.

Reliability

  • Bounded fan-out: tools that sweep every application or tier cap simultaneous requests (MAX_CONCURRENT_REQUESTS, default 6) instead of firing one request per entity at once, which trips controller rate limiting on large accounts.

  • Budgeted truncation: oversized responses are trimmed to the largest prefix that fits CHARACTER_LIMIT, and the note reports how many of the total items were kept.

  • Capped error bodies: upstream error payloads (including HTML error pages) are collapsed to a single line and truncated before being surfaced.

License

ISC

Available Tools

30 tools
appd_add_widget_to_dashboardAdd Widget to DashboardA

Add a single widget to an existing dashboard without replacing existing widgets.

This fetches the current dashboard, appends the new widget, and saves it.

Widget types (use exact names):

  • "TIMESERIES_GRAPH": Time-series chart (needs applicationId + metricPath)

  • "METRIC_VALUE": Single metric number (needs applicationId + metricPath)

  • "HEALTH_LIST": Health status list (needs applicationId + entityType)

  • "TEXT": Static text label (needs text)

Args:

  • dashboardId (number): Dashboard ID

  • widget: Widget object with type, title, height, width, x, y, and type-specific fields

Returns: The updated dashboard with the new widget added.

Inputs: widget (required), dashboardId (required).

appd_auto_build_dashboardAuto-Build DashboardA

Automatically build a complete monitoring dashboard for an application.

Discovers the application's tiers, business transactions, and health rules, then creates a fully populated multi-section dashboard in AppDynamics.

Focus modes:

  • "comprehensive" (default): Overview + business transactions + infrastructure + health

  • "performance": Overview + business transactions

  • "infrastructure": Overview + tier-level graphs

  • "health": Overview + health status

Args:

  • applicationName (string): Application name or numeric ID

  • dashboardName (string, optional): Dashboard name. Defaults to "{AppName} - Auto Dashboard"

  • focus (string, optional): comprehensive | performance | infrastructure | health

  • timeRangeMinutes (number, optional): Time window in minutes. Default: 60

Returns: The created dashboard name and ID.

Inputs: applicationName (required), focus, dashboardName, timeRangeMinutes.

appd_browse_metric_treeBrowse Metric TreeA
Read-onlyIdempotent

Browse the AppDynamics metric tree to discover available metric paths.

Call without metricPath to see top-level folders, then drill into specific folders by providing their path.

Common top-level folders:

  • Overall Application Performance

  • Application Infrastructure Performance

  • Business Transaction Performance

  • Backends

  • Errors

  • Service Endpoints

Custom metrics (submitted by machine agents) live under: 'Application Infrastructure Performance|{Tier}|Individual Nodes|{Node}|Custom Metrics' Use rollup=false when browsing node-level paths to ensure per-node data is returned.

Args:

  • application (string|number): App name or ID

  • metricPath (string, optional): Parent path to browse (omit for top-level)

  • rollup (boolean, optional): Aggregate across entities (default: true). Set false for node-level browsing.

Returns: Array of child metric nodes with name, type (folder or leaf), and full path.

Inputs: application (required), rollup, metricPath.

appd_clone_dashboardClone DashboardA

Clone an existing dashboard with a new name.

Creates an exact copy of the source dashboard (including all widgets) with the specified new name.

Args:

  • dashboardId (number): Source dashboard ID to clone

  • newName (string): Name for the cloned dashboard

Returns: The newly created dashboard with its new ID.

Inputs: newName (required), dashboardId (required).

appd_create_dashboardCreate DashboardA

Create a new custom dashboard in AppDynamics.

You can create a blank dashboard and add widgets later using appd_add_widget_to_dashboard, or provide widgets upfront.

Widget types (use exact names):

  • "TIMESERIES_GRAPH": Time-series line/area chart (needs applicationId + metricPath)

  • "METRIC_VALUE": Single metric number display (needs applicationId + metricPath)

  • "HEALTH_LIST": Health rule status list (needs applicationId, entityType like 'POLICY')

  • "TEXT": Static text label or title (needs text)

  • "PIE": Pie chart (needs applicationId + metricPath)

  • "GAUGE": Gauge display (needs applicationId + metricPath)

Grid layout: width max is 12 (full row). Height is in grid units (2-4 typical). Use appd_browse_metric_tree to discover metric paths for widgets.

Args:

  • name (string): Dashboard name

  • description (string, optional): Description

  • height/width (number, optional): Canvas size (default: 768x1024)

  • widgets (array, optional): Widgets to place on the dashboard

  • template (boolean, optional): Create as template

Returns: The created dashboard object with its new ID.

Inputs: name (required), width, height, widgets, +2 more.

appd_create_health_ruleCreate Health RuleA

Create a new health rule for an application.

Supports APM and SIM (Server & Infrastructure Monitoring) entity types. At least one critical condition is required.

Args:

  • application (string|number): App name or ID

  • name (string): Health rule name

  • enabled (boolean, default true)

  • affectedEntityType: BUSINESS_TRANSACTION_PERFORMANCE | APPLICATION_PERFORMANCE | TIER_NODE_HEALTH | TIER_NODE_TRANSACTION_PERFORMANCE | BACKEND_CALL_PERFORMANCE | SERVICE_ENDPOINT_PERFORMANCE | CUSTOM

  • affectedTier (string, optional): Scope to a specific tier (TIER_NODE_HEALTH / TIER_NODE_TRANSACTION_PERFORMANCE only)

  • affectedNode (string, optional): Scope to a specific node (takes precedence over affectedTier)

  • customEntityType (string, optional): Entity type for CUSTOM rules — use "SERVER" for SIM nodes

  • customEntityName (string, optional): Entity name for CUSTOM rules — use the server/node hostname

  • criticalConditions (array): at least one condition with metricPath, threshold, operator

  • warningConditions (array, optional): same structure

  • conditionAggregationType (ALL|ANY, default ALL)

  • useDataFromLastNMinutes (default 30)

  • waitTimeAfterViolation (default 30)

APM custom metrics (machine agent on APM app): use affectedEntityType=TIER_NODE_HEALTH with affectedTier or affectedNode. metricPath must be RELATIVE to the entity (e.g. "Custom Metrics|MyMetric").

SIM / URL Monitor metrics: use affectedEntityType=CUSTOM, customEntityType="SERVER", customEntityName=. metricPath must be the FULL absolute path starting with "Application Infrastructure Performance|...". Operators supported: GREATER_THAN, LESS_THAN, GREATER_THAN_EQUALS, LESS_THAN_EQUALS, EQUALS, NOT_EQUALS. Example: { metricPath: "Application Infrastructure Performance|Root|Individual Nodes|myhost|Custom Metrics|URL Monitor|SvcA|Status", threshold: 4, operator: "NOT_EQUALS" }

Returns: Created health rule object with assigned ID.

Inputs: name (required), application (required), affectedEntityType (required), criticalConditions (required), +9 more.

appd_delete_dashboardDelete DashboardA
DestructiveIdempotent

Delete a custom dashboard. This action is PERMANENT and cannot be undone.

Consider using appd_export_dashboard first to create a backup.

Args:

  • dashboardId (number): Dashboard ID to delete

Returns: Confirmation of deletion.

Inputs: dashboardId (required).

appd_delete_health_ruleDelete Health RuleA
DestructiveIdempotent

Permanently delete a health rule by ID.

This action cannot be undone. Use appd_get_health_rules to confirm the ID before deleting.

Args:

  • application (string|number): App name or ID

  • healthRuleId (number): ID of the health rule to delete

Returns: Confirmation message.

Inputs: application (required), healthRuleId (required).

appd_diagnose_issueDiagnose Issue (Root Cause Analysis)A
Read-onlyIdempotent

Perform a two-phase automated root cause analysis for an application.

Phase 1 (topology): Fetches health violations, anomalies, error events, transaction snapshots, business transactions, tiers, nodes, and backends in parallel — correlating them into ranked root cause candidates.

Phase 2 (metrics with baseline): For each affected tier, backend, and node, fetches metrics for BOTH the current window AND a prior equivalent baseline window. Anomaly flags (isSlow, isCpuSaturated, hasGcPressure) are computed as percentage degradation vs baseline — no hardcoded absolute thresholds. Example: a backend normally at 50ms now at 600ms is flagged (+1100%); one normally at 2000ms now at 2100ms is not (+5%).

Use this when you need to quickly understand why an application is behaving badly without manually calling many separate tools.

Args:

  • application (string|number): App name or numeric ID

  • durationInMins (number, optional): Lookback window in minutes (default: 60)

  • focus (string, optional): Narrow diagnosis to 'performance', 'errors', 'availability', or 'all' (default)

Returns: A structured diagnostic report with summary, causalityChain (ordered root→effect), tierMetrics, backendAnalysis, infrastructureInsights (all with baseline comparison), ranked root cause candidates, timeline, error breakdown, sample snapshots (with sqlQueries/httpCalls/errorStackTrace), and metric-aware investigation steps.

Inputs: application (required), focus, durationInMins.

appd_enable_health_ruleEnable / Disable Health RuleA
Idempotent

Enable or disable a health rule without changing any other settings.

Fetches the current rule, sets the enabled flag, and PUTs it back.

Args:

  • application (string|number): App name or ID

  • healthRuleId (number): ID of the health rule

  • enabled (boolean): true to enable, false to disable

Returns: Updated health rule object.

Inputs: enabled (required), application (required), healthRuleId (required).

appd_export_dashboardExport Dashboard JSONA
Read-onlyIdempotent

Export a dashboard as a portable JSON definition.

The exported JSON can be used to recreate the dashboard in another controller or back it up.

Args:

  • dashboardId (number): Dashboard ID to export

Returns: Complete dashboard JSON definition suitable for import.

Inputs: dashboardId (required).

appd_get_anomaliesGet Anomaly EventsA
Read-onlyIdempotent

Retrieve anomaly detection events for a specific application or all applications. By default, returns only currently open anomalies.

Set includeAll to true to see all events including closed ones.

Args:

  • application (string|number, optional): App name or ID. Omit for all apps.

  • durationInMins (number, optional): Lookback in minutes (default: 1440 = 24h)

  • severities (string, optional): Comma-separated severity levels (default: 'INFO,WARN,ERROR')

  • includeAll (boolean, optional): If true, includes all events including closed anomalies

Returns: Array of anomaly events. When querying all apps, results are grouped by application.

Inputs: includeAll, severities, application, durationInMins.

appd_get_applicationsList AppDynamics ApplicationsA
Read-onlyIdempotent

List all business applications monitored by AppDynamics.

Optionally filter by name using a case-insensitive partial match. Returns application ID, name, and description for each app.

Use this tool first to discover application IDs needed by other tools.

Args:

  • nameFilter (string, optional): Filter by application name

Returns: Array of applications with id, name, and description.

Inputs: nameFilter.

appd_get_backendsGet Backends / Remote ServicesA
Read-onlyIdempotent

List all backend (remote service) dependencies detected for an application.

Backends are external services your application calls — databases (JDBC), HTTP APIs, caches (Redis, Memcached), message queues (JMS, Kafka), etc.

This is one of AppDynamics' most powerful features for dependency mapping and troubleshooting. Slow backends are a common root cause of application performance issues.

Args:

  • application (string|number): App name or ID

  • typeFilter (string, optional): Filter by exit point type (e.g., "HTTP", "JDBC", "CACHE")

Returns: Array of backends with id, name, exitPointType, and connection properties.

Inputs: application (required), typeFilter.

appd_get_bt_performanceGet BT Performance MetricsA
Read-onlyIdempotent

Get performance metrics for a specific business transaction (BT).

Retrieves average response time, calls per minute, errors per minute, slow calls, very slow calls, and stall count for the specified BT.

Use appd_get_business_transactions first to find the BT ID.

Args:

  • application (string|number): App name or ID

  • btId (number): Business transaction ID

  • durationInMins (number, optional): Lookback in minutes (default: 60)

Returns: BT details plus metric data for each performance metric.

Inputs: btId (required), application (required), durationInMins.

appd_get_business_transactionsList Business TransactionsA
Read-onlyIdempotent

List all business transactions (BTs) for a given application.

BTs are the key unit of monitoring in AppDynamics — each represents a distinct user request or workflow. Use this to discover BT IDs neeed by appd_get_bt_performance.

Args:

  • application (string|number): App name or IF

  • tierFilter (string, optional): Filter by tier name

Returns: Array of BTs with id, name, tierName, entryPointType.

Inputs: application (required), tierFilter.

appd_get_dashboardGet Dashboard DetailsA
Read-onlyIdempotent

Get the full definition of a specific dashboard, including all widgets and their configurations.

This reveals what metrics and entities the dashboard monitors — useful for understanding what a team cares about, or for cloning/modifying dashboards.

Args:

  • dashboardId (number): Dashboard ID (from appd_get_dashboards)

Returns: Complete dashboard object with widgets, layout, and data source configuration.

Inputs: dashboardId (required).

appd_get_dashboardsList DashboardsA
Read-onlyIdempotent

List all custom dashboards in AppDynamics.

Returns dashboard summaries including id, name, creator, and timestamps. Use nameFilter to search for specific dashboards.

Args:

  • nameFilter (string, optional): Filter by dashboard name

Returns: Array of dashboard summaries.

Inputs: nameFilter.

appd_get_errorsGet Error EventsA
Read-onlyIdempotent

Retrieve error and exception events for an application.

Returns ERROR, APPLICATION_ERROR, and APPLICATION_CRASH events from the AppDynamics events API. These represent exceptions, application errors, and crashes detected by the agent.

Args:

  • application (string|number): App name or ID

  • durationInMins (number, optional): Lookback in minutes (default: 60)

Returns: Array of error events with severity, summary, timestamp, and affected entity details.

Inputs: application (required), durationInMins.

appd_get_health_rulesList Health RulesA
Read-onlyIdempotent

List health rules configured for an application, or get details of a specific health rule.

Health rules define the thresholds and conditions that trigger violations. Understanding what health rules exist and their configuration is essential context for interpreting violations.

Without healthRuleId: returns a summary list of all health rules (id, name, type, enabled, affected entity type). With healthRuleId: returns the full configuration of that specific health rule including evaluation criteria.

Args:

  • application (string|number): App name or ID

  • healthRuleId (number, optional): Specific health rule ID for details

Returns: Array of health rules or single detailed health rule object.

Inputs: application (required), healthRuleId.

appd_get_health_violationsGet Health Rule ViolationsA
Read-onlyIdempotent

Retrieve health rule violations for a specific application or all applications.

If application is not provided, returns violations across all monitored applications. Supports application lookup by name or numeric ID.

Args:

  • application (string|number, optional): App name or ID. Omit for all apps.

  • durationInMins (number, optional): Lookback window in minutes (default: 1440 = 24h)

Returns: Array of health rule violations with severity, status, affected entity, and timestamps.

Inputs: application, durationInMins.

appd_get_metric_dataGet Metric DataA
Read-onlyIdempotent

Query any metric from the AppDynamics metric tree.

This is a generic tool that can retrieve any metric — infrastructure (CPU, memory, disk), application performance, custom metrics, etc.

Use appd_browse_metric_tree to discover available metric paths first.

Custom metrics: Machine agent custom metrics are stored per-node, not aggregated at tier level. To query them, use rollup=false and a node-level path: 'Application Infrastructure Performance|{Tier}|Individual Nodes|{Node}|Custom Metrics|{MetricName}' Wildcard example: 'Application Infrastructure Performance||Individual Nodes||Custom Metrics|MyMetric' with rollup=false

Args:

  • application (string|number): App name or ID

  • metricPath (string): Full metric path (pipe-separated)

  • durationInMins (number, optional): Lookback in minutes (default: 60)

  • rollup (boolean, optional): Aggregate across entities (default: true). Set false for custom/per-node metrics.

Returns: Array of metric data objects with timestamps, min, max, avg, count, sum values.

Inputs: metricPath (required), application (required), rollup, durationInMins.

appd_get_service_endpoint_performanceGet Service Endpoint PerformanceA
Read-onlyIdempotent

Get performance metrics for a specific service endpoint.

Retrieves average response time, calls per minute, and errors per minute for the specified service endpoint.

Use appd_get_service_endpoints first to find the SEP ID.

Args:

  • application (string|number): App name or ID

  • sepId (number): Service endpoint ID

  • durationInMins (number, optional): Lookback in minutes (default: 60)

Returns: Performance metrics for the service endpoint.

Inputs: sepId (required), application (required), durationInMins.

appd_get_service_endpointsList Service EndpointsA
Read-onlyIdempotent

List service endpoints (SEPs) for an application.

Service endpoints represent individual API endpoints or servlet mappings within your application tiers. They provide more granular performance data than business transactions — you can see which specific URL paths or service methods are slow.

Args:

  • application (string|number): App name or ID

  • tierFilter (string, optional): Filter by tier name

Returns: Array of service endpoints with id, name, tier info, and type.

Inputs: application (required), tierFilter.

appd_get_snapshotsGet Transaction SnapshotsA
Read-onlyIdempotent

Retrieve transaction snapshots (slow, error, stall) for an application.

Snapshots are deep diagnostic captures of individual requests. They show call graphs, SQL queries, HTTP calls, and more for requests that were slow, errored, or stalled.

Args:

  • application (string|number): App name or ID

  • durationInMins (number, optional): Lookback in minutes (default: 30)

  • guids (string, optional): Specific snapshot GUIDs

  • dataCollectorName/Type/Value (string, optional): Data collector filters

  • maxResults (number, optional): Max snapshots to return (default: 20, max: 100)

Returns: Array of snapshot objects with timing, error details, and diagnostic info.

Inputs: application (required), guids, maxResults, durationInMins, +3 more.

appd_get_tiers_and_nodesGet Tiers and NodesA
Read-onlyIdempotent

Retrieve the tiers and nodes (infrastructure topology) for an application.

Shows each tier with its type, agent type, and associated nodes. Nodes include machine details, agent versions, and IP addresses.

Args:

  • application (string|number): App name or ID

Returns: Array of tiers, each with a nested array of nodes.

Inputs: application (required).

appd_import_dashboardImport Dashboard from JSONA

Create a new dashboard from a JSON definition string.

Accepts the JSON output of appd_export_dashboard (or any saved dashboard JSON file) and creates a new dashboard from it. The original ID is always discarded — AppDynamics assigns a fresh one.

Typical workflow:

  1. appd_export_dashboard → save JSON to a file

  2. Edit the file if needed (rename, adjust metrics, etc.)

  3. appd_import_dashboard with the file contents → new dashboard created

Args:

  • dashboardJson (string): Full dashboard JSON (paste contents of an exported file)

  • dashboardName (string, optional): Override the name from the JSON

Returns: The newly created dashboard with its new ID.

Inputs: dashboardJson (required), dashboardName.

appd_save_dashboard_fileSave Dashboard Definition to FileA

Build a complete AppDynamics dashboard JSON definition and save it to a local file — without creating anything in AppDynamics yet.

The saved file can be:

  • Inspected or edited before importing

  • Version-controlled alongside your code

  • Imported with appd_import_dashboard at any time

The file format is identical to appd_export_dashboard output and is directly importable.

Widget types (use exact names):

  • "TIMESERIES_GRAPH": Time-series chart (needs applicationId + metricPath)

  • "METRIC_VALUE": Single metric number (needs applicationId + metricPath)

  • "HEALTH_LIST": Health status list (needs applicationId + entityType)

  • "TEXT": Static label or section heading (needs text)

  • "PIE": Pie chart (needs applicationId + metricPath)

  • "GAUGE": Gauge (needs applicationId + metricPath)

Grid layout: width max is 12 (full row). Height is in grid units (1–4 typical). Use appd_browse_metric_tree to discover metric paths.

Args:

  • name (string): Dashboard name

  • filePath (string, optional): Where to write the file. Default: ./dashboard-{name}.json

  • description (string, optional): Dashboard description

  • height/width (number, optional): Canvas size in pixels (default: 768×1024)

  • widgets (array, optional): Widget definitions

Returns: Absolute path of the saved file and a widget summary.

Inputs: name (required), width, height, widgets, +2 more.

appd_update_dashboardUpdate DashboardA
Idempotent

Update an existing dashboard's properties and/or widgets.

IMPORTANT: If you provide widgets, this REPLACES all existing widgets. To add a single widget without losing existing ones, use appd_add_widget_to_dashboard instead.

Args:

  • dashboardId (number): Dashboard ID

  • name (string, optional): New name

  • description (string, optional): New description

  • height/width (number, optional): New canvas size

  • widgets (array, optional): Complete widget set (replaces existing)

Returns: The updated dashboard object.

Inputs: dashboardId (required), name, width, height, +2 more.

appd_update_health_ruleUpdate Health RuleA
Idempotent

Update an existing health rule by ID.

Fetches the current rule, merges the provided fields, then PUTs the updated rule back. Only fields you supply are changed; unspecified fields retain their current values.

Args:

  • application (string|number): App name or ID

  • healthRuleId (number): ID of the health rule to update

  • name, enabled, affectedEntityType, criticalConditions, warningConditions, conditionAggregationType, useDataFromLastNMinutes, waitTimeAfterViolation — all optional

Returns: Updated health rule object.

Inputs: application (required), healthRuleId (required), name, enabled, +10 more.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.1/5.0

    Scored across 30 tools

    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.

    Maintenance

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      B
      quality
      Not graded
      maintenance
      A Model Context Protocol server that enables AI assistants to interact with Datadog's observability platform through natural language.
      72
      MIT
    • A
      license
      Not graded
      quality
      Not graded
      maintenance
      A Model Context Protocol server that provides access to Observe API functionality, enabling LLMs to execute OPAL queries, manage datasets/monitors, and leverage vector search for documentation and troubleshooting runbooks.
      1
      -
    • A
      license
      B
      quality
      D
      maintenance
      A Model Context Protocol server that enables AI assistants to query Prometheus metrics, discover available data, and analyze system performance through natural language interactions.
      5
      242 npm
      MIT
    • A
      license
      Not graded
      quality
      D
      maintenance
      A Model Context Protocol server that enables AI agents to interact directly with Prometheus metrics data through natural language queries.
      MIT