Skip to main content
Glama
jagalliers

appd-mcp

by jagalliers

Get AppDynamics health rule violations

appd_get_health_rule_violations

Retrieve open or recently-closed health rule violations for any application over a specified time window. Quickly identify critical rule breaches to resolve issues.

Instructions

Retrieve open / recently-closed health rule violations for an application within a time window.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
applicationYes
timeRangeNoAppD time range. Defaults to BEFORE_NOW with durationMinutes=30 if omitted by the caller.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
summaryYes
evidenceNo
entitiesYes
timeRangeNo
sourceEndpointsYes
paginationNo
warningsYes
truncatedYes

Implementation Reference

  • Input schema for the tool: requires application (appRefSchema) and optional timeRange.
    const inputShape = {
      application: appRefSchema,
      timeRange: timeRangeSchema.optional(),
    };
    
    interface Violation {
      id?: number;
      name?: string;
      description?: string;
      severity?: string;
      affectedEntityDefinition?: { entityType?: string; entityId?: number; name?: string };
      triggeredEntityDefinition?: { entityType?: string; entityId?: number; name?: string };
      startTimeInMillis?: number;
      endTimeInMillis?: number;
      detectedTimeInMillis?: number;
      incidentStatus?: string;
      // varies by API version
    }
    
    interface ViolationsEvidence {
      application: AppRef;
      count: number;
      violations: Violation[];
    }
  • TypeScript interfaces Violation and ViolationsEvidence defining the shape of output data.
    interface Violation {
      id?: number;
      name?: string;
      description?: string;
      severity?: string;
      affectedEntityDefinition?: { entityType?: string; entityId?: number; name?: string };
      triggeredEntityDefinition?: { entityType?: string; entityId?: number; name?: string };
      startTimeInMillis?: number;
      endTimeInMillis?: number;
      detectedTimeInMillis?: number;
      incidentStatus?: string;
      // varies by API version
    }
    
    interface ViolationsEvidence {
      application: AppRef;
      count: number;
      violations: Violation[];
    }
  • Tool registration: exports getHealthRuleViolationsTool as a ToolRegistration with name 'appd_get_health_rule_violations', profile 'read', and register() function that calls server.registerTool.
    export const getHealthRuleViolationsTool: ToolRegistration = {
      name: 'appd_get_health_rule_violations',
      profile: 'read',
      register(server, services) {
        server.registerTool(
          'appd_get_health_rule_violations',
          {
            title: 'Get AppDynamics health rule violations',
            description:
              'Retrieve open / recently-closed health rule violations for an application within a time window.',
            inputSchema: inputShape,
            outputSchema: envelopeOutputShape,
          },
          wrapHandler<{ application: AppRef; timeRange?: TimeRange | undefined }, ViolationsEvidence>(
            services.log,
            'appd_get_health_rule_violations',
            async (input) => {
              const tr = input.timeRange ?? DEFAULT_TIME_RANGE;
              const params = applyTimeRangeToParams(tr);
              const appPath = appRefToPath(input.application);
              const path = `applications/${appPath}/problems/healthrule-violations`;
              const res = await services.controller.get<Violation[]>(path, Object.fromEntries(params));
              const violations = Array.isArray(res.body) ? res.body : [];
    
              return toToolResult(
                buildEnvelope({
                  summary: `${violations.length} health rule violation${violations.length === 1 ? '' : 's'}.`,
                  evidence: {
                    application: input.application,
                    count: violations.length,
                    violations,
                  } as ViolationsEvidence,
                  entities: [{ kind: 'application', id: input.application }],
                  timeRange: toEnvelopeTimeRange(tr),
                  sourceEndpoints: [`GET /controller/rest/${path}`],
                  warnings: timeRangeWarnings(tr),
                }),
              );
            },
          ),
        );
      },
    };
  • Handler function that fetches health rule violations from the AppDynamics controller API (/applications/{app}/problems/healthrule-violations), processes time range, and returns results wrapped in an envelope.
    async (input) => {
      const tr = input.timeRange ?? DEFAULT_TIME_RANGE;
      const params = applyTimeRangeToParams(tr);
      const appPath = appRefToPath(input.application);
      const path = `applications/${appPath}/problems/healthrule-violations`;
      const res = await services.controller.get<Violation[]>(path, Object.fromEntries(params));
      const violations = Array.isArray(res.body) ? res.body : [];
    
      return toToolResult(
        buildEnvelope({
          summary: `${violations.length} health rule violation${violations.length === 1 ? '' : 's'}.`,
          evidence: {
            application: input.application,
            count: violations.length,
            violations,
          } as ViolationsEvidence,
          entities: [{ kind: 'application', id: input.application }],
          timeRange: toEnvelopeTimeRange(tr),
          sourceEndpoints: [`GET /controller/rest/${path}`],
          warnings: timeRangeWarnings(tr),
        }),
      );
    },
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It only states retrieval, implying a read operation, but does not mention if it's read-only, any side effects, authentication needs, or rate limits. The absence of such context leaves the agent uninformed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence that conveys the core purpose without any extraneous words. Efficient and clear.

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 sibling tools for anomalies and events, the description does not clarify how health rule violations differ from those. It also lacks explanation of 'open/recently-closed' status. However, the output schema is not required to be described, so completeness is adequate but not high.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description only mentions 'within a time window', which is already covered by the input schema's details on timeRange including defaults and subtypes. The application parameter is also described in the schema. The description adds little value 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 the verb 'Retrieve' and the resource 'open / recently-closed health rule violations' for an application within a time window. It distinguishes from sibling tools like appd_get_events or appd_get_anomaly_violations by focusing specifically on health rule violations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving health rule violations within a time window but does not explicitly state when to use this tool versus alternatives like appd_get_anomaly_violations. No when-not-to-use or prerequisite information is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/jagalliers/appd-mcp'

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