appd-mcp

by jagalliers

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.2
Disambiguation5/5
Each tool targets a distinct AppDynamics resource or function (e.g., alerting config, anomaly violations, application model, dependency map, events, health rule violations, metric hierarchy, transaction snapshots, applications list, health rules list, analytics events, metrics query). No overlapping purposes; descriptions clearly differentiate the tools.
Naming Consistency5/5
All tools follow a consistent 'appd_verb_noun' pattern in snake_case. Verbs are predominantly 'get', 'list', or 'query', applied appropriately to each operation. The naming is predictable and aids agent selection.
Tool Count5/5
12 tools is well-scoped for an AppDynamics monitoring server. The set covers essential monitoring and RCA workflows without being overwhelming. Each tool serves a clear purpose and earns its place.
Completeness4/5
The tool surface covers key monitoring operations: application discovery, model, health rule violations, anomaly violations, events, metrics, transaction snapshots, dependencies, alerting config, health rules, metric hierarchy, and analytics events. Minor gaps exist (e.g., no tool for dashboard retrieval or detailed health rule by ID), but core workflows are fully supported.
Average 3.7/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on May 27, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It only discloses the behavioral impact of fetchSuspectedCause (heavier response), but omits other behavioral traits like read-only nature, permission requirements, rate limits, or pagination behavior. Significant gaps remain.
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 at two sentences with zero wasted words. All critical information is front-loaded, and the fetchSuspectedCause detail is efficiently appended.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters including a complex timeRange union and pagination, the description fails to explain most parameters. It only covers fetchSuspectedCause. With an output schema present, return values are covered, but overall context for effective use is lacking.
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 description adds meaningful context for fetchSuspectedCause, explaining its effect on response size. However, with 60% schema description coverage and 5 parameters, the description does not compensate for undocumented parameters like pageSize or the timeRange structure in enough detail. Basic value added but insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Retrieve anomaly violations for an application within a time window', clearly indicating the verb (retrieve) and resource (anomaly violations for an application). It distinguishes from the sibling tool 'appd_get_health_rule_violations' by focusing on anomaly violations versus health rule violations, though it does not explicitly name the sibling.
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 anomaly violations within a time window, but it does not provide when-to-use or when-not-to-use guidance relative to siblings like 'appd_get_events' or 'appd_get_health_rule_violations'. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. It mentions the 600-event limit but omits details like pagination behavior, ordering, result format, or read-only nature. A mutation vs read distinction is not clarified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 17 words, efficiently front-loading the core action and filters. No redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the timeRange parameter (4 variants) and the presence of an output schema, the description lacks detail on how to construct the time range, what severity values mean, or any examples. It is too sparse for a tool with nested objects.
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 75%, and the schema provides descriptions for most parameters. The description adds no additional semantic value beyond summarizing the filter criteria. Baseline of 3 is appropriate as the schema does the heavy lifting.
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', the resource 'events', and key filters (application, type, severity, time window). It also specifies a limit of 600 events. This distinguishes it from sibling tools which deal with alerts, violations, metrics, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use, or suggest sibling tools for different use cases.
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?
The description discloses that confidence depends on snapshot density and that a warning surfaces when data is sparse, which is helpful. However, with no annotations, it does not state whether the operation is read-only or destructive, nor any side effects. More behavioral context would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first defines the core function, the second adds important behavioral nuance about confidence and warnings. It is concise, front-loaded, and every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that synthesizes from model and snapshots, the description covers the transformation and output quality hint. With an output schema present, return value details are not needed. However, it lacks prerequisites (e.g., snapshots must exist) and any performance or resource considerations, leaving some gaps for a complex operation.
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 does not add any information beyond the input schema. The schema already describes the parameters (application as name or id, timeRange with type and duration). Given 50% schema description coverage, the description missed an opportunity to clarify parameter usage or defaults beyond what the 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 clearly states it synthesizes a tier→tier/backend dependency map from the application model and transaction snapshots, which is specific and differentiates it from sibling tools like appd_get_application_model or appd_get_transaction_snapshots. The mention of MCP-level aggregation and confidence dependence on snapshot density adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings. The description does not mention prerequisites (e.g., needing transaction snapshots), alternatives, or exclusions. This leaves the agent without context to decide between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions the API and optional fan-out for full definitions, but omits details like error handling, performance impact, or required permissions. Partial transparency.
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?
Two concise sentences, front-loaded with purpose and optional behavior. No extraneous information.
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?
Output schema exists, so return values need not be described. Tool is simple with 3 params, but lacks context on usage scenarios, limitations, or error states. Adequate but with notable gaps.
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?
Schema coverage is 67% and the description does not explain parameters individually. It hints at expandDetails with 'optionally fan out' but does not describe application or maxDetailFanout. Minimal added 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 the tool lists health rule summaries (id, name, enabled) for an application via the Alerting REST v1 API, and optionally fetches full rule definitions. This is specific and distinguishes from siblings that deal with violations or other configs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like appd_get_health_rule_violations or appd_get_alerting_config. The description only states what it does, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It indicates a read-like operation ('Retrieve') but does not disclose side effects, authentication needs, rate limits, pagination, or any constraints beyond the time window. The description is minimal in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb, and contains no redundant information. Every word contributes to the purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with 2 parameters and an output schema. The description covers the basic functionality but lacks details like default time range (though mentioned in schema), return format, or filtering capabilities. It is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (application, timeRange) have detailed descriptions in the schema. The description adds no further meaning beyond the schema, as it only restates the overall purpose. With high schema description coverage, the description provides marginal added value for parameter semantics.
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', which is specific and distinguishes from sibling tools like appd_list_health_rules (lists rules, not violations) and appd_get_anomaly_violations (different violation type).
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 but does not specify when to use this tool versus alternatives like appd_get_anomaly_violations or when not to use it. No explicit context or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description relies on itself to convey behavioral traits. It discloses capacity limits (cap 100, max 600) and a usage hint, but does not mention whether the operation is read-only, authentication needs, pagination, or response format. It provides some value but not comprehensive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and includes key constraints and usage hint. Every word contributes value, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity with 11 parameters and an output schema, the description covers only capacity limits and one parameter's use case. It lacks guidance on common filters or response structure, leaving the agent needing to infer from the schema. It is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for the needExitCalls parameter by linking it to dependency-map analysis, which is beyond the schema. However, with 64% schema coverage, many parameters already have descriptions; the description does not compensate fully for the undocumented ones. It adds moderate value.
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 'slow/error/diagnostic transaction snapshots for an application', making it specific. It also hints at a sibling tool (dependency map) for context, distinguishing its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a hint for when to use the needExitCalls parameter for dependency-map analysis, but does not explicitly state when to use this tool over alternatives or when not to use it. This leaves room for ambiguity.
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?
The description discloses the parallel fetching behavior, which is a key behavioral trait beyond the input schema. However, it does not mention any potential side effects, resource implications, or rate limits. Since no annotations are provided, the description carries the full burden for behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first delivers the core functionality with action and scope, the second provides contextual importance. Every word earns its place, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and hints at the tool's role in RCA workflows. While it does not explicitly mention prerequisites or usage order among siblings, the hint is sufficient given the output schema exists and the tool is relatively straightforward. The completeness is adequate but could be improved with more explicit linkage to other tools.
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 description mentions the component types (business transactions, tiers, nodes, backends) that correspond to the 'include' parameter enum values, but it does not add any new meaning beyond what is already in the schema. With schema coverage at 50%, the description partially reinforces the parameter semantics but does not compensate fully.
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 action (fetch) and the resources (business transactions, tiers, nodes, backends) for one application, and highlights the parallel execution. It also positions the tool as an anchor for RCA workflows, distinguishing it from other tools that have more specific scopes.
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 ('Anchor for nearly all RCA workflows') but does not explicitly specify when to use this tool versus its siblings, nor does it mention any prerequisites or exclusions. The guidance is implied rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the scope (visible to configured API Client) and filter limitation (SaaS only), but does not mention pagination, rate limits, or output structure beyond what the output schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose and includes the optional filter with its constraint. No wasted 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 list tool with one optional parameter and an existing output schema, the description is fairly complete. It covers the main functionality and filter conditions. Minor gaps include lack of mention of result ordering or limits, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the tool description adds no additional meaning beyond the schema. The description reiterates the filter option but does not provide new insights into the parameter's semantics or 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 clearly states it lists business applications visible to the configured API Client, with an optional alive filter. The verb 'list' and resource 'applications' are specific, and the description distinguishes from sibling 'get' tools that target specific items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage condition for the filter (SaaS only) but does not explicitly state when not to use this tool or suggest alternative tools from the sibling list. The guidance is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the two modes and the need for env vars, but does not describe read/write nature, rate limits, pagination, or error handling. The description is adequate but not rich; the schema covers limits and mutual exclusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and contains no unnecessary words. It efficiently communicates the essential 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 presence of an output schema and high parameter coverage, the description does not need to explain return values. It covers the main purpose, modes, and prerequisites. Minor gaps: could clarify that limit is single-query only, but schema already states that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The tool description adds no additional meaning beyond mentioning two modes, which is already implied by the parameter descriptions. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (run an ADQL query), the resource (Events Service), and distinguishes two modes (single string vs array). It differentiates from sibling tools like appd_query_metrics by specifying ADQL against Events Service.
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?
It mentions two modes and prerequisites (env vars), but does not explicitly state when to use one mode over the other or contrast with sibling tools like appd_get_events. The context is clear but lacks explicit when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it is a composite read performing parallel fetches via the Alerting REST v1 API. This gives the agent awareness of multiple API calls. It does not cover permissions or rate limits, but read-only nature is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first explains what the tool does, the second explains its use case. Every word contributes value, and the information is front-loaded. No unnecessary elaboration.
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 an output schema exists, return values do not need description. The description covers the composite nature, API used, and purpose. It lacks detail on potential heavy load or error handling, but overall is complete for an inventory read 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?
The input schema already provides a description for the 'application' parameter (name or numeric id). The tool description does not add any additional meaning beyond stating it operates on one application. With 0% schema_description_coverage (per context), the description should compensate, but it still meets the 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 it is a composite read that fetches health rules, policies, actions, and schedules for one application. It distinguishes from siblings like appd_list_health_rules which only fetch health rules, making the purpose specific and non-overlapping.
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 ends with 'Use this for "what alerts and to whom" inventories,' providing a clear context for its use. It does not explicitly mention when not to use it or alternatives, but the sibling tools imply those.
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?
The description discloses default behavior (BEFORE_NOW 30 minutes, rollup=true) and mentions surfacing granularity/long-window warnings. As a read operation without annotations, this provides adequate transparency.
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 with three sentences, each providing essential information 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?
Combined with the output schema, the description covers key behavior, defaults, and warnings. It lacks mention of parallel path fan-out, but the schema covers that.
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?
The description adds value beyond the schema by specifying defaults and warning behavior. The schema already covers parameter descriptions, but the description enhances understanding with operational details.
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 fetches metric paths over a time range using metric-data-v2. It specifies the verb 'Fetch' and the resource 'metric paths', distinguishing it from siblings like appd_query_analytics_events.
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 when-to-use or when-not-to-use guidance is given. However, the purpose is specific enough that agents can infer usage based on sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses caching behavior (5 minutes) and explains the dual behavior based on parameter presence. It does not cover error conditions or rate limits, but given the missing annotations, it does reasonably well.
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—two sentences that pack essential information. No wasted words, and the purpose is front-loaded.
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 has only 2 parameters (1 required) and an output schema exists, the description covers the core behavior and caching. It could mention pagination or error handling, but for a hierarchy-walking tool, it is sufficiently 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 50%. The description adds meaningful context for the metricPath parameter, including an example and clarification on encoding. The application parameter is well-documented in the schema, so the description does not need to add more.
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 'walks the metric hierarchy' for one application and distinguishes behavior based on whether metricPath is provided: returns top-level folders without it, children at that level with it. This differentiates it from sibling tools like appd_query_metrics.
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 tells when to use the tool with and without the metricPath parameter. It does not mention when not to use it or suggest alternatives, but the context is clear enough for an agent to decide.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jagalliers/appd-mcp'

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