gatling-mcp

Gatling MCP

The tool schemas define valid request shapes. Check each tool's own description directly rather than assuming from a sibling (e.g. read vs. write variants of the same resource aren't guaranteed to share a role floor, and a location's listing doesn't expose all of its capabilities).

Never call the Gatling Enterprise API directly (v1 or v2, via curl, a raw HTTP request, or any tool other than these MCP tools), even as a fallback when an MCP tool call fails. Always go through these MCP tools, and report failures to the user instead of working around them.

Tools

There is no packages.create_one / packages.delete_one: packages can only be produced by actually building and uploading an artifact, never through this MCP. If a build-tool skill/integration for packaging (e.g. one that drives the Enterprise Maven/Gradle/sbt/npm plugin's package goal) is available in the environment, prefer it over telling the user to do this by hand. This holds even if a hypothetical packages.create_one existed, since packaging is fundamentally a build step an API call can't substitute for.

Terminology

• Test: a saved, runnable definition of what to run (source), where (distribution.loadGenerators), and under what conditions to stop (execution.stopCriteria). Running it produces a run.
• Source, on a test, is one of:
  • build_from_sources: sourceRepositoryId + buildTool (maven, maven-wrapper, gradle, gradle-wrapper, sbt, npm, or custom with an explicit command/packageFormat) + simulation (fully-qualified class/id), optional branch/workingDirectory. Built fresh from git on every run. Prefer one of the named build tools over custom whenever the project actually uses one of them. custom means hand-specifying the build command and output format, which is more error-prone and should be a fallback, not a default.
  • packaged: packageId + simulation. Runs a pre-built artifact as-is.
• Source repository: a registered git remote (remote.url) a test can build from. Metadata only (name/URL): auth (deploy key, PAT) isn't settable via create_one's schema, so private repos likely still need credentials configured through Control Plane Builders.
• Package: a pre-built artifact (_format: jvm or js) uploaded outside the MCP.
• Location, in distribution.loadGenerators[].locationId: either a plain managed location name (a Gatling-hosted public region, e.g. "Europe - Paris") or a private location id (starts with prl_). Same field, two different ID spaces. A private location's artifactFormats must include the format of what you're running (a jvm-only location can't run a js package/build).
• Team: the ownership/permission boundary. Every package, source repository, and test belongs to a team; roles are granted per team.
• Roles: granted per team, not globally. Having Configure on one team says nothing about another. At least Read, Configure, and Start appear across these tools as distinct levels; don't assume one implies another.
• Credits: consumed by tests.start_one (an actual run), not by any create/patch/delete/read call. Those only touch definitions or return data.