The test is simple: are the inputs and outputs of this step fixed? Then write a script. Running tests, publishing or generating a changelog are faster, easier to debug and clearer on failure as commands.
Reach for MCP when the model has to pick among sources at runtime, or decide the next step from a result. The value there is tool descriptions and structured returns, not the number of services it can reach.
If you do add MCP in CI, cut the server list to what this job needs, inject credentials from the CI secret store, and put a timeout on the whole thing. An allow-all tool config does not belong in a pipeline.
Mixing is the practical answer: scripts for deterministic steps, MCP only at the step that needs judgement, output to a robot branch for review. See our pages on coding agents in CI and MCP versus CLI tools.