DEV Community: Puneet Gavri

Running MCP Servers Locally with Docker MCP Ecosystem: Dynamic MCP + Kiro (DIY GUIDE)

Puneet Gavri — Sat, 07 Mar 2026 08:08:41 +0000

Running MCP Servers Locally with Docker MCP Ecosystem: Dynamic MCP + Kiro (DIY GUIDE)

Report this article

Published Mar 3, 2026

In the newsletter What MCP Is Not… And Why You Should Start MCPing! , we talked about Model Context Protocol (MCP) architecture, workflow and various use-cases.

In short MCP is an open-source standard that connects AI apps to external systems, enabling them to access data, tools, and workflows.

But the next question is: “Okay, MCP is cool, But how and where do I run these MCP servers?" . In this article we would be talking about one of the most convenient way to run the MCP servers locally.

We will explore how Docker MCP ecosystem makes MCP servers easy to discover, run, and manage locally.

The Pain: MCP Setup Struggle

MCP itself is elegant. The experience of running MCP servers locally? Not so much.

You dig through GitHub, install different runtimes, fix dependency errors, tweak config files, restart things…One server needs Node. Another needs Python. Something else needs a specific setup. And there goes your “quick experiment.”

And Then Docker's MCP Ecosystem Shows Up

Docker MCP ecosystem is made up of three pieces, each handling a different part of the MCP setup headache

MCP Catalog Think of it as a trusted app store for MCP servers. Instead of digging through random GitHub repos, you get verified, versioned Docker containers with proper metadata and security updates and ready to run.

MCP Toolkit Built into Docker Desktop, the Toolkit gives you a simple UI to browse, install, and manage MCP servers. No cloning repos. No manual config edits. Just click, install, and manage.

MCP Gateway The Gateway runs the MCP containers and exposes a single endpoint for all your AI clients. Install a server once, and it’s available everywhere - Claude Desktop, Cursor, VS Code, LM Studio, and more.

Put together, Discovery, setup, and connectivity all live in one place , so you spend less time configuring and more time actually using MCP.

What is cool about this?

No setup chaos: MCP servers come as containers. You pick one, click install, and it runs and that too "same" on every machine.
Security and Isolation : Most importantly each server runs in its own container, so tools don’t get free access to your machine or your secrets.
Trusted starting point: The catalog is curated and signed, so you’re not pulling random code from the internet and hoping for the best.

Great!!! you can add mcp servers with a click. But what happens when you scale??

When you add an MCP server, it doesn’t come with just one tool , it comes with all of its tools for example github official MCP server has 40 tools, terraform has 9 tools. Every tool definition gets loaded into the model at startup and Your context window starts filling up before real work even begins.
Most AI models (like Claude or GPT-4) have a fixed limit on how many tools they can "see" at once (often around 128)
Adding new servers may require config updates and restarts

Dynamic MCP solves this problem and makes the MCP simplicity work at scale!

What is Dynamic MCP?

Dynamic MCP changes the model from “load everything upfront” to load only what you need, when you need it. Instead of preloading all tools:

The agent searches the MCP Catalog during the conversation and loads only the specific server required for the task
It can add and configure tools live without the need to restart
It asks for authentication only when a tool is triggered
Compared to pre-loading all the tools, token usage is quite low.

When a client connects to the MCP Gateway, it automatically gets access to a small set of built-in management tools. These tools allow the agent to:

mcp-find - Search for servers in the catalog
mcp-add - Add a server to the current session
mcp-config-set - Update a server’s settings
mcp-remove - Remove a server
mcp-exec - Run any available tool in the session
code-mode - Combine multiple MCP tools into a custom JavaScript-powered tool

This capability is enabled automatically when you connect an MCP client to the toolkit. Dynamically added servers only last for the current session. When you start a new session, only the servers saved in your profile will be available.

STEP-BY-STEP Setting up Kiro with Docker MCP Toolkit

Prerequisites:

Docker Desktop 4.42+ (Windows) or 4.40+ (macOS) installed. If not already use this link to install it Docker Desktop Installation
Kiro IDE latest version. To install go to https://kiro.dev/download and download Kiro. Once Downloaded, authenticate using one of the method as per the documentation https://kiro.dev/docs/getting-started/authentication/

Steps:

Step 1: Enable Docker MCP Toolkit on Docker Desktop

Open Docker Desktop and enable the MCP Toolkit from the Settings menu.

