{ "SchemaVersion": "1", "Kind": "DirectoryEntry", "SubjectType": "mcp-server", "Slug": "testkube-mcp", "Name": "testkube-mcp", "Title": "testkube-mcp MCP Server | Pod", "Description": "MCP server for Testkube - Manage test workflows, executions, and artifacts via AI assistants", "CanonicalUrl": "https://askpod.ai/mcp/testkube-mcp", "MarkdownUrl": "https://askpod.ai/mcp/testkube-mcp.md", "JsonUrl": "https://askpod.ai/mcp/testkube-mcp.json", "DatePublished": "2026-08-31T23:50:54.202Z", "DateModified": "2026-08-31T23:50:54.202Z", "RegistryName": "io.github.kubeshop/testkube-mcp", "RepositoryUrl": "https://github.com/kubeshop/testkube", "VerificationStatus": "unverified", "Identities": [], "Sources": [ { "Source": "github_issues", "LastSeenAt": "2026-08-31T23:50:54.202Z" }, { "Source": "official_mcp_registry", "ExternalId": "io.github.kubeshop/testkube-mcp", "LastSeenAt": "2026-08-31T23:50:54.202Z" } ], "Categories": [], "FirstParty": false, "Deployments": [ { "Kind": "package", "PackageRegistry": "oci", "PackageIdentifier": "docker.io/kubeshop/mcp-server:2.9.1", "ConfigSnippet": "{\n \"mcpServers\": {\n \"testkube-mcp\": {\n \"command\": \"npx\",\n \"args\": [\n \"-y\",\n \"docker.io/kubeshop/mcp-server:2.9.1\"\n ]\n }\n }\n}" } ], "Tools": { "Claimed": [], "ClaimedCount": 0, "Observed": null, "ObservedCount": null, "Verified": false, "Mismatch": null }, "Measured": null, "Usage": null, "Issues": [ { "Title": "Add Support for S3 Virtual-Hosted-Style URLs", "Excerpt": "**Problem Description**\nTestkube currently cannot work with S3-compatible storage services that only support virtual-hosted-style URLs (e.g., Tencent Cloud COS CDC). This limitation prevents users from using Testkube with certain cloud providers' object storage services.\n\n**Current Behavior**\nWhen configuring Testkube with external S3-compatible storage, the MinIO client always uses path-style URLs, even when AWS_S3_FORCE_PATH_STYLE=false is set.\n\nExample configuration:\n\n``` yaml\nglobal:\n stora", "SourceUrl": "https://github.com/kubeshop/testkube/issues/6890", "PublishedAt": "2025-12-01T10:52:05.000Z", "State": "closed", "Comments": 4, "Reporter": "External", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "Can you provide CRDs (outside Helm template) to be used with flux gitSource", "Excerpt": "**Describe the enhancement you'd like to see**\nWe need to deploy testKube with flux.\nBut to prevent dependency issued we use a dedicated ksutomization to deploy CRDs.\nBut you not push the CRDs outise Helm chart.\n\nCan you source control CRDs on this repository like others kubernetes operators?\n\n**Additional context**\nHere is an example https://github.com/prometheus-operator/prometheus-operator/tree/main/example/prometheus-operator-crd\nBy default KubeBuilder generate the example folder with the CR", "SourceUrl": "https://github.com/kubeshop/testkube/issues/6636", "PublishedAt": "2025-09-01T08:48:53.000Z", "State": "closed", "Comments": 2, "Reporter": "External", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "User should have the flexibility to provide the custom name to JMeter artifacts when uploaded to S3 bucket. As of now it gets uploaded by the name of testkube execution id which is not user friendly.", "Excerpt": "**Is your feature request related to a problem? Please describe.**\nSo when I uploaded the JMeter artifacts to S3 bucket, I found that the key name is the testkube execution id. So, in a day if 10 reports are generated, then on S3 it will show 10 execution IDs and for a user it will be really difficult to you know categorize that when the artifact was uploaded. It does not has and date time appended to it. It's just execution id. To fetch yesterday's report one has to go testkube to look out for ", "SourceUrl": "https://github.com/kubeshop/testkube/issues/6148", "PublishedAt": "2025-02-03T05:17:52.000Z", "State": "closed", "Comments": 9, "Reporter": "External", "Rank": "top", "Extractor": "github_issue" }, { "Title": "container executor - pre/post-run scripts - command isn't executed", "Excerpt": "**Describe the bug**\r\nContainer executor and pre/post-run scripts - command isn't executed, test is marked as passed just after pre-run.\r\n\r\nhttps://demo.testkube.dev/tests/container-executor-postman-smoke/executions/658436af3e18ce9cee6da375 without pre/post-run scripts\r\n\r\nhttps://demo.testkube.dev/tests/container-executor-postman-smoke/executions/6584381d3e18ce9cee6da381 with pre/post-run scripts\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Definitions:\r\n\r\nExecutor:\r\n```\r\napiVersion", "SourceUrl": "https://github.com/kubeshop/testkube/issues/4828", "PublishedAt": "2023-12-21T13:09:28.000Z", "State": "closed", "Comments": 2, "Reporter": "Contributor", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "Add ability to export and output the data in xml junit format", "Excerpt": "**Is your feature request related to a problem? Please describe.**\r\nNo\r\n\r\n**Describe the solution you'd like**\r\nAs a DevOps I would like to be able to export the output of executions in xml junit format. Currently able to out put json, pretty.\r\nIn order to be able to integrate the gitlab test report. we should have the ability to be able to generate a test report in xml jnuit format which makes it easier to integrate with gitlab test report feature. \r\n\r\nPlease see the doc below: \r\nhttps://docs.g", "SourceUrl": "https://github.com/kubeshop/testkube/issues/4285", "PublishedAt": "2023-08-21T19:04:52.000Z", "State": "closed", "Comments": 5, "Reporter": "External", "Rank": "top", "Extractor": "github_issue" }, { "Title": "Ability to pass SSL cert for Minio connection", "Excerpt": "When trying integrte Minio with external service endpoint, sometime SSL certificate will be needed for the connection.\r\nCurrently in testkube configuration there is no provision to pass the SSL Cetificate details.\r\nRequesting to enable the feature to pass SSL Certifcates, it will be good, if's read from a k8 secret.", "SourceUrl": "https://github.com/kubeshop/testkube/issues/3883", "PublishedAt": "2023-05-23T13:46:00.000Z", "State": "closed", "Comments": 1, "Reporter": "External", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "Enable api telemetry opt-out at installation time", "Excerpt": "**Describe the enhancement you'd like to see**\r\n\r\nAs a testkube administrator\r\nin order to disable telemetry on sensitive or internet offline/airgap environments\r\nI need a way to opt-out from telemetry at installation time (such as an environment variable that can be valued in the helm chart)\r\n\r\nCurrently, the api telemetry status is stored in a config map dynamically created at 1st api server start with telemetry enabled by default\r\n\r\nhttps://github.com/kubeshop/testkube/blob/18111f9dcf2edc8847", "SourceUrl": "https://github.com/kubeshop/testkube/issues/3622", "PublishedAt": "2023-04-05T13:36:41.000Z", "State": "closed", "Comments": 9, "Reporter": "Contributor", "Rank": "top", "Extractor": "github_issue" }, { "Title": "Locust executor", "Excerpt": "I need the ability to run distributed Locust with master and multiple workers that communicate with one another.\r\nI tried creating it using container executor but faced some issues with the custom job-template.\r\nFurthermore, I want it to be one test and with a custom container executor, I will have to create 2 tests - one for the master and one for the worker.\r\nCan you please consider adding it as an executor?", "SourceUrl": "https://github.com/kubeshop/testkube/issues/2866", "PublishedAt": "2022-12-07T10:41:05.000Z", "State": "closed", "Comments": 10, "Reporter": "External", "Rank": "top", "Extractor": "github_issue" }, { "Title": "Container Executor: Retain full JSON-log, so I can analyse failures", "Excerpt": "**Describe the bug**\r\nWhen I use a container executor, I face the problem that **the log out put** is generated but **lost when I refresh the browser** (from which I guess: the output is not persisted...).\r\n![Screenshot_2022-11-09_at_12 42 29](https://user-images.githubusercontent.com/3470837/201113242-a66d2221-e180-4964-8353-7a07f1c23440.png)\r\n\r\nThis might prevent proper error analysis!\r\n\r\nAccording to @vsukhin, this is _caused by the test process' output not being wrapped in JSON_.\r\n\r\nBut: Whe", "SourceUrl": "https://github.com/kubeshop/testkube/issues/2699", "PublishedAt": "2022-11-10T14:06:34.000Z", "State": "closed", "Comments": 7, "Reporter": "External", "Rank": "top", "Extractor": "github_issue" }, { "Title": "`portman` executor", "Excerpt": "**Is your feature request related to a problem? Please describe.**\r\n\r\nImplement executor for generating Postman tests \r\n\r\nhttps://github.com/apideck-libraries/portman\r\n\r\nconsider it being part of Postman executor?", "SourceUrl": "https://github.com/kubeshop/testkube/issues/2617", "PublishedAt": "2022-10-25T18:42:28.000Z", "State": "closed", "Comments": 1, "Reporter": "Contributor", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "Container based executors", "Excerpt": "- Allow users to define an executor by specifying \r\n - docker image name\r\n - credentials (in case of private registries)\r\n - name of the executor (and other misc data t.b.d)\r\n- Test can be defined to use this executor. The same behaviour is expected from a users's standpoint \r\n- There should be a clear folder structure documented that specifies\r\n - Which folder should the artifacts be saved too ?\r\n - Q: should the logs be saved in artifacts ?\r\n\r\n- Pass & fail is", "SourceUrl": "https://github.com/kubeshop/testkube/issues/2234", "PublishedAt": "2022-09-05T23:24:05.000Z", "State": "closed", "Comments": 1, "Reporter": "Contributor", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "Add --executor-args support in argocd plugin", "Excerpt": "**Is your feature request related to a problem? Please describe.**\r\nCurrently, `testkube generate tests-crds` doesn’t have any option to pass `--executor-args` option.\r\nAdd this support so that we can use this in argocd plugin.\r\n\r\n**Describe the solution you'd like**\r\n```\r\nsource:\r\n repoURL: https://github.com/kubeshop/testkube-argocd.git\r\n targetRevision: HEAD\r\n path: examples/postman-collections\r\n plugin:\r\n name: testkube\r\n extraArgs:\r\n - '--insecure'\r\n```", "SourceUrl": "https://github.com/kubeshop/testkube/issues/2223", "PublishedAt": "2022-09-02T18:10:05.000Z", "State": "closed", "Comments": 6, "Reporter": "Contributor", "Rank": "top", "Extractor": "github_issue" }, { "Title": "Executors - Add handling for possible binary parameters", "Excerpt": "**Describe the enhancement you'd like to see**\r\n\r\nAs a tester, I want to have possible binary parameters which I can pass through Testkube UI / CLI with visual help\r\nI don't want to check binary `--help` in Terminal to check that \r\n\r\n**Additional context**\r\n\r\nAdd some common mechanism and data structure for:\r\n- [ ] *parsing*, \r\n- [ ] *defining*\r\n- [ ] and *validating* parameters\r\n\r\nBasic implementation was done by Discord user https://github.com/jdborneman-terminus \r\n\r\nHere: https://github.com/", "SourceUrl": "https://github.com/kubeshop/testkube/issues/1811", "PublishedAt": "2022-07-14T07:25:43.000Z", "State": "closed", "Comments": 1, "Reporter": "Contributor", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "Artifacts generation for curl and postman type tests.", "Excerpt": "**Describe the enhancement you'd like to see**\r\nCan there be a possibility of generating yaml or json report for curl and postman tests as well.\r\n\r\n**Additional context**\r\nThe STDOUT of these tests execution results in -o json or yaml will be needed to save in file, needing changes in their respective executors.", "SourceUrl": "https://github.com/kubeshop/testkube/issues/1653", "PublishedAt": "2022-06-15T05:25:43.000Z", "State": "closed", "Comments": 5, "Reporter": "External", "Rank": "top", "Extractor": "github_issue" }, { "Title": "Cypress test not starting", "Excerpt": "**Describe the bug**\r\n\r\n\"image\"\r\n\r\n```\r\ncat examples/test-git-dir.json | go run cmd/agent/main.go\r\n{\"type\":\"event\",\"content\":\"running test [6183cec12acc0cb7de5c249e]\"}\r\n{\"type\":\"error\",\"content\":\"npm install error: process error: exec: not started\"}\r\nexit status 1\r\n```\r\n\r\n**Version / Cluster**\r\n- Demo cluster \r\n- local go build also looks wasted", "SourceUrl": "https://github.com/kubeshop/testkube/issues/1416", "PublishedAt": "2022-04-29T10:12:22.000Z", "State": "closed", "Comments": 3, "Reporter": "Contributor", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "EventEmitter - Webhooks could be pluggable", "Excerpt": "**Why should it be implemented?**\r\n\r\n\r\nbut I was thinking more about doing whole EventsEmitter pluggable\r\n\r\ne.g.\r\n```\r\n\t\ts.EventsEmitter.Notify(testkube.WebhookEvent{\r\n\t\t\tUri: wh.Spec.Uri,\r\n Kind: \"SLACK\" // it would be defined as Webhook kind == SLACK \r\n\t\t\tType_: eventType,\r\n\t\t\tExecution: &execution,\r\n\t\t})\r\n```\r\n\r\nDon't know yet what full implemetation could be provided but we could add several Kinds - like slack or other internal event types if needed.\r\n\r", "SourceUrl": "https://github.com/kubeshop/testkube/issues/1366", "PublishedAt": "2022-04-22T08:30:14.000Z", "State": "closed", "Comments": 1, "Reporter": "Contributor", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "Authentication for API and UI", "Excerpt": "### Goal\r\nAllow users that expose Testkube (e.g., to the Internet) to configure an Authentication layer in order to control who has access to it. \r\n\r\n### UI UX\r\nAs a user I would be able to use the OAuth provider that was configured when Testkube was installed and I would see something like this:\r\n\"image\"\r\n