AppDynamics MCP Server
This server provides a comprehensive MCP interface to AppDynamics, enabling natural language access to monitoring data and management across 30+ tools. You can:
Discover applications by listing and searching.
Manage health rules with full CRUD, conditional creation (for various entity types), partial updates, and enable/disable; retrieve health rule violations and anomaly events.
Analyze application performance by listing business transactions and service endpoints, and fetching metrics like response time, throughput, and errors.
Inspect infrastructure by retrieving tiers, nodes, and backend dependencies (databases, HTTP APIs, caches, queues), filterable by type.
Perform diagnostics with transaction snapshots and error/exception events.
Conduct automated root cause analysis using a two-phase analysis that correlates violations, anomalies, errors, and snapshots, with focus modes (performance, errors, availability) and historical time windows.
Query metrics by browsing the metric tree and querying any metric with configurable time ranges and rollup control.
Manage dashboards with full CRUD, widget management, cloning, export/import, saving JSON locally, and auto-building multi-section dashboards in one step. All time-aware tools support flexible time ranges via duration, start/end times in ISO 8601 or epoch milliseconds.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@AppDynamics MCP Server show health violations for the payment app"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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 |
|
| Last N minutes |
|
| Exactly that window |
|
| N minutes before that point |
|
| N minutes after that point |
|
// "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 install2. Configure environment
Copy .env.example to .env and fill in your credentials:
cp .env.example .envRequired variables:
Variable | Description |
| Controller base URL (e.g., |
| OAuth client name or API key |
| OAuth client secret |
| Account name (for |
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 |
| List all monitored applications (with optional name filter) |
Health Monitoring
Tool | Description |
| List health rules or get details of a specific rule |
| Create a new health rule with warning and/or critical conditions. Supports |
| Update an existing health rule's name, conditions, thresholds, or scope |
| Permanently delete a health rule |
| Enable or disable a health rule |
| Get health rule violations for one or all apps |
| Get anomaly events (open-only by default) |
Application Performance
Tool | Description |
| List BTs for an application |
| Get response time, throughput, errors for a BT |
| List service endpoints (API-level granularity), discovered via the metric tree |
| Get performance metrics for a service endpoint (by name, plus optional |
Infrastructure
Tool | Description |
| Get tiers with their nodes (agents, machines, IPs) |
| List backend dependencies (databases, APIs, caches, queues) |
Diagnostics
Tool | Description |
| Get transaction snapshots (deep diagnostic captures) |
| Get error and exception events |
Root Cause Analysis
Tool | Description |
| 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 |
| Browse the metric hierarchy to discover available metrics, including custom machine-agent metrics |
| Query any metric by path, over any time range. Supports |
Dashboards
Tool | Description |
| List all custom dashboards |
| Get full dashboard definition with widgets |
| Create a new dashboard with optional widgets |
| Update dashboard properties and/or widgets |
| Add a single widget without replacing existing ones |
| Clone a dashboard with a new name |
| Delete a dashboard (permanent) |
| Export dashboard as portable JSON |
| Create a new dashboard from a saved JSON definition |
| Build a complete dashboard JSON file locally without creating anything in AppDynamics — ready to edit and import |
| Auto-discover tiers, BTs, and health rules, then create a complete multi-section dashboard in one shot |
Dashboard widget types
Widget type | Description |
| Time-series line chart for one or more metrics |
| Single aggregated number (gauge tile) — stored as |
| Gauge dial |
| Pie chart |
| Health rule status (green/yellow/red circles). Set |
| Static text / label — stored as |
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 onlyArchitecture
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, narrationDevelopment
# 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.mjsCI 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:
OAuth2 Client Credentials (recommended): Set
APPD_CLIENT_NAME,APPD_CLIENT_SECRET, and optionallyAPPD_ACCOUNT_NAME. The server acquires and caches tokens automatically.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
401invalidates 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 toolsappd_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 TreeARead-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 DashboardADestructiveIdempotent
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 RuleADestructiveIdempotent
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)ARead-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 RuleAIdempotent
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 JSONARead-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 EventsARead-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 ApplicationsARead-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 ServicesARead-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 MetricsARead-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 TransactionsARead-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 DetailsARead-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 DashboardsARead-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 EventsARead-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 RulesARead-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 ViolationsARead-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 DataARead-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 PerformanceARead-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 EndpointsARead-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 SnapshotsARead-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 NodesARead-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:
appd_export_dashboard → save JSON to a file
Edit the file if needed (rename, adjust metrics, etc.)
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 DashboardAIdempotent
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 RuleAIdempotent
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
Scored across 30 tools
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.
All tools follow a consistent 'appd_verb_noun' pattern (e.g., appd_get_applications, appd_create_dashboard). There are no deviations or mixed conventions.
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.
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
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Related MCP Servers
- AlicenseBqualityNot gradedmaintenanceA Model Context Protocol server that enables AI assistants to interact with Datadog's observability platform through natural language.72MIT
- AlicenseNot gradedqualityNot gradedmaintenanceA 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-
- AlicenseBqualityDmaintenanceA Model Context Protocol server that enables AI assistants to query Prometheus metrics, discover available data, and analyze system performance through natural language interactions.5242 npmMIT
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that enables AI agents to interact directly with Prometheus metrics data through natural language queries.MIT