---
title: "11 — Connecting Tools with MCP — The Universal Port for AI"
uid: connecting-tools-mcp
tags: ["channels", "tunnels", "roadmap:claude-code", "model-context-protocol", "tools", "mcp", "claude-code"]
excerpt: "MCP is a standardized bridge — the USB-C port for AI — so the loop discovers and calls external functions through one protocol instead of one custom integration per service."
date: 2026-08-13T03:28:21+0000
source: https://www.aveshina.my.id/en/blog/connecting-tools-mcp
---

"Plugins, basically" was how I described MCP, and it undersold the standardization. The frame that stuck: **MCP is a standardized bridge that lets the loop discover and call external functions, so Claude connects to any service through one protocol instead of needing a custom-coded integration per tool.** [1] The roadmap's metaphor is exact: it's a "USB-C port for AI." One cable shape, many devices.

The framing that clicked is the contrast with the built-in tools. Read, Edit, Bash, Grep are the loop's hands on _my local machine_. MCP is the mechanism that gives it hands on _everything else_ — GitHub to manage pull requests, a Postgres or Snowflake database to query, Jira or Linear to update issues [1]. Without MCP, every one of those would need a bespoke integration coded into Claude itself. With MCP, each service publishes a server that speaks the protocol, and Claude discovers and calls whatever functions that server exposes.

## What MCP actually is

The protocol is an open standard. The roadmap's definition is precise: it enables Claude Code to connect securely to a vast ecosystem of external tools, databases, and third-party services, extending the core capabilities beyond simple file editing [2]. Three properties matter:

- **Standardized.** One protocol, any server. I don't write integration code; I run a server that already exists (or write one against the spec).
- **Discoverable.** Claude learns what tools a server exposes dynamically — it doesn't need them hard-coded. The tool menu grows by connecting servers, not by patching the agent.
- **Isolated.** Each MCP server is its own process. Connecting one doesn't grant access to another; permissions are granted per server.

```figure
<svg viewBox="0 0 740 280" xmlns="http://www.w3.org/2000/svg" class="my-6 w-full max-w-2xl" role="img" aria-label="MCP as a USB-C port for AI. Left: an agent orb labelled Loop. Center: a single standardized port labelled MCP. Right: five external services each plugging into that one port with the same cable shape — GitHub, Postgres, Jira, Slack, Snowflake. One service (internal DB) connects through a locked tunnel icon labelled 'outbound-only, no inbound port'.">
  <defs>
    <marker id="mcp1" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto">
      <path d="M0,0 L10,5 L0,10 z" fill="#64748b"/>
    </marker>
  </defs>
  <g font-family="ui-sans-serif, system-ui, sans-serif" text-rendering="geometricPrecision">
    <!-- agent orb -->
    <rect x="20" y="110" width="130" height="60" rx="30" fill="#e0e7ff" stroke="#6366f1" stroke-width="1.8"/>
    <text x="85" y="138" font-size="13" font-weight="700" fill="#1e1b4b" text-anchor="middle">Loop</text>
    <text x="85" y="155" font-size="9.5" fill="#475569" text-anchor="middle">+ built-in tools</text>

    <!-- MCP port -->
    <rect x="230" y="115" width="120" height="50" rx="8" fill="#dcfce7" stroke="#16a34a" stroke-width="1.8"/>
    <text x="290" y="138" font-size="13" font-weight="700" fill="#052e16" text-anchor="middle">MCP</text>
    <text x="290" y="154" font-size="9.5" fill="#052e16" text-anchor="middle">one protocol</text>
    <path d="M150,140 L228,140" fill="none" stroke="#64748b" stroke-width="1.5" marker-end="url(#mcp1)"/>

    <!-- services -->
    <g font-size="10.5" font-family="ui-monospace,monospace">
      <rect x="400" y="40" width="130" height="32" rx="6" fill="#fef9c3" stroke="#ca8a04" stroke-width="1.2"/>
      <text x="465" y="60" fill="#422006" text-anchor="middle">GitHub</text>
      <path d="M350,135 C370,90 390,60 398,56" fill="none" stroke="#64748b" stroke-width="1.2"/>

      <rect x="545" y="40" width="130" height="32" rx="6" fill="#fef9c3" stroke="#ca8a04" stroke-width="1.2"/>
      <text x="610" y="60" fill="#422006" text-anchor="middle">Jira</text>

      <rect x="400" y="100" width="130" height="32" rx="6" fill="#fef9c3" stroke="#ca8a04" stroke-width="1.2"/>
      <text x="465" y="120" fill="#422006" text-anchor="middle">Postgres</text>
      <path d="M350,140 L398,116" fill="none" stroke="#64748b" stroke-width="1.2"/>

      <rect x="545" y="100" width="130" height="32" rx="6" fill="#fef9c3" stroke="#ca8a04" stroke-width="1.2"/>
      <text x="610" y="120" fill="#422006" text-anchor="middle">Slack</text>

      <rect x="400" y="160" width="130" height="32" rx="6" fill="#fef9c3" stroke="#ca8a04" stroke-width="1.2"/>
      <text x="465" y="180" fill="#422006" text-anchor="middle">Snowflake</text>
      <path d="M350,145 C370,165 390,176 398,176" fill="none" stroke="#64748b" stroke-width="1.2"/>

      <!-- internal via tunnel -->
      <rect x="400" y="210" width="130" height="32" rx="6" fill="#fce7f3" stroke="#db2777" stroke-width="1.5"/>
      <text x="465" y="230" fill="#500724" text-anchor="middle">internal DB</text>
      <text x="465" y="258" font-size="8.5" fill="#db2777" text-anchor="middle">🔒 tunnel · outbound-only</text>
      <path d="M350,150 C370,210 390,226 398,226" fill="none" stroke="#db2777" stroke-width="1.2" stroke-dasharray="5,3"/>
    </g>
  </g>
</svg>
```