you should see MCP Toolkit in the left panel. You can see Catalog of curated MCP servers to choose from(as on date 311 and it keeps growing). My Servers tab shows the installed servers. Clients tab shows the list of clients that you can use to connect with the MCP servers. OAuth tab for authentication to MCP servers with existing credentials.

STEP 2: Connect Kiro as client

On your docker desktop MCP toolkit go to Clients tab and click on connect button left to Kiro . Here you can see various other clients available as well like cursor, Codex, Gemini cli , etc.

STEP 3: Restart Kiro and enable mcp agent

Go to Kiro settings

in the search search for "mcp" and Kiro Agent: Configure MCP parameter set it to enable (in case if if it is disabled).

STEP 4: Verify

click on the Kiro icon as below, you would see MCP_DOCKER exposing the tools that we discussed above.

or you can also open the Command Palette (Press Ctrl+Shift+P (Windows/Linux) or Cmd+Shift+P (macOS)) and find "Kiro: Open MCP Config" too view the mcp.json where the mcp servers are configured.

in mcp.josn you should see "MCP_DOCKER":{"command":"docker","args":["mcp","gateway","run"]}

what this does is: When Kiro needs to access MCP tools, it executes "docker mcp gateway run", which starts the Docker MCP Gateway which connects Kiro to appropriate mcp server running inside isolated containers. In short, it’s the link that lets Kiro safely use containerised tools via Docker.

If you open the terminal and check the OUTPUT logs:

You would see internal tools (like mcp-find, mcp-add, mcp-remove, mcp-exec etc) getting enabled, which means that the gateway is ready to manage and run MCP servers on the fly.

That's all!! Now you are good to start

STEP 5: Vibe!!

To test the setup, let me give a prompt on Kiro chat to create terraform code for any aws resource and the github action workflow:

PROMPT: "Use the terraform mcp, aws documentation mcp and github mcp to generate production-ready, modular Terraform code for a secure multi-AZ AWS ECS Fargate cluster following AWS Well-Architected security best practices, and also create a GitHub Actions workflow that performs IaC security scanning, Terraform validation, and plan checks before deployment. "

you would see Kiro isn’t just answering. It’s dynamically discovering tools, attaching them to the session, and then using them to fetch accurate AWS documentation before generating your Terraform code.

And (Optionally) if you really want to notice that these mcp servers are running in a container in your local machine....you can!

If you ask Kiro what tools it has or just type /tools , you’ll notice it’s not a massive list. Only the tools needed for that specific task are active. If you check Currently Active MCP Tools (via Docker), you’ll see just those dynamically added servers sitting there. Nothing extra.

It keeps things clean. Only what’s needed, nothing more.

Setting up other Clients with Docker MCP toolkit

The way we have set up Kiro to run MCP servers locally using Docker MCP toolkit, similar process can be followed for various other clients like Claude Code, Claude Desktop, Gemini CLI, Cursor etc.

Conclusion

Running MCP locally doesn’t have to be messy. In this article, we saw how the Docker MCP ecosystem simplifies setup, how Dynamic MCP keeps things scalable, and how easy it is to wire everything up with Kiro. Now it’s just about installing what you need, connecting your client, and building cool stuff.

Running MCP Servers Locally with Docker MCP Ecosystem: Dynamic MCP + Kiro (DIY GUIDE)

Puneet Gavri — Sat, 07 Mar 2026 07:12:15 +0000

In the newsletter What MCP Is Not… And Why You Should Start MCPing! , we talked about Model Context Protocol (MCP) architecture, workflow and various use-cases. In short MCP is an open-source standard that connects AI apps to external systems, enabling them to access data, tools, and workflows.

TERRAFORM ACTIONS : The HashiConf '25 Drop We’ve All Been Waiting For!!!!

Puneet Gavri — Fri, 26 Sep 2025 20:48:05 +0000

At HashiConf this week, HashiCorp rolled out something many of us DevOps folks have been wishfully dreaming about: Terraform Actions.

If you've worked with Terraform for longer than five minutes, you know the philosophy: immutable infra only! Apply, destroy, and between those two, you're not really supposed to do anything.

But let's admit it, we've all done stuff. Executed a script on a VM, initiated a migration, or invoked something without modifying the .tf file. Most often, the "solution" was provisioners or some other workarounds, which, if we're being honest, always seemed like duct-taping your car bumper. HashiCorp docs even do not recommend them saying: "try not to use these."

