How AI Connects to Your Systems — MCP Explainer

💡 Why Does AI Need MCP?

Without MCP, AI can only work with text you paste into it. It can't look things up, check databases, or take actions in your systems. MCP changes that.

📋

Without MCP

Export CSV → paste into chat → AI analyzes what you gave it. Manual, one-at-a-time.

🔌

With MCP

AI queries your database directly, gets exactly what it needs, analyzes live data. Automatic.

🔌

USB-C for AI

Just as USB-C connects any device to any peripheral, MCP connects any AI to any data source.

🌐

Open Standard

Works with Claude, ChatGPT, Kiro, Cursor, VS Code — build once, connect everywhere.

🏦 What MCP Means for Insurance Teams

Your team works with databases, spreadsheets, document stores, and internal APIs every day. MCP lets AI access these systems the same way you do — but faster.

Today (Manual)	With MCP (Automated)
Export claims data to CSV, paste into AI	AI queries claims database directly
Open 50 medical reports one by one	AI scans the claims documents folder automatically
Check policy coverage across 3 different systems	AI checks all 3 systems in one request
Copy policyholder data, format it, paste it	AI runs SQL query, gets exactly what it needs
Manually send alert when fraud detected	AI sends the alert automatically via MCP

💡

Key insight: MCP doesn't replace your systems — it connects AI to them. Your databases, APIs, and tools stay exactly where they are. MCP just gives AI a way to talk to them.

⚡ API vs MCP — What's the Difference?

Both APIs and MCP let systems talk to each other. But they solve different problems and work at different levels. Here's the clearest way to think about it:

🔌

API (Application Programming Interface)

A contract between two systems. "Send me this request, I'll give you this response." Designed for programs to talk to programs.

🧠

MCP (Model Context Protocol)

A contract between AI and systems. "Here are the tools I offer — the AI decides when and how to use them." Designed for AI to discover and use capabilities.

The Key Difference: Who Decides?

Aspect	Traditional API	MCP
Who calls it?	A developer writes code: `fetch('/api/claims')`	The AI decides on its own: "I need claims data, let me call `read_query`"
Discovery	Developer reads API docs, writes integration code	AI asks the server "what tools do you have?" and figures it out
Flexibility	Fixed endpoints — each use case needs a specific API call	AI composes tools dynamically — same tools, infinite use cases
Who builds it?	Developers build and maintain integrations	Configure once, AI handles the rest
Error handling	Developer codes retry logic, error parsing	AI reads the error, adjusts its approach, tries again

🏦 AnyCompany Example: Getting Claims Data

🔌 With a Traditional API

A developer writes this code:

// Developer writes this
const resp = await fetch(
  '/api/claims?status=pending'
);
const data = await resp.json();
// Then format, display, handle errors...
        

Requires: developer time, API knowledge, error handling code, maintenance when API changes.

🧠 With MCP

You just ask in plain English:

// You type this in Kiro:
"Show me all pending claims over $10K
 with their policy details"

// AI automatically:
→ tools/call read_query
  SELECT * FROM claims
  WHERE status = 'pending' AND amount > 10000
        

Requires: MCP server configured (one-time JSON file). No code, no API knowledge needed.

💡

The analogy: An API is like a vending machine — you press the exact button for what you want. MCP is like a personal assistant with access to the vending machine — you say "I'm thirsty" and they figure out which button to press.

🤝 They Work Together, Not Against Each Other

MCP doesn't replace APIs — it wraps them so AI can use them. Many MCP servers are just thin wrappers around existing APIs.

Scenario	Use API directly	Use MCP
Building a web app that shows claims dashboard	✅ Yes — your app code calls the API	❌ No — apps don't need AI reasoning
AI agent that investigates claims fraud patterns	❌ No — AI can't call APIs on its own	✅ Yes — AI discovers and calls tools
Automated report that pulls from policy, claims, and underwriting databases	⚠️ Possible but needs custom code	✅ Yes — AI queries all 3 via MCP
Slack bot that responds to commands	✅ Yes — fixed command → fixed response	✅ Also works — AI reasons about the request
Dashboard with real-time charts	✅ Yes — direct data pipeline	❌ No — MCP is for AI, not dashboards

🔑

Rule of thumb: If a human or program knows exactly what data it needs → use an API. If an AI needs to figure out what data it needs based on a question → use MCP. In practice, MCP servers often call APIs under the hood — you just don't have to write the integration code.

🔧 MCP Architecture

MCP follows a simple client-server pattern. The AI application (Kiro) is the host. It creates clients that connect to servers. Each server provides access to a specific data source or tool.

🤖 MCP Host Kiro / Claude / Cursor

→

🔗 MCP Client One per server

→

🗄️ MCP Server Database / API / Files

Three Core Primitives

Every MCP server can expose three types of capabilities:

🔨

Tools

Actions the AI can perform: run a SQL query, call an API, send a message. The AI decides when to use them.

📦

Resources

Data the AI can read: file contents, database schemas, API responses. Like giving the AI access to a document.

💬