## Skills improve how MCP gets used

A subtle but important pairing: **skills make MCP usage smarter.** The roadmap flags that skills act as structured knowledge packages that improve how Claude interacts with MCP servers, giving it precise, context-aware instructions for specific tools and workflows [3]. Rather than the model inferring how to use a given server from scratch each time, a skill provides curated guidance on which calls to make, how to chain them, and how to interpret results.

The way of thinking: MCP grows the tool menu; skills shape _how_ the model reaches into that menu. A GitHub MCP server exposes functions; a "manage a pull request" skill tells the model which sequence of those functions actually produces a good PR. They compose — and the discipline (from the skills post) still holds: enable only the MCP servers a session needs, because every server's tool definitions consume context [4].

## Channels: pushing the outside in

Channels showed up earlier (in the surfaces post) as a way to use Claude from a phone. From the MCP angle, they're a specific kind of MCP server plugin: they push messages, alerts, and webhooks _into_ a running session [5]. I install one for Telegram, Discord, or iMessage, configure credentials, pair my account, and events arrive in my already-open session — ideal for an always-on setup where Claude runs in the background.

The distinction worth holding onto: regular MCP servers expose functions the model calls when _it_ needs something; channels push events _in_ from the outside world without the model asking. Both speak MCP; the direction differs.

## MCP tunnels: private network, no exposed ports

The piece that took longest to click is **MCP Tunnels**, and it matters for any real-world setup. Tunnels connect Claude to MCP servers running inside a _private network_ without opening inbound firewall ports or exposing services to the public internet [6]. Traffic flows over an outbound-only encrypted connection, so internal tools and data sources stay fully private while still being reachable.

Why this is a big deal: most enterprise data — internal databases, private APIs, intranet services — can never be exposed publicly, which without tunnels would mean MCP simply can't reach them. With tunnels, I can build agents that interact with internal systems securely, because the connection is initiated from inside the private network outward. The security posture is "no inbound surface," which is the only posture a security team will sign off on.

## Managing MCP in a session

The /mcp slash command is the integration hub inside a session. While I use claude mcp add in the terminal to install a new server, /mcp manages connections, authorizes permissions, and views the specific tools available to the model [7]. It's the place to check what the tool menu actually contains right now — which matters for the context-hygiene discipline of enabling only what's needed.