So what's new?

Terraform Actions is now a first-class block within HCL that allows you to define what should occur between the creation and teardown of infrastructure.

It's as if HashiCorp is declaring:

"Fine, we know you're going to do this anyway. Here's a tidy, supported means of doing it."

Some actual applications:

Run DB migrations post-deployment of a new instance.
Rotate secrets without taking everything down.
Make config tweaks safely without violating immutability guarantees.
Invoke a Lambda, stop an AWS EC2 instance, invalidate an AWS CloudFront cache, etc.

Terraform v1.14.0-beta2 (pre-release) just dropped yesterday (Sept 25, 2025). As of today (the very next day), in the AWS provider I only see three Actions available so far aws_lambda_invoke, aws_cloudfront_create_invalidation, and aws_ec2_stop_instance.

To really see the difference between the old way and the new way, let’s take a simple example: say we need to invoke a Lambda function (yep, in AWS).

Before (old school way!):

If any existing Lambda is to be invoked, we could use a data block:

data "aws_lambda_invocation" "call_hellolambda" {
function_name = "hellolambda"
input = jsonencode({ })
}

output "lambda_response" {
value = data.aws_lambda_invocation.call_hellolambda.result
}

Sure, this works — but it runs the Lambda every single time you do terraform apply. Not exactly flexible.

If we wish to invoke the lambda just after creation, we can use a resource block:

resource "aws_lambda_function" "example" {
function_name = "hellolambda"
}

resource "aws_lambda_invocation" "invoke_after_creation" {
function_name = aws_lambda_function.example.function_name
depends_on = [aws_lambda_function.example]

input = jsonencode({
})
}

Here the Lambda gets invoked right after creation. Sounds good… until you realize it’s now stuck to the lifecycle. If nothing changes in the resource config, Terraform won’t re-invoke it.

We were using clunky, duct-taping provisioners:

provisioner "remote-exec" {
inline = ["aws lambda invoke --function-name hellolambda /tmp/lambda_output.txt"]
connection { ... }
}

This is the duct-tape-and-prayers method. It’ll run… until the day it doesn’t, and then you’re the lucky one ssh’ing into a box at 2 AM.

After Terraform Actions (the new way of On-Demand Invocations!!)

You can configure (the new) action blocks in your Terraform configuration that are not referenced anywhere else in your code like below:

action "aws_lambda_invoke" "test" {
config {
function_name = "hellolambda"
payload = jsonencode({})
}
}

This standalone action can be triggered using the Terraform CLI. To invoke them, you use the -invoke=<action address> flag with the terraform plan or terraform apply commands:

terraform apply -auto-approve -invoke=action.aws_lambda_invoke.test

You would see output like this:

The above example is just for ad-hoc action which you can trigger using the CLI. You can also bind actions to the lifecycle of a resource.

Why Terraform Actions Feel Like an Upgrade

The good thing about Terraform Actions is that they finally give us a clean, native way to run operations in Terraform without resorting to hacks. A few reasons this matters:

You can perform on-demand tasks like invoking a Lambda function, rotating a secret, stopping/starting an EC2, without tying it to the whole “create/destroy” lifecycle.
No more duct-taping SSH commands or local-exec scripts just to run a one-off task.
Actions are visible and auditable in your config, instead of tasks/operations hiding in random shell scripts.
They fit naturally into CI/CD pipelines hence safer, easier, and a lot less fragile than the workarounds most of us have been using.

From the release notes:

Actions are provider-defined and meant to codify use cases outside the normal CRUD model in your Terraform configuration. Providers can define Actions like aws_lambda_invoke or aws_cloudfront_create_invalidation that do something imperative outside of Terraform’s normal CRUD model. You can configure such a side-effect with an action block and have actions triggered through the lifecycle of a resource or through passing the -invoke CLI flag.

Conclusion

Terraform Actions are still in beta and starting with just a handful of examples, but honestly, it already feels like a fresh breeze after years of duct-taping solutions.

It surely will ease our pain of playing with various workarounds. This was my initial reaction article on this wonderful addition by HashiCorp.

Excited to explore other new features and enhancements in this latest version 1.14 and cannot wait to drop more such content in "The Devops Drop".

Subscribe to The Devops Drop on LinkedIn : https://www.linkedin.com/build-relation/newsletter-follow?entityUrn=7375749694414782466