MCP

MCP Model Context Protocol, an open standard that lets AI tools call external services and data sources through small add-on servers. is how Kiro reaches anything outside your codebase: documentation services, databases, ticket systems, search, your own internal APIs. If a service exposes an MCP server, its capabilities become tools the agent can call in the middle of a task.

What is MCP?

Model Context Protocol is an open standard, not a Kiro feature. Kiro provides the socket; anyone can build the plug. That matters because it means you are not waiting for Amazon to integrate your favorite tool. A server exists or you write one, and Kiro can use it either way.

Once a server is connected, its tools appear to the agent like the built-in ones. Ask a question that needs current library documentation and the agent can fetch it. Ask about a failing job and the agent can query your observability platform. The agent decides when a tool is relevant, subject to your permission rules.

Why it exists

An agent that can only read your repository is working with half the picture. Real tasks reach outward constantly: what does this API actually return, what does the ticket say, what is in the staging database, what did the deploy log show. Without MCP, all of that arrives by copy and paste, which means it arrives stale, partial, and only when you thought to include it.

MCP also keeps Kiro from becoming a pile of vendor integrations. One protocol, many servers, and the same configuration shape for all of them.

How it works

Configuration. Servers are declared in JSON. Workspace servers live in .kiro/settings/mcp.json, personal servers in ~/.kiro/settings/mcp.json, and Kiro’s configuration documentation gives the precedence as agent level, then project, then global. The closer scope wins.

{
  "mcpServers": {
    "aws-docs": {
      "command": "npx",
      "args": ["-y", "example-aws-docs-server"],
      "env": { "API_TOKEN": "${API_TOKEN}" },
      "autoApprove": [],
      "disabled": false
    }
  }
}

The keys worth knowing. Local servers use command, args, and env, where ${VAR} expands from the environment Kiro was launched in. Remote servers use url instead, plus optional headers and oauth. disabled turns a server off without deleting its entry, which is the clean way to isolate a suspect. disabledTools removes individual tools from an otherwise working server, which is useful when one noisy tool is the actual problem. autoApprove lists tools the agent may call without asking.

Authentication. Servers that need a login use OAuth. In the CLI, /mcp auth starts the flow, /mcp cancel-auth abandons a pending one, and /mcp logout drops saved credentials. The IDE has handled MCP OAuth automatically since v1.0.116, and IDE v1.0.395 (August 27, 2026) added support for the latest MCP protocol revision with more reliable sign-in.

Hot reload. Since CLI v2.10.0, agent and MCP configuration changes take effect on save. You do not restart the session and you do not lose history.

Debugging. Two places, in order. The MCP servers panel shows each server’s connection status. The Kiro - MCP Logs output channel says why a server failed to start. Editing JSON on a hunch before reading those is the single most common way to spend an hour on a five-minute problem.

Common mistakes

"autoApprove": "*" on a server you do not fully trust. Auto-approval means the agent calls those tools without asking you, which is fine for a read-only docs server and dangerous for anything that can write, spend, or delete. The fix: approve tool by tool, and keep the wildcard for servers whose entire surface is read-only.

Forgetting the precedence rule. The same server, configured once, behaving differently depending on which folder you opened, is almost always a workspace file overriding the user-level one. The fix: when a server works everywhere except one project, read that project’s .kiro/settings/mcp.json first.

An ${ENV_VAR} that resolves to nothing. The server starts, then authentication fails in a way that looks like a broken server. The fix: confirm the variable is set in the environment Kiro was actually launched from, which on a desktop app is not always your shell.

Running everything always-on. Every connected server contributes tool definitions to the agent’s context on every turn. A dozen of them is a real cost paid on every request. The fix: keep the always-on set small and reach for powers, which load on demand, for specialized technology.

Permissions and safety

MCP calls are governed by the mcp capability in Kiro’s permission model, and the effect ranking applies as everywhere else: deny beats ask, which beats allow, and a deny wins from any scope. That gives you a blunt instrument worth knowing about. You can deny an MCP server across all workspaces in ~/.kiro/settings/permissions.yaml while still allowing it in the one project that needs it.

Where it fits

MCP is the “what it can reach” layer. Powers sit directly on top of it: a power bundles an MCP server configuration with a POWER.md steering file and optional hooks, so the agent knows not just that a tool exists but when to use it. Custom agents can declare their own mcpServers, which is where agent-level precedence comes from, and can be restricted so a scoped agent reaches only the servers its job needs.

By surface: the IDE and the CLI both configure and run MCP servers. Kiro Crew lists integrations through MCP among its agent capabilities. Since September 1, 2026, MCP servers configured in Kiro Web sync down to local IDE and CLI sessions as read-only previews.

Learn more

• Add an MCP server is the step-by-step version.
• Add a power shows the packaged alternative.
• Create a custom agent covers agent-level server configuration.
• Troubleshooting has the full MCP symptom table.
• Advanced Tutorial uses MCP in a real workflow.