Prompts

Reusable templates that structure how the AI interacts with the server. Like pre-built query patterns.

⚙️ How Connection Works

When you configure an MCP server in Kiro, here's what happens under the hood:

Step	What happens	You see
1. Configure	You add the server to `.kiro/settings/mcp.json`	Edit a JSON file
2. Connect	Kiro launches the MCP server process and negotiates capabilities	Green checkmark ✅ in MCP panel
3. Discover	Kiro asks the server "what tools do you have?" via `tools/list`	Tool names appear in the panel
4. Use	When you ask a question, Kiro decides which tool to call and sends a `tools/call` request	AI response includes data from the server

🔍

Two transport modes: MCP servers can run locally (on your machine, using stdio — like the Fetch server) or remotely (on a server, using HTTP — like a cloud API). The protocol is the same either way.

🔬 Under the Hood: What Actually Happens

When you type a question in plain English, here's the exact transformation that occurs — from your words to a structured tool call and back to a human-readable answer.

The Full Transformation Chain

1 You type (natural language)

"What are the pending claims over $50K that were submitted this month?"

2 LLM decides which tool to call

The LLM sees the list of tools the MCP server advertised during connection. Based on your question, it decides which tool to call and constructs the arguments:

// LLM's output (structured tool call — NOT raw JSON-RPC):
Tool: read_query
Arguments: {
  "query": "SELECT claim_id, policyholder, amount, status, submitted_date FROM claims WHERE status = 'pending' AND amount > 50000 AND submitted_date >= '2026-05-01'"
}
        

💡 The AI decides what to call and what arguments to pass. It does NOT write the JSON-RPC envelope — that's the next layer's job.

3 MCP Client wraps it in JSON-RPC and sends to server Protocol layer

Kiro's MCP Client takes the LLM's tool call decision and packages it into the standard JSON-RPC 2.0 format. The AI never writes this — the infrastructure handles it automatically:

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "read_query",
    "arguments": {
      "query": "SELECT claim_id, policyholder, amount, status, submitted_date FROM claims WHERE status = 'pending' AND amount > 50000 AND submitted_date >= '2026-05-01'"
    }
  },
  "id": 1
}
        

💡 The MCP protocol is the transport standard — it ensures any AI host (Kiro, Claude, Cursor) can talk to any MCP server using the same format. The LLM provides the intent; the protocol provides the envelope.

4 MCP Server executes and returns result

{
  "jsonrpc": "2.0",
  "result": {
    "content": [{
      "type": "text",
      "text": "[{\"claim_id\":\"CLM-2026-0847\",\"policyholder\":\"Tan Wei Ming\",\"amount\":78500,\"status\":\"pending\",\"submitted_date\":\"2026-05-03\"}, ...]"
    }]
  },
  "id": 1
}
        

5 AI formats the answer for you

Found 3 pending claims over $50K submitted this month:

| Claim ID       | Policyholder   | Amount    | Date       |
|----------------|----------------|-----------|------------|
| CLM-2026-0847  | Tan Wei Ming   | $78,500   | 3 May 2026 |
| CLM-2026-0891  | Sarah Lim      | $125,000  | 7 May 2026 |
| CLM-2026-0903  | Ahmad bin Ismail| $62,300  | 5 May 2026 |

Total pending: $265,800 across 3 claims.
        

🧠 Why This Helps AI Agents

Without MCP, an AI agent is limited to what's in its training data and what you paste into the chat. With MCP, the agent gains real capabilities:

🔍

Tool Discovery

At connection time, the server tells the AI: "Here are my tools, here's what each one does, here are the parameters." The AI doesn't need to be pre-programmed — it learns what's available.

🧩

Dynamic Composition

The AI can chain multiple tools together. "Get claims data" → "Cross-reference with policy limits" → "Flag the ones that exceed coverage." One question, multiple tool calls.

🔄

Error Recovery

If a tool call fails, the AI reads the error message and adjusts. Wrong table name? It asks the server for the schema and tries again. No human intervention needed.

📐

Structured I/O

MCP uses JSON-RPC 2.0 — a standard wire format. This means any AI that speaks MCP can use any MCP server. Build once, connect to Claude, Kiro, Cursor, or any future AI.

📋 What the AI Sees: Tool Advertisement

When an MCP server connects, it advertises its tools with a schema. This is what the AI "reads" to understand what it can do:

// Response to "tools/list" — the AI sees this at connection time
{
  "tools": [
    {
      "name": "read_query",
      "description": "Execute a SELECT query on the claims database",
      "inputSchema": {
        "type": "object",
        "properties": {
          "query": { "type": "string", "description": "SQL SELECT query" }
        },
        "required": ["query"]
      }
    },
    {
      "name": "list_tables",
      "description": "List all tables in the database",
      "inputSchema": { "type": "object", "properties": {} }
    }
  ]
}
    

🔑

This is the magic: The AI reads the tool name, description, and parameter schema — then decides on its own when and how to use it. You never write integration code. The AI figures out that "pending claims over $50K" means calling read_query with a SQL WHERE clause. The description field is what teaches the AI what each tool does.

