Реализация сервера Model Context Protocol (MCP) для Argo CD , позволяющая помощникам AI взаимодействовать с вашими приложениями Argo CD посредством естественного языка. Этот сервер обеспечивает бесшовную интеграцию с Visual Studio Code и другими клиентами MCP через транспортные протоколы stdio и Server-Sent Events (SSE).
Этот проект поддерживается Akuity , создателями проекта Argo.
Akuity — это корпоративная компания для Argo и Kargo, которая предоставляет необходимую платформу для сквозного GitOps для Kubernetes. С помощью платформы Akuity предприятия могут развертывать с помощью управляемого Argo CD, беспрепятственно продвигать с помощью Kargo и получать видимость в реальном времени в своей инфраструктуре с помощью Akuity Monitoring. Akuity была основана создателями Argo Хонгом Ваном, Джесси Суеном и Александром Матюшенцевым с целью предоставить командам платформы и приложения лучшие инструменты для GitOps в масштабе предприятия.
Транспортные протоколы : поддерживаются транспортные режимы stdio и SSE для гибкой интеграции с различными клиентами.
Полная интеграция API Argo CD : обеспечивает полный доступ к ресурсам и операциям Argo CD.
Готовность к использованию помощника на основе искусственного интеллекта : предварительно настроенные инструменты для помощников на основе искусственного интеллекта для взаимодействия с Argo CD на естественном языке.
Related MCP server: OpsLevel MCP
Node.js (рекомендуется v18 или выше)
менеджер пакетов pnpm (для разработки)
Экземпляр Argo CD с доступом по API
Токен API Argo CD ( инструкции см. в документации )
Следуйте документации по Cursor для поддержки MCP и создайте файл .cursor/mcp.json в своем проекте:
{
"mcpServers": {
"argocd-mcp": {
"command": "npx",
"args": [
"argocd-mcp@latest",
"stdio"
],
"env": {
"ARGOCD_BASE_URL": "<argocd_url>",
"ARGOCD_API_TOKEN": "<argocd_token>"
}
}
}
}Начните разговор в режиме агента, чтобы использовать MCP.
Следуйте документации Использование серверов MCP в VS Code и создайте файл .vscode/mcp.json в своем проекте:
{
"servers": {
"argocd-mcp-stdio": {
"type": "stdio",
"command": "npx",
"args": [
"argocd-mcp@latest",
"stdio"
],
"env": {
"ARGOCD_BASE_URL": "<argocd_url>",
"ARGOCD_API_TOKEN": "<argocd_token>"
}
}
}
}Начните разговор с помощником на основе искусственного интеллекта в VS Code, который поддерживает MCP.
Следуя MCP в документации Claude Desktop , создайте файл конфигурации claude_desktop_config.json :
{
"mcpServers": {
"argocd-mcp": {
"command": "npx",
"args": [
"argocd-mcp@latest",
"stdio"
],
"env": {
"ARGOCD_BASE_URL": "<argocd_url>",
"ARGOCD_API_TOKEN": "<argocd_token>"
}
}
}
}Настройте Claude Desktop для использования этого файла конфигурации в настройках.
Сервер предоставляет следующие инструменты управления ArgoCD:
list_applications : Список и фильтрация всех приложений
get_application : Получить подробную информацию о конкретном приложении
create_application : Создать новое приложение
update_application : Обновить существующее приложение
delete_application : Удалить приложение
sync_application : Запуск операции синхронизации в приложении
get_application_resource_tree : Получить дерево ресурсов для определенного приложения
get_application_managed_resources : Получить управляемые ресурсы для определенного приложения
get_application_workload_logs : получение журналов для рабочих нагрузок приложений (модули, развертывания и т. д.)
get_resource_events : Получить события для ресурсов, управляемых приложением
get_resource_actions : Получить доступные действия для ресурсов
run_resource_action : Выполнить действие над ресурсом
Клонируйте репозиторий:
git clone https://github.com/akuity/argocd-mcp.git
cd argocd-mcpУстановите зависимости проекта:
pnpm installЗапустите сервер разработки с включенной горячей перезагрузкой:
# For HTTP mode with hot reloading
pnpm run dev
# For SSE mode with hot reloading
pnpm run dev-sseПосле запуска сервера вы можете использовать сервер MCP в Visual Studio Code или другом клиенте MCP.
Чтобы обновить определения типов TypeScript на основе последней спецификации API Argo CD:
Загрузите файл swagger.json со страницы релиза ArgoCD , например, вот ссылка на swagger.json для ArgoCD v2.14.11.
Поместите загруженный файл swagger.json в корневой каталог проекта argocd-mcp .
Сгенерируйте типы TypeScript из определения Swagger, выполнив следующую команду. Это создаст или перезапишет файл src/types/argocd.d.ts :
pnpm run generate-typesОбновите файл src/types/argocd-types.ts для экспорта требуемых типов из вновь созданного src/types/argocd.d.ts . Этот шаг часто требует ручного просмотра, чтобы убедиться, что отображаются только необходимые типы.
create_application creates a new ArgoCD application in the specified namespace. The application.metadata.namespace field determines where the Application resource will be created (e.g., "argocd", "argocd-apps", or any custom namespace).
| Name | Required | Description | Default |
|---|---|---|---|
| application | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions creation without details on side effects, permissions, or failure modes. Carries full burden but provides minimal 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb and resource, with no extraneous content. Efficient but could benefit from structured sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with complex nested input and no output schema, the description lacks return value info, success conditions, and error handling. Schema partially compensates but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the schema, noting that namespace determines where the Application resource is created. Schema already defines structure, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (new ArgoCD application), and specifies the namespace. It implicitly distinguishes from sibling tools by action type, but does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 update_application or sync_application. Missing prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_application deletes application. Specify applicationNamespace if the application is in a non-default namespace to avoid permission errors.
| Name | Required | Description | Default |
|---|---|---|---|
| applicationName | Yes | ||
| applicationNamespace | No | The namespace where the application is located. Required if application is not in the default namespace. | |
| cascade | No | Whether to cascade the deletion to child resources | |
| propagationPolicy | No | Deletion propagation policy (e.g., "Foreground", "Background", "Orphan") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It merely states the action and warns about namespace permissions, but omits critical details like irreversibility, effects on child resources, or required permissions for the deletion operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences: one states the core action, the other provides a practical tip. Both sentences earn their place without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description should cover more context. It does not address return values, error conditions, prerequisites, or the irreversible nature of deletion. The description is too sparse for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% (3 of 4 parameters described). The description adds minimal value beyond the schema: it reinforces the namespace parameter's purpose but does not clarify applicationName, cascade, or propagationPolicy. The added context is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool deletes an application, which is a specific verb-resource combination. It distinguishes from sibling tools like create_application or update_application. However, it does not elaborate on the scope or consequences of deletion, so it is not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only provides a tip about specifying namespace to avoid permission errors. It offers no guidance on when to use delete versus alternative tools (e.g., sync_application, update_application) or when deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application returns application by application name. Optionally specify the application namespace to get applications from non-default namespaces.
| Name | Required | Description | Default |
|---|---|---|---|
| applicationName | Yes | ||
| applicationNamespace | No | The namespace where the ArgoCD application resource will be created. This is the namespace of the Application resource itself, not the destination namespace for the application's resources. You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.). The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks details on behavior such as error handling, default namespace behavior, or that it is a read-only operation. Only the optional namespace is mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with 17 words, front-loading the purpose and key behavior. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with two parameters and no output schema, the description is adequate but could benefit from specifying default namespace, error responses, or return value structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, with only the namespace parameter having a description. The tool description adds that namespace is optional and for non-default namespaces but does not explain the applicationName parameter format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves an application by name, with an optional namespace parameter. It distinguishes from siblings like list_applications by specifying retrieval of a single application by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions using the namespace parameter for non-default namespaces but does not provide explicit when-to-use or when-not-to-use guidance compared to other tools like get_application_events or list_applications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_events returns events for application by application name
| Name | Required | Description | Default |
|---|---|---|---|
| applicationName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description provides no behavioral details beyond the basic purpose. It does not disclose pagination, ordering, time range, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded with the action. However, for better clarity, it could be structured with bullet points or more explicit details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low schema coverage, no output schema, and no annotations, the description is incomplete. It does not specify the return type (list of events) or any event structure, leaving the agent with insufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage. The description only repeats the parameter name context ('by application name'), adding no format, constraints, or usage details. It does not compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it returns events for an application by name, which is a specific verb-resource combination. It distinguishes from siblings like get_application (returns the app itself) and list_applications (lists apps). However, it lacks detail on what type of events are returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 get_resource_events. The description does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_managed_resources returns managed resources for application by application name with optional filtering. Use filters to avoid token limits with large applications. Examples: kind="ConfigMap" for config maps only, namespace="production" for specific namespace, or combine multiple filters.
| Name | Required | Description | Default |
|---|---|---|---|
| applicationName | Yes | ||
| kind | No | Filter by Kubernetes resource kind (e.g., "ConfigMap", "Secret", "Deployment") | |
| namespace | No | Filter by Kubernetes namespace | |
| name | No | Filter by resource name | |
| version | No | Filter by resource API version | |
| group | No | Filter by API group | |
| appNamespace | No | Filter by Argo CD application namespace | |
| project | No | Filter by Argo CD project |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of transparency. It warns about token limits for large applications, which is a behavioral insight, but does not clarify read-only nature, authentication requirements, or response structure. Partial but lacking depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words: first states purpose, second advises filtering, third gives examples. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a tool with high schema coverage and a clear return purpose. However, it lacks details about response format or pagination, which would be expected for a list of resources. No output schema is provided, so description should have filled that gap more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (88%), and the description adds value by explaining why filters matter (token limits) and giving concrete examples (kind, namespace). This enhances understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns managed resources for a given application with optional filtering, using specific verb and resource. It distinguishes from sibling tools like get_application and get_resources by focusing on managed resources and filtering capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using filters to avoid token limits with large applications, providing concrete examples. It does not mention when not to use this tool versus alternatives, but the guidance is clear and practical for the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_resource_tree returns resource tree for application by application name
| Name | Required | Description | Default |
|---|---|---|---|
| applicationName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, rate limits, or authentication requirements. The description only states the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, making it highly concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is adequate but incomplete. It lacks details about the structure or content of the returned resource tree.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no extra meaning to the parameter 'applicationName' beyond what the schema states (a required string). No format, case sensitivity, or examples are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a resource tree for an application by name. However, it does not differentiate from sibling tools like get_application_managed_resources or get_resources, which may have overlapping purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_managed_resources, get_resources). The description lacks context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_application_workload_logs returns logs for application workload (Deployment, StatefulSet, Pod, etc.) by application name and resource ref and optionally container name
| Name | Required | Description | Default |
|---|---|---|---|
| applicationName | Yes | ||
| applicationNamespace | Yes | The namespace where the ArgoCD application resource will be created. This is the namespace of the Application resource itself, not the destination namespace for the application's resources. You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.). The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer. | |
| resourceRef | Yes | ||
| container | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It does not mention potential limits, authorization needs, or whether the operation is read-only or destructive. The description only states what the tool does, not how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that captures the essence without extra words. It is front-loaded with the tool's purpose. However, it could be slightly more structured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should explain what type of logs are returned (e.g., format, pagination). It does not describe the return value, leaving ambiguity. The tool has complex parameters (nested object) and the description does not cover all details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 25% of schema parameters have descriptions. The description adds minimal meaning beyond parameter names (e.g., 'by application name and resource ref and optionally container name'). The nested resourceRef object lacks explanation of its fields despite a detailed schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves logs for application workloads, specifying the resource types and key parameters. It is specific about the verb and resource, but does not explicitly differentiate from sibling tools like get_application_events or get_resource_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives such as get_resource_events or get_application_events. There is no mention of prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_resource_actions returns actions for a resource that is managed by an application
| Name | Required | Description | Default |
|---|---|---|---|
| applicationName | Yes | ||
| applicationNamespace | Yes | The namespace where the ArgoCD application resource will be created. This is the namespace of the Application resource itself, not the destination namespace for the application's resources. You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.). The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer. | |
| resourceRef | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only mentions returning actions but does not confirm read-only nature, nor does it discuss permissions, side effects, or what happens if the resource is not found. The minimal information is insufficient for a safe agent invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste, achieving conciseness. However, it could be improved with additional context without becoming verbose, but overall it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters including a nested object, no output schema, and no annotations. The description does not explain the return format or behavior beyond 'returns actions'. Given the complexity, the description lacks completeness and should provide more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only applicationNamespace has a description). The tool description does not add any meaning beyond the schema for the other parameters (applicationName, resourceRef). Since the description fails to compensate for the low coverage, the score is low.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns actions for a resource managed by an application, using a specific verb and resource. However, it does not distinguish from sibling tools like run_resource_action or get_resource_events, so it loses a point for lack of differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 using it to list available actions before calling run_resource_action. This lack of context makes it harder for an AI agent to decide correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_resource_events returns events for a resource that is managed by an application
| Name | Required | Description | Default |
|---|---|---|---|
| applicationName | Yes | ||
| applicationNamespace | Yes | The namespace where the ArgoCD application resource will be created. This is the namespace of the Application resource itself, not the destination namespace for the application's resources. You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.). The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer. | |
| resourceUID | Yes | ||
| resourceNamespace | Yes | ||
| resourceName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states it 'returns events', implying read-only behavior but does not explicitly confirm this, nor does it disclose any authorization needs, side effects, or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence. While it is not formally structured, it conveys the core purpose efficiently without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five required parameters, no output schema, and no annotations, the description is insufficient. It does not explain what constitutes an event, the return format, or any preconditions, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (20%), with only 'applicationNamespace' having a meaningful description. The tool description adds no additional meaning beyond the schema for the other four parameters, failing to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns events for a resource managed by an application. However, it does not distinguish this from the sibling tool 'get_application_events', which might serve a similar purpose, potentially causing confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not specify when to use this tool versus alternatives like 'get_application_events', nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_resources return manifests for resources specified by resourceRefs. If resourceRefs is empty or not provided, fetches all resources managed by the application.
| Name | Required | Description | Default |
|---|---|---|---|
| applicationName | Yes | ||
| applicationNamespace | Yes | The namespace where the ArgoCD application resource will be created. This is the namespace of the Application resource itself, not the destination namespace for the application's resources. You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.). The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer. | |
| resourceRefs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose side effects, permissions, or read-only nature. It only states it returns manifests, which is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, clear, no wasted words. Front-loaded with action and result.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description indicates returns manifests. Covers main behavior but lacks details on error handling or output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 33%. Description adds meaning for resourceRefs (optional, fetches all if empty) but does not clarify applicationName or applicationNamespace beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns manifests for resources specified by resourceRefs or all resources when empty. It distinguishes from sibling tools like list_applications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (to get manifests) but does not explicitly compare to siblings. No guidance on when not to use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_applications returns list of applications
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Search applications by name. This is a partial match on the application name and does not support glob patterns (e.g. "*"). Optional. | |
| limit | No | Maximum number of applications to return. Use this to reduce token usage when there are many applications. Optional. | |
| offset | No | Number of applications to skip before returning results. Use with limit for pagination. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it returns a list, omitting details like ordering, default limits, or any 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it sacrifices informativeness; it is under-specified rather than efficiently compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of sibling tools for specific operations and the lack of an output schema, the description fails to clarify result ordering, pagination behavior, or default limits, leaving gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% parameter description coverage, so baseline is 3. The description adds no extra meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name, 'list_applications returns list of applications,' without specifying any filtering or scope, making it a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 sibling tools like get_application or search functions, and no context for typical use cases is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_resource_action runs an action on a resource
| Name | Required | Description | Default |
|---|---|---|---|
| applicationName | Yes | ||
| applicationNamespace | Yes | The namespace where the ArgoCD application resource will be created. This is the namespace of the Application resource itself, not the destination namespace for the application's resources. You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.). The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer. | |
| resourceRef | Yes | ||
| action | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It does not disclose whether the action is destructive, requires permissions, or has side effects. The lack of behavioral details leaves the agent in the dark about the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise but at the expense of clarity. It could be improved by adding a few more sentences about purpose and usage without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 required parameters, nested object, no output schema), the description is inadequate. It does not explain what actions are valid, what the tool returns, or how to construct the resourceRef. The agent would struggle to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only applicationNamespace has a description). The tool description adds no additional meaning to parameters; it merely repeats the tool name. The nested resourceRef object is not explained at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'runs an action on a resource' but is extremely vague. It does not specify what kind of resource, what actions are possible, or how it differs from sibling tools like sync_application or get_resource_actions. The purpose is unclear without further inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The description lacks context about prerequisites (e.g., need to use get_resource_actions first to see available actions) 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.
sync_application syncs application. Specify applicationNamespace if the application is in a non-default namespace to avoid permission errors.
| Name | Required | Description | Default |
|---|---|---|---|
| applicationName | Yes | ||
| applicationNamespace | No | The namespace where the application is located. Required if application is not in the default namespace. | |
| dryRun | No | Perform a dry run sync without applying changes | |
| prune | No | Remove resources that are no longer defined in the source | |
| revision | No | Sync to a specific revision instead of the latest | |
| syncOptions | No | Additional sync options (e.g., ["CreateNamespace=true", "PrunePropagationPolicy=foreground"]) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits (e.g., whether the operation is destructive, permission requirements, side effects). The description is far too brief to compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) with no wasted words, but it is too brief given the complexity of the tool (6 parameters, sync operation). It could be more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a moderate parameter count, the description is incomplete. It fails to explain what 'sync' entails, return behavior, errors, or any important context needed for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (83%), so the baseline is 3. The description adds some context for 'applicationNamespace' (permission errors), but adds no meaning beyond the schema for other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'syncs' and the resource 'application'. It communicates the core function, but does not differentiate from sibling tools like 'update_application' or 'create_application', which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guidance is about specifying 'applicationNamespace' for non-default namespaces to avoid errors. No guidance on when to use this tool versus alternatives, nor prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_application updates application
| Name | Required | Description | Default |
|---|---|---|---|
| applicationName | Yes | ||
| application | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits. For example, it does not specify if this is a full replace (PUT) or partial update (PATCH), whether it triggers a sync, or what happens to omitted fields. With zero annotation coverage, the description carries the full burden and fails entirely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only 3 words, but this is not concise—it is under-specified. It wastes the opportunity to provide any useful context. A good description should be front-loaded with purpose and key constraints, but this is virtually empty.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested input schema (with required metadata, spec, etc.) and no output schema, the description is completely inadequate. The agent needs to know what fields are mutable, the effect of the update, and any side effects. None is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about the two required parameters (applicationName, application). Despite some inline schema descriptions for nested fields, the context signals 0% schema description coverage, meaning the tool's own description must compensate, but it does not mention any parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: 'update_application updates application'. It merely restates the tool name and the implied action without specifying what exactly is updated (e.g., ArgoCD application resource, configuration, etc.). No verb+resource clarity beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 siblings like create_application or sync_application. Does not mention that it is for updating existing applications only, or what scenarios warrant an update vs. a sync.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0create_application2 fields changedInput schema / properties / application / properties / metadata / properties / namespace / descriptionPrevious value: -"The namespace of the application.\n Note that this may differ from the namespace of individual resources.\n Make sure to verify the application namespace in the Application resource — it is often argocd, but not always."New value: +"The namespace where the ArgoCD application resource will be created.\n This is the namespace of the Application resource itself, not the destination namespace for the application's resources.\n You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.).\n The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer."Input schema / properties / application / properties / metadata / properties / namespace / minLengthAdded value: +1delete_application3 fields changedInput schema / properties / applicationNamespaceAdded value: +{
+ "description": "The namespace where the application is located. Required if application is not in the default namespace.",
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / cascadeAdded value: +{
+ "description": "Whether to cascade the deletion to child resources",
+ "type": "boolean"
+}Input schema / properties / propagationPolicyAdded value: +{
+ "description": "Deletion propagation policy (e.g., \"Foreground\", \"Background\", \"Orphan\")",
+ "type": "string"
+}get_application1 field changedInput schema / properties / applicationNamespaceAdded value: +{
+ "description": "The namespace where the ArgoCD application resource will be created.\n This is the namespace of the Application resource itself, not the destination namespace for the application's resources.\n You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.).\n The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer.",
+ "minLength": 1,
+ "type": "string"
+}get_application_workload_logs4 fields changedInput schema / properties / applicationNamespace / descriptionPrevious value: -"The namespace of the application.\n Note that this may differ from the namespace of individual resources.\n Make sure to verify the application namespace in the Application resource — it is often argocd, but not always."New value: +"The namespace where the ArgoCD application resource will be created.\n This is the namespace of the Application resource itself, not the destination namespace for the application's resources.\n You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.).\n The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer."Input schema / properties / applicationNamespace / minLengthAdded value: +1Input schema / properties / containerAdded value: +{
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "applicationName",
- "applicationNamespace",
- "resourceRef"
-]New value: +[
+ "applicationName",
+ "applicationNamespace",
+ "resourceRef",
+ "container"
+]get_resource_actions2 fields changedInput schema / properties / applicationNamespace / descriptionPrevious value: -"The namespace of the application.\n Note that this may differ from the namespace of individual resources.\n Make sure to verify the application namespace in the Application resource — it is often argocd, but not always."New value: +"The namespace where the ArgoCD application resource will be created.\n This is the namespace of the Application resource itself, not the destination namespace for the application's resources.\n You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.).\n The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer."Input schema / properties / applicationNamespace / minLengthAdded value: +1get_resource_events2 fields changedInput schema / properties / applicationNamespace / descriptionPrevious value: -"The namespace of the application.\n Note that this may differ from the namespace of individual resources.\n Make sure to verify the application namespace in the Application resource — it is often argocd, but not always."New value: +"The namespace where the ArgoCD application resource will be created.\n This is the namespace of the Application resource itself, not the destination namespace for the application's resources.\n You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.).\n The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer."Input schema / properties / applicationNamespace / minLengthAdded value: +1get_resourceslist_applications2 fields changedInput schema / properties / limitAdded value: +{
+ "description": "Maximum number of applications to return. Use this to reduce token usage when there are many applications. Optional.",
+ "exclusiveMinimum": 0,
+ "type": "integer"
+}Input schema / properties / offsetAdded value: +{
+ "description": "Number of applications to skip before returning results. Use with limit for pagination. Optional.",
+ "minimum": 0,
+ "type": "integer"
+}run_resource_action2 fields changedInput schema / properties / applicationNamespace / descriptionPrevious value: -"The namespace of the application.\n Note that this may differ from the namespace of individual resources.\n Make sure to verify the application namespace in the Application resource — it is often argocd, but not always."New value: +"The namespace where the ArgoCD application resource will be created.\n This is the namespace of the Application resource itself, not the destination namespace for the application's resources.\n You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.).\n The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer."Input schema / properties / applicationNamespace / minLengthAdded value: +1sync_application5 fields changedInput schema / properties / applicationNamespaceAdded value: +{
+ "description": "The namespace where the application is located. Required if application is not in the default namespace.",
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / dryRunAdded value: +{
+ "description": "Perform a dry run sync without applying changes",
+ "type": "boolean"
+}Input schema / properties / pruneAdded value: +{
+ "description": "Remove resources that are no longer defined in the source",
+ "type": "boolean"
+}Input schema / properties / revisionAdded value: +{
+ "description": "Sync to a specific revision instead of the latest",
+ "type": "string"
+}Input schema / properties / syncOptionsAdded value: +{
+ "description": "Additional sync options (e.g., [\"CreateNamespace=true\", \"PrunePropagationPolicy=foreground\"])",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}update_application2 fields changedInput schema / properties / application / properties / metadata / properties / namespace / descriptionPrevious value: -"The namespace of the application.\n Note that this may differ from the namespace of individual resources.\n Make sure to verify the application namespace in the Application resource — it is often argocd, but not always."New value: +"The namespace where the ArgoCD application resource will be created.\n This is the namespace of the Application resource itself, not the destination namespace for the application's resources.\n You can specify any valid Kubernetes namespace (e.g., 'argocd', 'argocd-apps', 'my-namespace', etc.).\n The default ArgoCD namespace is typically 'argocd', but you can use any namespace you prefer."Input schema / properties / application / properties / metadata / properties / namespace / minLengthAdded value: +1create_applicationdelete_applicationget_applicationget_application_eventsget_application_managed_resourcesget_application_resource_treeget_application_workload_logsget_resource_actionsget_resource_eventslist_applicationsrun_resource_actionsync_applicationupdate_applicationScored across 14 tools
Each tool targets a distinct aspect of ArgoCD application management. While get_application_events and get_resource_events could be confused, descriptions clarify their scope. Overall, purposes are clearly separated.
All tools use consistent snake_case with verb_noun pattern (e.g., create_application, get_application_events). The naming is predictable and follows a clear convention.
14 tools is well-scoped for an ArgoCD MCP server, covering CRUD operations, synchronization, logs, events, and resource management without being excessive.
The tool set covers core application lifecycle (CRUD, sync, logs, events) and resource management. Minor gaps like rollback or version history are missing, but the surface is largely complete for common tasks.
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
