Chapter 0: Clone the workshop

This chapter gets the Support Escalation MCP server running, connects your coding agent to it, and walks you through using it the way a support engineer would. Your agent will file a real Linear issue, and you’ll see the security gaps you’ll close with Keycard in this workshop.

Clone the repo

Command line

git clone https://github.com/keycardai/keycard-workshop-code
cd keycard-workshop-code

Inside, you’ll find the starter MCP server (support-escalation/), completed MCP server (mcp-server/), agent skills, and configuration files.

Note

You’ll spend most of the workshop in support-escalation/, building on top of the initial insecure MCP server. The mcp-server/ folder contains the completed code. If you get off track, see Checkpoints for code recovery instructions.

Set up the server

1. Install dependencies:

   Command line

   cd support-escalation
   npm install

2. Copy the example environment file and open it:

   Command line

   cp .env.example .env

   You’ll see an empty LINEAR_API_KEY variable. The instructor will provide the API key. Read the comment above the key to learn about the problems with shipping access this way. You’ll feel each of them firsthand in a few minutes (and you may have already felt them yourself in the wild).

3. Start the server:

   Command line

   npm run dev

   It serves on http://localhost:8000/mcp. There is no web interface, it’s just an API. Leave it running.

Real API key = real risks

The provided Linear API key accesses a shared workshop workspace. Anything you (or your agent) does with your MCP server actually shows up there. The customer support ticket data is fake, but the flow and the risks are real. This will be made especially apparent with many people using the same workspace simultaneously during the workshop.

Connect your coding agent

The MCP server uses HTTP. Connect your agent.

Already have a Linear MCP server?

If your editor already has another Linear (or similar) MCP server configured, disable it for this workshop. Otherwise your agent may call that server instead of the one you’re building, which is confusing and routes tool calls to the wrong place.

Claude Code

In your terminal, enter the following command:

Command line

claude mcp add --transport http support-escalation http://localhost:8000/mcp

Claude Desktop

Claude Desktop only launches stdio servers, so you bridge to the HTTP endpoint with mcp-remote. Add this to claude_desktop_config.json, then fully quit and reopen the app:

claude_desktop_config.json

{
  "mcpServers": {
    "support-escalation": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "http://localhost:8000/mcp"]
    }
  }
}

Codex

~/.codex/config.toml

[mcp_servers.support-escalation]
url = "http://localhost:8000/mcp"

Cursor

~/.cursor/mcp.json

{
  "mcpServers": {
    "support-escalation": {
      "url": "http://localhost:8000/mcp"
    }
  }
}

Then open Settings (Cmd+Shift+J / Ctrl+Shift+J) → Features → Model Context Protocol and confirm support-escalation is enabled.

Access without authentication

You just connected to the MCP server without credentials or a login. The server didn’t ask who you are, because it has no way to. Unrestricted MCP server access is the first security problem.

Discover available tools

Ask your agent what tools are available from the MCP server:

Prompt your coding agent

List the tools the support-escalation server exposes.

Three tools are listed: get_support_tickets, escalate_ticket, and delete_issue. This is MCP tool discovery: your agent sees the surface the server exposes, and nothing else. Those three calls are the entire attack surface you’ll secure over the course of the workshop.

Try out the MCP server

Now test drive the MCP server. Ask your agent to look at the support queue and escalate the most critical ticket.

Prompt your coding agent

Using the support-escalation tools, list the open support tickets. Then escalate the critical payment ticket (the one about double charges) to engineering with escalate_ticket.

Your agent calls get_support_tickets, reads the tickets, picks the critical double-charge one, and calls escalate_ticket. It creates a new issue in the shared Linear workspace. Open the link it gives you.

If your agent hesitates before escalating

Some agents notice the sensitive data in that ticket and warn you, or offer to redact it first. Tell it to go ahead. Then notice what just happened: the agent couldn’t redact anything even if you wanted it to. escalate_ticket only accepts a ticket ID, and the server then builds the issue content exactly as written.

An agent’s good judgment isn’t a security control. Data crosses the boundary on the MCP server’s terms, so the fix has to live server-side. You’ll build this in Chapter 5.

Assess security problems

Three things just went wrong.

1. The MCP server is completely unsecured.

Anyone who can reach localhost:8000 can call every tool. There’s no bearer token, no authentication, no concept of identity (user, agent, or otherwise). In production, this is an MCP server on the internet that anyone can drive.

2. One shared Linear API key does everything under the same account every time.

Every escalation in the room is created by the same Linear key. The key belongs to one Linear account: “Learn Keycard (learn@keycard.ai).” Linear creates every issue while acting as “Learn Keycard” (never as you). This happens no matter who actually escalated it.

The creator field isn’t blank; it’s filled in confidently and uselessly, with the same name for everyone. You can’t tell who filed which issue, can’t audit a single attendee, and couldn’t revoke one person without cutting off everyone. The key is also a kitchen sink: escalate_ticket only needs to create one issue, but it holds the power to read, edit, and delete anything at the agent’s discretion.

3. Customer PII is exposed in Linear.

Look at the issue content. The ticket was copied in verbatim, so a customer’s social security number and credit card are now exposed in engineering’s issue tracker. Nothing masked Personally Identifiable Information (PII), because nothing in the MCP server knows it should.

Clean up after yourself

Ask your agent to delete the issue you just filed:

Prompt your coding agent

Use the delete_issue tool to delete the support escalation issue you just filed.

That trashes the issue in the shared workspace, and demonstrates the danger of API keys again: the same credential that created the issue can also delete it at will.

What Delete does in Linear

“Delete” here means trash because Linear soft-deletes the issue, so it moves to the workspace trash (recoverable) rather than vanishing. If you still have the issue open, it’ll reload with a small “deleted” banner instead of a 404. Trash is all this tool can ever do; permanent deletion is a higher-privilege action, which is discussed in Chapter 7.

What’s next?

During the workshop, you’ll close all of these security gaps, addressing one thing at a time so you always know which fix did what. You’ll put real authentication in front of /mcp, give every tool call a verifiable identity, move secrets into a vault, swap the shared Linear API key for per-user delegated access, mask the PII with an LLM, and finally write a policy that refuses to let the agent overreach.

Checkpoint

• Your agent is connected to the server.
• get_support_tickets returns the tickets.
• You’ve filed (and ideally trashed) a Linear issue in the shared workspace.
• You can point to all three security risks in the issue you created.