## How I use this

The habit these notes left me with is an enablement test for MCP servers: _does this session actually call into that service?_ If not, the server stays disabled, because its tool definitions cost context every turn. For sessions that do need external reach, I pair the MCP server with a skill that shapes how the model uses it, so the calls are deliberate rather than improvised. And for anything behind a corporate firewall, tunnels are the only acceptable path — outbound-only, no inbound port, full privacy. The throughline: MCP grows what the loop can touch; the discipline is keeping that growth intentional.

## References

[1] Anthropic, "Connect Claude Code to tools via MCP," Claude Code Docs, 2025. [Online]. Available: [https://code.claude.com/docs/en/mcp](https://code.claude.com/docs/en/mcp)

[2] Model Context Protocol, "What is the Model Context Protocol?," 2025. [Online]. Available: [https://modelcontextprotocol.io/docs/getting-started/intro](https://modelcontextprotocol.io/docs/getting-started/intro)

[3] Anthropic, "The Complete Guide to Building Skills for Claude," Anthropic Resources, 2025. [Online]. Available: [https://resources.anthropic.com/hubfs/The-Complete-Guide-to-Building-Skill-for-Claude.pdf?hsLang=en](https://resources.anthropic.com/hubfs/The-Complete-Guide-to-Building-Skill-for-Claude.pdf?hsLang=en)

[4] Mario Giancini, "The Hidden Cost of MCP Servers (And When They're Worth It)," 2025. [Online]. Available: [https://mariogiancini.com/the-hidden-cost-of-mcp-servers-and-when-theyre-worth-it](https://mariogiancini.com/the-hidden-cost-of-mcp-servers-and-when-theyre-worth-it)

[5] Anthropic, "Push events into a running session with channels," Claude Code Docs, 2025. [Online]. Available: [https://code.claude.com/docs/en/channels](https://code.claude.com/docs/en/channels)

[6] Anthropic, "MCP Tunnels," Claude Developer Platform Docs, 2025. [Online]. Available: [https://platform.claude.com/docs/en/agents-and-tools/mcp-tunnels/overview](https://platform.claude.com/docs/en/agents-and-tools/mcp-tunnels/overview)

[7] Anthropic, "Interactive mode — /mcp," Claude Code Docs, 2025. [Online]. Available: [https://code.claude.com/docs/en/interactive-mode](https://code.claude.com/docs/en/interactive-mode)

```quiz
Q: What problem does MCP solve?
- It is a faster way to run shell commands locally
- It is a standardized bridge so the loop can discover and call external functions without a custom-coded integration per service
correct: 1
explain: Without MCP, every external service (GitHub, Postgres, Jira) would need its own bespoke integration in Claude. MCP is one protocol any server can speak — "USB-C for AI."

Q: How do skills relate to MCP servers?
- They replace the need for MCP servers
- Skills shape HOW the model uses an MCP server's tools, giving curated guidance on calls, chains, and interpretation
correct: 1
explain: MCP grows the tool menu; skills provide the knowledge for using that menu well. A GitHub MCP server exposes functions; a PR skill tells the model which sequence makes a good PR.

Q: What is the difference between a regular MCP server and a channel?
- They are identical
- A regular server exposes functions the model calls on demand; a channel pushes events INTO the session from outside (Telegram, Discord, iMessage)
correct: 1
explain: Both speak MCP. Regular servers are model-initiated (pull); channels are externally-initiated (push into a running session).

Q: Why are MCP Tunnels necessary for enterprise data?
- They make queries run faster
- They connect to private-network servers with an outbound-only connection, so no inbound firewall ports are opened and services stay private
correct: 1
explain: Internal databases and private APIs can't be exposed publicly. Tunnels let Claude reach them over an outbound-only encrypted link, giving a "no inbound surface" security posture.

Q: Why should you disable MCP servers a session doesn't use?
- Unused servers crash the session
- Their tool definitions consume context every turn, polluting the window and raising cost
correct: 1
explain: Every enabled server adds its tool definitions to the context the model re-reads each turn. The enablement test: enable only servers the session actually calls.
```