Skip to main content
Glama
godrix

@godrix/argocd-mcp

by godrix
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Server Quality Checklist

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

  • Latest release: v0.6.1

  • Disambiguation4/5

    Most tools have distinct purposes, but there is some overlap among refresh tools (refresh-application, refresh-application-cache, refresh-application-observability) and multiple get-application* tools that could be confused if not read carefully. Descriptions are detailed enough to differentiate, but minor ambiguity remains.

    Naming Consistency2/5

    Naming conventions are mixed: some tools use snake_case (argocd_auth_status, argocd_login), while most use kebab-case (get-application, list-applications). Verb placement varies (prefix vs suffix). No consistent verb_noun or noun_verb pattern, making it harder to predict tool names.

    Tool Count4/5

    26 tools is slightly above the typical range, but it reflects the complexity of Argo CD operations (authentication, application inspection, syncing, troubleshooting). A few tools are UI-specific (refresh-application-observability), but overall the count is justified for the domain.

    Completeness3/5

    The tool set covers many common tasks (list, get, sync, search, diagnose), but notable gaps include missing create/update/delete application tools and limited project management beyond listing. This means agents cannot perform full lifecycle management.

  • Average 3.7/5 across 26 of 26 tools scored. Lowest: 2.9/5.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • 4 commits in the last 12 weeks
    • Last stable release on
    • 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?

    With no annotations provided, the description carries full burden. It states the tool is read-only and mutations are blocked, which is key behavioral info. However, the input schema contradicts this by including mutation HTTP methods (POST, PUT, PATCH, DELETE), creating a significant inconsistency that undermines transparency.

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

    Conciseness4/5

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

    The description is two short sentences, front-loaded with purpose. It is concise without waste. However, it could be slightly improved by addressing the contradiction with schema or adding a brief example.

    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 tool has 6 parameters including nested objects and no output schema, the description lacks important context such as example API paths, how to handle pathParams/queryParams, what happens when a mutation is attempted, and prerequisites like authentication. The contradiction further reduces completeness.

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

    Parameters3/5

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

    Schema coverage is 100% with descriptions for all 6 parameters. The tool description does not add any parameter information beyond the schema, so it meets the baseline of 3. No additional meaning or usage hints are provided.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose4/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description states 'Execute a read-only Argo CD REST API call (GET)', which clearly identifies the tool as a generic read-only API caller for Argo CD. This distinguishes it from sibling tools that perform specific operations (e.g., get-application, list-applications). However, the schema allows mutation methods, causing some confusion.

    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 says 'Mutations are blocked while ARGOCD_READ_ONLY=true', implying it's for read-only operations, but it does not provide explicit guidance on when to use this tool versus sibling tools like get-application or list-applications. 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?

    The only behavioral trait disclosed is 'Blocked while ARGOCD_READ_ONLY=true', which is useful but insufficient. With no annotations provided, the description should explain that sync may change application state, potentially delete or update resources, and could be a long-running operation. It also fails to mention confirmation steps or the impact of parameters like 'force' and 'prune'.

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

    Conciseness4/5

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

    The description is very concise at two sentences, with no wasted words. It is structured as a single line of purpose followed by a condition. While short, it is efficient. However, the brevity sacrifices important context, preventing a perfect score.

    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?

    For a mutation tool with 6 parameters, no output schema, and no annotations, the description is far too sparse. It does not explain return values, error conditions, the concept of 'target state', or how to verify success. Many sibling tools are read-only, so this tool's mutation behavior needs more explicit context.

    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 has 100% description coverage, meaning each parameter already has a description (e.g., 'Force sync (replace)', 'Prune resources during sync'). The tool description does not add any additional meaning or context, so the score is at baseline for well-documented schemas.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose4/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states 'Sync application to target state' with a specific verb ('Sync') and resource ('application'), making the tool's purpose immediately understandable. However, it does not differentiate from sibling tools like 'refresh-application' or 'terminate-application-operation', which could also modify application state.

    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 alternatives such as 'refresh-application' or 'get-application-diff'. There is no mention of prerequisites, exclusions, or scenarios where this tool is inappropriate (e.g., read-only mode is hinted but not as a recommendation).

    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?

    With no annotations, the description carries full burden for behavioral disclosure. It only states the operation performed, without mentioning safety (read-only, idempotent), authentication requirements, or side effects. The agent cannot infer that this is a safe read operation.

    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?

    Single sentence, no filler words, directly conveys the tool's function. Every word earns its place.

    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?

    Despite only 3 parameters and no output schema, the description is insufficient. It does not clarify the format or structure of the returned 'full parameter documentation', nor does it hint at how the tool relates to sibling tools like 'search-argocd-endpoints'. The description leaves the agent needing to infer too much.

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

    Parameters3/5

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

    Schema coverage is 100%, providing baseline descriptions for each parameter. The tool description adds no additional meaning beyond 'from swagger', which is redundant given the context. Baseline score of 3 is appropriate.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states the tool's purpose: 'Get full parameter documentation for an Argo CD API endpoint from swagger.' It uses a specific verb ('Get') and resource ('parameter documentation for an endpoint'), distinguishing it from sibling tools like 'search-argocd-endpoints' which likely search or list endpoints.

    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 alternatives like 'search-argocd-endpoints' or 'call-argocd-api'. The description does not specify prerequisites, such as having the endpoint path/method or operationId known, nor does it suggest when not to use it.

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

  • Behavior2/5

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

    No annotations provided, so the description must disclose behavioral traits. It only states it fetches resource tree data, but does not mention idempotency, permissions, rate limits, or any potential side effects.

    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?

    Single sentence with no wasted words. Front-loaded with the core action and examples.

    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?

    Minimally adequate: lists resource types but no output schema exists, and the description does not clarify the tree structure or health representation. Given tool complexity, more detail would be helpful.

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

    Parameters3/5

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

    Schema covers both parameters fully (name and profile with descriptions). The tool description adds no extra meaning beyond schema, so baseline score of 3 is appropriate.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states 'Get the resource tree for an application' and provides specific examples (pods, services, deployments, health per node), which distinguishes it from sibling tools like get-application or get-application-manifests.

    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. With many sibling tools for applications, the description should explicitly mention cases where this tool is preferable.

    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 provided, so the description carries full burden. It mentions revision but omits behavioral traits such as cache bypass (noCache), permission requirements, or output format. The description does not disclose that rendering may be resource-intensive or that parameters like profile/project affect the output.

    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, consisting of a single sentence that front-loads the verb and resource. Every word earns its place, with no fluff or redundancy.

    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 (5 parameters, no output schema), the description is insufficient. It does not explain what 'rendered manifests' entails, how the output is structured, or why one would use this over similar tools like 'get-application-diff'. Missing context for a new user.

    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 each parameter is documented. The description adds the context that revision is optional, which is already indicated in the schema. No additional meaning is provided for other parameters like noCache, profile, or project, so the description adds minimal value beyond the schema.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states the verb 'get' and the resource 'rendered manifests', and explicitly mentions the optional revision parameter, distinguishing it from siblings like 'get-application' or 'get-application-diff' which serve different purposes.

    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 rendered manifests, but lacks explicit guidance on when to use this tool versus alternatives like 'get-application' or 'get-application-diff'. No when-not or alternative naming is provided.

    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?

    With no annotations, the description carries the full burden. It implies a mutation ('reconcile from Git') and mentions cache invalidation with mode=hard. However, it omits key behavioral traits: whether it's destructive, idempotent, requires specific permissions, or what side effects occur.

    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 the action and resource. Every sentence provides information (action, mode usage, condition). No wasted words.

    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?

    No output schema exists, but the description does not explain what the tool returns or any error conditions. It fails to describe the 'normal' mode or the 'profile' parameter's role. Given the mutation nature and 3 parameters, more detail is needed for safe and effective use.

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

    Parameters4/5

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

    Schema coverage is 100% with descriptions for all three parameters. The description adds value by explaining the purpose of mode=hard ('invalidate cache') and the environment variable guard, which are not in the schema. This supplements the parameter understanding beyond the schema alone.

    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 action: 'Refresh an application (reconcile from Git)'. It differentiates from sibling 'refresh-application-cache' by mentioning mode=hard for cache invalidation. The verb 'refresh' with resource 'application' is specific and unambiguous.

    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 only mentions the environment variable condition but provides no guidance on when to use this tool over siblings like sync-application or get-application-diff. It does not state when not to use it or alternatives.

    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?

    Since no annotations are provided, the description carries the full burden. It lists what data is fetched (status, resource tree, events, logs from unhealthy pods) but does not disclose if the operation is read-only, potential side effects, error behavior, or performance implications.

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

    Conciseness4/5

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

    The description is a single concise sentence that front-loads the key composite nature. It is efficient but could be slightly better structured with bullet points for clarity.

    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 tool's complexity (composite of multiple diagnostics), no output schema, and no annotations, the description is too brief. It does not explain what 'application status' covers, what 'resource tree' includes, or the format of events and logs. Important context is missing.

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

    Parameters3/5

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

    Schema coverage is 100%, so baseline is 3. The description adds no additional context beyond what the schema already provides for parameters like name, profile, tailLines, and maxPodLogs. No parameter meaning is enhanced.

    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 precisely states it's a composite troubleshooting tool combining application status, resource tree, events, and logs from unhealthy pods. This clearly distinguishes it from sibling tools like get-application or get-application-pod-logs, which are single-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 implies use for comprehensive troubleshooting but does not explicitly state when to use it versus individual diagnostic tools (e.g., get-application-pod-logs). There's no guidance on prerequisites or when not to use it.

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

  • Behavior3/5

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

    No annotations provided, so the description carries the full burden. It discloses the output (username, Azure groups, issuer) but does not mention prerequisites (e.g., being logged in), error conditions, or whether it is a read-only operation. Adequate but not comprehensive.

    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, well-structured sentence that front-loads the verb and resource, with no extraneous words. Efficient.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness3/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    For a simple, optional-parameter getter with no output schema and no annotations, the description covers the basic purpose and output. However, it lacks details on authentication requirements or potential error states, which could be useful for an AI agent.

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

    Parameters3/5

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

    Schema coverage is 100% for the single 'profile' parameter, which is documented in the schema. The description does not add new parameter details beyond 'environment profile', so baseline 3 is appropriate.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states the operation (Get) and resource (authenticated user for an environment profile) and lists the returned fields (username, Azure groups, issuer). This distinguishes it from sibling tools like 'argocd_auth_status' which might have different scope.

    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 explicit guidance on when to use this tool versus alternatives like 'argocd_auth_status'. The description implies it is for a specific profile but does not provide context or exclusion criteria.

    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 provided, so the description carries full burden. It mentions the termination action and a blocking condition, but does not disclose side effects, safety implications, or what happens to the operation after termination.

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

    Conciseness4/5

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

    Single sentence with no wasted words, front-loaded with the primary action. Slightly too concise but effective.

    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?

    Missing info on return values, error states, or post-termination behavior. No output schema, so description should cover more. The blocking condition helps but is insufficient.

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

    Parameters3/5

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

    Schema coverage is 100% with descriptions for both parameters. The description adds no extra meaning beyond the schema; the 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?

    Description clearly states the tool terminates a running sync/operation, with a specific verb and resource. It distinguishes from siblings like sync-application by being the inverse operation.

    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?

    Description includes a condition for when the tool is blocked (ARGOCD_READ_ONLY=true), which guides usage. However, it does not explicitly state when to use versus alternatives, but the context of sibling tools makes it clear.

    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 burden. It implies read-only operation but doesn't explicitly state safety. Parameter description adds detail on validateTokens behavior.

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

    Conciseness5/5

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

    One clear, concise sentence with no filler; efficiently states purpose and outputs.

    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?

    Description covers purpose and return content (URLs and auth status) adequately for a simple tool with one optional param and no output schema; slight lack of output format detail.

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

    Parameters3/5

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

    Schema coverage is 100% with clear param description. Description adds no extra meaning beyond schema, meeting baseline for high coverage.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    Description clearly states the tool lists configured Argo CD environment profiles with URLs and auth status, distinct from siblings like list-applications or list-projects.

    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 or alternatives; lacks context on when to prefer this over sibling tools like argocd_auth_status or search-argocd-endpoints.

    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 the full burden. It states the tool lists projects, which implies read-only behavior, but does not explicitly confirm safety or disclose any additional behavioral traits (e.g., pagination, rate limits). The description is adequate but not enriched beyond the obvious.

    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 14 words, front-loading the action and key result fields. Every word earns its place with no 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?

    For a simple list tool with no output schema and no annotations, the description sufficiently conveys the purpose and returned fields. It could mention pagination or default behavior (e.g., lists all projects if no filter), but overall it is complete enough for an AI agent to understand the tool's basic functionality.

    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 provides 100% coverage for the three parameters (name, profile, namesOnly). The description does not add any meaning beyond what the schema already documents, so the baseline score of 3 applies.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description uses the specific verb 'List' and clearly identifies the resource as 'Argo CD AppProjects'. It also specifies the returned fields (description, allowed source repos, destinations), which distinguishes it from sibling tools like 'list-applications' that list a different resource.

    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 alternatives such as 'list-applications' or 'list-argocd-profiles'. The description does not mention any preconditions or exclusions.

    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 provided, so description must cover behavioral traits. It indicates a mutating operation ('force refresh') but omits details like idempotency, permission requirements, or side effects on other users. This gap reduces transparency.

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

    Conciseness4/5

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

    Two sentences, no fluff. Could be slightly more precise (e.g., clarifying 'force' implications), but overall efficient.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness3/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    No output schema, so description should hint at return value or side effects. It does not mention what the agent can expect after invocation (e.g., confirmation message, cache state). Incomplete for a moderate-complexity tool.

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

    Parameters3/5

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

    Schema description coverage is 100% (one parameter 'profile' documented). The description does not add extra meaning beyond the schema; it merely restates 'for a profile'. Baseline score of 3 is appropriate.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states the tool's action ('force refresh the in-memory application name cache') and its use case ('useful after creating/deleting applications'). It distinguishes from sibling tools like 'refresh-application' and 'application-cache-status'.

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

    Usage Guidelines4/5

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

    Provides explicit when-to-use guidance ('useful after creating/deleting applications'), though it does not mention when not to use or alternatives. Still, valuable context for decision-making.

    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 must carry the full burden. It indicates a dry-run, safe operation (non-destructive), but does not mention authorization requirements, rate limits, or behavior on errors. Minimal but adequate for a read-only tool.

    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 immediately conveys the tool's purpose. No unnecessary words or details, and it is front-loaded with the most important 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?

    While the description captures the core function, it lacks details about the output format (e.g., is it a JSON diff, human-readable text?) and does not mention any error handling or special cases. Given no output schema, more detail on return value would be beneficial.

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

    Parameters3/5

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

    Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema's field descriptions. It does not explain parameter types, constraints, or usage hints.

    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 performs a server-side dry-run diff for an application, showing what would change on sync. It effectively distinguishes from sibling tools like 'get-application' (which retrieves details) and 'sync-application' (which actually applies changes).

    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 previewing changes before syncing, but does not explicitly state when to use this tool versus alternatives like 'sync-application' or 'get-application'. 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.

  • Behavior3/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 in-memory session scope and env var precedence, which is useful. But it does not detail behavior like overwriting existing keys, error conditions, or if the tool requires prior 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?

    Two sentences, no wasted words. Front-loaded with main action, then usage notes. Efficient and structured.

    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 setter with 2 parameters, no output schema, and no annotations, the description is mostly complete. It covers purpose, source of token, and persistence behavior. Minor gap: no mention of what happens on invalid key or how to verify it's set.

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

    Parameters3/5

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

    Schema description coverage is 100% with descriptions for both parameters. The description adds little beyond the schema (e.g., apiKey is a Bearer token, profile is environment). Baseline 3 is appropriate as the schema already does the heavy lifting.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose4/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states the verb 'set' and resource 'Argo CD API key (Bearer token) in memory for the current MCP session'. It adds context about token sources, making the purpose specific. It does not explicitly distinguish from siblings like argocd_login, but the purpose is unambiguous.

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

    Usage Guidelines4/5

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

    The description gives explicit when-to-use scenarios (token from UI or generate-token) and notes that env vars take precedence on restart. However, it does not mention when not to use or alternative authentication methods among siblings, missing some guidance.

    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 must convey safety. It implies a read-only operation ('Get detailed status'), but lacks detail on auth requirements, rate limits, or any potential side effects. Basic transparency is present.

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

    Conciseness4/5

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

    The description is a single sentence of 14 words, front-loading the core purpose. It is efficient but could benefit from bullet points for clarity on returned fields.

    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 no output schema, the description hints at return fields (sync, health, conditions, source), which is helpful. However, with many sibling tools, it does not fully contextualize when to use this specific tool over others.

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

    Parameters3/5

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

    Schema coverage is 100% and the description does not add meaning beyond the schema for the two parameters. The baseline of 3 is appropriate as the schema already documents the parameters sufficiently.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description uses specific verb 'Get' and resource 'detailed status of a single Argo CD application', listing key data fields (sync, health, conditions, source). This clearly distinguishes it from sibling tools like list-applications or diagnose-application.

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

    Usage Guidelines4/5

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

    The purpose implies usage for querying a single app's status, but there is no explicit guidance on when to use this vs alternatives, or when not to use it. The distinction from siblings is clear from context.

    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 provided, the description carries the full burden. It discloses the buffered/non-streaming behavior, but omits details on authentication, rate limits, or what happens when no logs are found. The disclosure is minimal.

    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 sentences, first states purpose and key behavior, second provides usage hint. Every word adds value; no wasted text.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness4/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    For a log retrieval tool with no output schema, the description covers purpose, behavior, and parameter grouping. It could mention the return format (lines of text) but the tool name and common conventions make it reasonably complete.

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

    Parameters3/5

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

    All 8 parameters have schema descriptions (100% coverage). The description adds a grouping hint ('Specify podName or use filters') but does not elaborate on parameter interactions or constraints beyond the schema.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states the action (get pod logs), the resource (for an application), and key behavioral detail (buffered tail, no streaming). This distinguishes it from sibling tools like get-application or refresh-application.

    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 hints at usage with 'Specify podName or use filters' but does not explicitly state when to prefer this tool versus alternatives, nor provide scenarios or exclusions.

    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 exist, and the description does not disclose behavioral traits like read-only nature, authorization needs, or rate limits. For a search tool, minimal extra context is provided beyond purpose.

    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 sentences with no wasted words. Front-loaded with the action and usage instruction.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness4/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the tool's simplicity (two optional parameters, no output schema), the description is fairly complete. It could mention the return format or limitations, but the core purpose and usage are clear.

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

    Parameters3/5

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

    Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning to parameters 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?

    Description clearly states the tool searches Argo CD REST API endpoints from a swagger catalog, with a specific verb and resource. It distinguishes from siblings by directing use before call-argocd-api.

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

    Usage Guidelines4/5

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

    Explicitly states when to use: 'Use before call-argocd-api.' Provides clear context, though no exclusions or alternatives are named.

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

  • Behavior4/5

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

    Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds behavioral insight by specifying that on hosts without MCP App it returns JSON and text summary. This goes beyond the annotations, though it doesn't detail permissions or limits.

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

    Conciseness5/5

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

    The description is a single, efficient sentence that front-loads the main purpose. No unnecessary words or repetition. Every part earns its place.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness4/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    For an observability viewer with no output schema, the description explains the return format (interactive panel or JSON plus text summary). It could be more detailed about the exact structure or edge cases, but it is largely sufficient given the tool's simplicity and the annotations covering safety.

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

    Parameters3/5

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

    Schema coverage is 100% with descriptions for both parameters (name and profile). The description does not add additional meaning to the parameters beyond what the schema provides. Baseline score of 3 is appropriate.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states it opens an interactive panel with specific Argo CD observability data (health, sync, Git, conditions, unhealthy resources) and explains fallback behavior on hosts without MCP App. This distinguishes it from sibling tools like get-application or diagnose-application.

    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 (e.g., get-application, diagnose-application). No prerequisites or exclusions mentioned. The description lacks context for selecting this tool over siblings.

    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; description indicates a read-only operation with no side effects, but lacks details on authentication requirements or response structure.

    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?

    Single sentence, no redundancy, front-loaded with key 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?

    Simple tool with no output schema; description covers return fields sufficiently, though could specify scope of 'per profile'.

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

    Parameters4/5

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

    No parameters; baseline score of 4 is appropriate per guidelines.

    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 verb 'Show' and resource 'application cache status per profile' with specific attributes (enabled, TTL, count, expiry). Distinguishes from sibling 'refresh-application-cache' which modifies cache.

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

    Usage Guidelines3/5

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

    Implies use for reading cache status, but no explicit guidance on when to use vs. alternatives like 'refresh-application-cache' or when not to use.

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

  • Behavior4/5

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

    With no annotations, the description discloses key behaviors: optional filters, priority app ordering with isPriority flag, caching (useCache, refreshCache), and client-side filtering for sync/health status. This is comprehensive, though it omits details like rate limits or cache TTL.

    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: first states purpose, second adds critical behavioral detail. No redundancy, front-loaded with key 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?

    Given 13 parameters and no output schema, the description is somewhat brief. It covers main behavior but lacks details on output format, error handling, or performance considerations, which are important for a list tool with many filters.

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

    Parameters4/5

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

    The schema covers all 13 parameters with descriptions. The tool description adds value by explaining the priority ordering and isPriority flag, which enhances understanding beyond the individual parameter descriptions.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states 'List Argo CD applications' with optional filters and specifies the priority ordering behavior, which distinguishes it from sibling tools like 'list-priority-applications' or 'search-applications'.

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

    Usage Guidelines3/5

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

    The description does not explicitly guide when to use this tool over alternatives. While it mentions priority apps appear first, it lacks direct comparisons or when-not-to-use guidance against siblings like 'search-applications' or 'list-priority-applications'.

    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?

    With no annotations, the description fully discloses that the tool probes the API, detects expired/revoked tokens, and returns recommendedAction. This is sufficient for a read-only status check, though it does not explicitly state that it does not modify state or require authentication itself.

    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 sentences with no filler, front-loaded with the core purpose. Every sentence is essential and adds value.

    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 zero-parameter, no-output-schema status tool, the description covers the action, detection mechanism, and return value (recommendedAction). It is complete enough for an agent to decide whether to invoke it, though it could mention potential latency or network dependence.

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

    Parameters4/5

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

    The input schema has zero parameters, so schema coverage is 100%. The description adds value by explaining the tool's behavior and output, meeting the baseline expectation for a no-parameter tool.

    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 specifies the verb 'Show' and resource 'authentication status for all configured Argo CD profiles'. It differentiates from sibling tools like 'argocd_login' (logging in) and 'argocd_set_api_key' (setting keys) by focusing on status checking and token expiry detection.

    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 use for checking auth status and detecting expired tokens, but does not explicitly state when to use this tool versus alternatives (e.g., argocd_login for authentication, argocd_set_api_key for key management). No when-not 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.

  • Behavior4/5

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

    With no annotations, the description carries full burden. It discloses that the tool is non-destructive ('public', 'does not require authentication') and specifies the return content (URL, OIDC config, UI banners). This is adequate but could mention rate limits or error handling.

    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 sentences, zero waste. Every word adds value: first sentence states purpose and outputs, second sentence clarifies auth requirement.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness4/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    For a simple read tool with two optional parameters and no output schema, the description covers the main behavior and safety. It could mention the output format, but is mostly complete.

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

    Parameters3/5

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

    Schema coverage is 100%, so the schema already documents both parameters. The description repeats schema descriptions without adding new meaning or examples, meeting baseline expectations.

    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 retrieves public Argo CD settings (URL, OIDC config, UI banners) for an environment profile, and explicitly notes no authentication is required. This distinguishes it from sibling tools that deal with user info, applications, or authentication.

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

    Usage Guidelines4/5

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

    The description implies usage for public settings without auth, but does not explicitly compare to alternatives like list-applications or describe-argocd-endpoint. It provides clear context but lacks explicit when-not 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?

    With no annotations, description carries full burden. It discloses read-only behavior ('List', 'Fetches live status'), and warns that UI favorites cannot be read. No mention of side effects, permissions, or rate limits, but for a read tool this is adequate.

    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 sentences, no redundant words. First sentence states action and data source; second adds useful constraint about UI favorites. Every sentence contributes meaning.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness5/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given simple schema (0 required params, no enums, no output schema) and two sibling list tools, description is complete: it covers what, source, live status, and limitation. Agent can use it correctly.

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

    Parameters3/5

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

    Schema coverage is 100% (both parameters described). Description adds minimal extra value: environment context for profile is implied, namesOnly is self-explanatory. Baseline 3 is appropriate.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    Description uses specific verb 'List' and clearly identifies resource as 'MCP priority/bookmark applications' specified by env var ARGOCD_PRIORITY_APPS. It distinguishes from sibling list-applications by focusing on bookmarked apps, and clarifies it cannot read UI favorites, enhancing specificity.

    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?

    Implies use when needing priority apps and their live status, and explicitly states UI favorites are not accessible via API. However, lacks explicit alternative names (e.g., 'for all apps, use list-applications') and doesn't say when not to use it.

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

  • Behavior4/5

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

    No annotations are provided, so the description carries full responsibility. It discloses key behaviors: default SSO login via the CLI that opens a browser immediately, and that it should be called directly when SSO expires. However, it does not detail other potential behaviors like network requirements or side effects, but the given context is sufficient for typical usage.

    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, consisting of only two sentences that front-load the purpose and immediately provide usage guidelines. Every sentence adds value without redundancy.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness4/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the complexity of 8 parameters and no output schema or annotations, the description provides necessary context: default behavior, situational usage, and alternatives. It does not explain return values, but for an authentication tool, success/failure can be reasonably inferred. Overall, it covers the key contextual needs.

    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 covers all 8 parameters with descriptions, achieving 100% coverage. The description adds minimal extra meaning beyond the schema, such as mentioning SSO as default. Baseline is 3 for high coverage, and the description does not significantly enhance parameter understanding.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states the tool's purpose: 'Authenticate to Argo CD for a profile.' It distinguishes itself from sibling tools like argocd_set_api_key by explicitly noting when to use SSO via the CLI and when to use API keys. It also mentions that when SSO expires, this tool should be called directly, differentiating it from alternative authentication methods.

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

    Usage Guidelines5/5

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

    The description provides explicit usage guidance: 'When SSO expires, call this directly — do not try API keys first.' It also directs users to use argocd_set_api_key or environment variables for API token authentication, making the tool's role clear.

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

  • Behavior4/5

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

    Annotations already provide readOnlyHint. Description adds context (UI-invoked, widget reload) but does not describe specific behavior like permissions or data refresh mechanism. It does not contradict annotations.

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

    Conciseness5/5

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

    Two sentences, front-loads the action, no unnecessary information. Very concise and structured.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness4/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the tool's restricted usage (UI-only), the description is largely complete. It clearly states purpose and usage restriction. Missing details about return values are mitigated by the readOnlyHint and the fact the agent should not call it.

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

    Parameters3/5

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

    Schema coverage is 100%, so both parameters are fully documented in the schema. The description adds no additional meaning about parameters, so baseline score of 3 is appropriate.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    Description uses specific verb 'recarrega' (reloads) and resource 'dados de observabilidade' (observability data), and clarifies it's for the widget. This distinguishes it from siblings like 'refresh-application' and 'view-application-observability'.

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

    Usage Guidelines5/5

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

    Explicitly states 'Chamado pela UI, não pelo modelo' (called by UI, not by the model), providing clear guidance that the AI agent should not invoke this tool. This is a strong usage restriction.

    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 description carries full burden. It discloses that the tool uses an in-memory cache and performs substring matching (LIKE) across multiple fields. Does not mention potential staleness of cache or performance impact, but the key behavioral traits are covered.

    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. First sentence defines the tool's action and scope. Second sentence provides context on why this tool exists (API limitation). Every word serves a purpose, no redundancy.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness4/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given 8 parameters, no annotations, and no output schema, the description reasonably covers what the tool does and how it behaves. Could elaborate on cache behavior or result format, but it's adequate for selection and invocation.

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

    Parameters4/5

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

    Schema description coverage is 100%, so baseline is 3. Description adds value by explaining the underlying search behavior (substring, cache, matching across fields) that is not captured by parameter descriptions. Also clarifies that 'query' is a substring and case-insensitive.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    Description clearly states it searches Argo CD applications by substring across multiple fields (name, project, repo, path, namespace). Differentiates from sibling tools like list-applications and get-application by specifying it's for partial search, and mentions the Argo CD API limitation.

    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?

    Description explicitly states when to use this tool: for partial substring search where the Argo CD API only supports exact match. Implies that for exact match, other tools like get-application should be used. Could be more explicit about alternatives, but the context is clear.

    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

mcp-argocd MCP server

Copy to your README.md:

Score Badge

mcp-argocd MCP server

Copy to your README.md:

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/godrix/mcp-argocd'

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