🔐 Security: Who Controls What the AI Can Do?

MCP gives AI capabilities — but with clear boundaries:

Control Layer	Who sets it	What it controls
MCP Server design	Server developer	Which tools exist, what they can do (e.g., read-only vs. read-write)
IAM / Permissions	Cloud admin	What the server's credentials can access (e.g., only the claims table, not the HR table)
MCP config	You (the user)	Which servers are enabled, which tools are auto-approved vs. require confirmation
Human-in-the-loop	Kiro UI	You see each tool call and can Allow or Reject before it executes

💡

For AnyCompany: You'd build an MCP server for claims that only exposes read_query (no writes). The IAM role would only have SELECT access to the claims table. Even if the AI "wanted" to delete data, it physically can't — the permissions don't allow it. Defense in depth.

🎮 MCP Message Flow — Interactive Demo

Watch messages flow through the full MCP architecture as you ask a question. Each step shows exactly what's happening between components.

Message Flow

Step 0 / 0

👤

You

Plain English

🤖

Kiro (Host)

AI reasoning

🔗

MCP Client

JSON-RPC 2.0

⚙️

MCP Server

varies per scenario

🌐

Data Source

Web / DB / AWS

Press Play or Step Forward to watch the message flow.

🏦 MCP Servers for Insurance Teams

These are the most common MCP servers your team would use. You specify what connections are needed in the Agent Design Canvas — your tech team configures the actual servers.

MCP Server	Connects to	Insurance use case	Setup
AWS API	AWS services	Query S3, Bedrock models, check infrastructure status	Config + credentials
AWS Documentation	AWS docs	Search service documentation, architecture guidance	Config only
Fetch	Web pages	Read product guides, competitor pages, regulatory notices	Config only
Database (PostgreSQL)	Databases	Query policy data, claims history, underwriting records	Config + credentials
Filesystem	File directories	Process folders of medical reports, scan claim documents	Config only
Slack / Teams	Team messaging	Send alerts when fraud pattern detected	API key
Google Drive / S3	Document storage	Read policy wordings and product specs for RAG grounding	OAuth / IAM
Email (SMTP)	Email systems	Send claims decisions, escalation alerts	SMTP config
Custom REST API	Internal services	Call underwriting rules engine, claims adjudication API	Custom build

💡

You design the recipe, your tech team sets up the kitchen. In the Agent Design Canvas, you specify "MCP connections needed: claims database, policy admin system, Slack for alerts." Your engineering team then configures the actual MCP servers. The open-source community has pre-built servers for most common systems.

⚙️ Configuration Example

This is what an MCP configuration looks like in Kiro. It's a simple JSON file — no code required:

// .kiro/settings/mcp.json
{
  "mcpServers": {
    "fetch": {
      "command": "uvx",
      "args": ["mcp-server-fetch"],
      "disabled": false
    },
    "aws-docs": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "env": { "FASTMCP_LOG_LEVEL": "ERROR" }
    },
    "aws-api": {
      "command": "uvx",
      "args": ["awslabs.aws-api-mcp-server@latest"],
      "env": { "AWS_REGION": "us-east-1" }
    }
  }
}
    

Three MCP servers, each a few lines of JSON. Kiro launches them, connects, and you can fetch web pages, search documentation, and query AWS — all in plain English.

🔗 The Complete Kiro Stack

MCP is the fourth and final layer of the Kiro automation stack. Here's how all 4 layers work together:

📋 Steering
Global rules

→

🛠️ Skills
On-demand expertise

→

⚡ Hooks
Auto-triggers

→

🔌 MCP
Data connections

How They Work Together — Claims Fraud Detection Example

Layer	What it does	In the fraud detection workflow
Steering	Sets global rules	SGD currency, no PII (NRIC/policy numbers), APPROVE/FLAG/REJECT ratings
Skill	Defines the investigation process	Claims Fraud Investigator persona, investigation report format, guardrails
Hook	Triggers automatically	New claim flagged → run fraud investigation skill
MCP	Connects to data	Fetch MCP → read policy documents; AWS API → query claims database, check provider records

🔍

The full automation loop: Flagged claim arrives → Hook detects it → Skill activates → MCP queries claims database → Investigation report generated → Claims adjuster reviews the recommendation. The AI handles the investigation; you make the decision.

🗺️ Your Workshop Journey

Module	What you learn	What you build
M1-M2	What agents are, how they work	Understanding of agent architecture
M3	Workflow patterns (chain, parallel, route, orchestrate)	Pattern selection for insurance workflows
M4-M5	AWS tools, frameworks (Kiro, Strands, AgentCore)	Hands-on with Kiro skills, hooks, MCP
M6	Custom solutions, guardrails, evaluation	Working agent with database connection

The thread: Module 1's agent concepts → applied in Module 3's workflow patterns. Module 3's patterns → implemented in Module 5's hands-on labs. Module 4's tools → connected via Module 5's MCP. Everything builds on what came before.