Getting Started with MCP — the Open Standard for Connecting AI Agents to Tools and Data

What is MCP?

MCP (Model Context Protocol) is an open standard for connecting AI models to external tools and data sources. Anthropic introduced it in late 2024 and released it as open source, and it is now adopted by a range of AI clients. The core idea is simple: expose "tools an AI can use" through a standard interface, and any MCP-compatible client can use them as-is.

Just as REST APIs standardized service-to-service integration, MCP standardizes the AI ↔ tool connection. Wrap a filesystem, database, internal API, or search index once as an MCP server, and multiple agents can share it. The side that builds a tool and the side that uses it talk over the same contract (the protocol), so they interoperate without knowing anything about each other's internals.

A useful analogy: MCP is like USB-C for AI. It used to be that every device needed its own proprietary cable; once a standard port arrived, one cable plugged into everything. MCP does the same thing for "the port where an AI meets the outside world" — it unifies it into a single spec.

Why a standard was needed — the M×N problem

Before MCP, every AI application wired up the tools it needed by hand, every time. If there are M clients and N tools or data sources you want to connect, you end up hand-writing roughly M×N separate integrations. Editor A talks to GitHub one way, editor B another way, and every time a new data source appears, every editor has to integrate it again. Integrations fragment, and the same work gets rebuilt team by team.

MCP turns that into M+N. A tool provider builds an MCP server once, a client implements an MCP client once, and after that any server meshes with any client over the shared standard. When a new tool appears, you add one server, and every MCP-aware client can use it immediately. That leverage is the biggest payoff of standardization.

The shape of MCP — hosts, clients, and servers

MCP has three roles. The vocabulary is easy to mix up, so pinning it down once makes everything after it easier.

• Host: the application the user faces. Marblo, the Claude desktop app, and various AI editors are hosts. The model and the clients live inside the host.
• Client: a connector inside the host that maintains a 1:1 connection with exactly one server. Three servers means three clients.
• Server: a process that exposes actual tools, data, and prompts in a standard shape. Servers exist per capability — a filesystem server, a GitHub server, a database server.

Messages travel as JSON-RPC 2.0 — requests, responses, and notifications in well-defined envelopes. Because of that, a server written in any language is interpreted identically by any client.

What an MCP server exposes — tools, resources, prompts

An MCP server offers three kinds of capabilities (primitives) in a standardized form.

• Tools: functions the model calls to execute. They expose actions with side effects — write_file, query_sql, create_issue. Each tool carries a name, a description, and an input schema (JSON Schema), so the model can decide on its own when to call it and with what arguments.
• Resources: data the model reads in. File contents, documents, DB records — material to inject as context, identified by URI. If tools are "verbs," resources are closer to "nouns."
• Prompts: reusable prompt templates the server prepares ahead of time. A canned request like "review this code" that a user can pull up like a slash command.

When a server declares these, the client — right after connecting — asks "what tools, resources, and prompts does this server have?" (discovery) and hands that list to the model. So you don't hardcode tools into your code; swap the server and the model's available capabilities change wholesale.

How a tool call actually flows

The most common primitive is the tool call. Tracing one real call in order makes the MCP picture click.

1. The user asks, "find files in this folder that still have TODOs."
2. The model looks at the tool list the server exposed and decides to call the search_files tool with suitable arguments.
3. The client wraps that call as a JSON-RPC request and sends it to the server.
4. The server does the actual work (scanning the directory) and returns the result as a response.
5. The client puts the result into the model's context, and the model composes a human-readable answer on top of it.

The key point is that the model never has to know the server's internals. It only knows "there is a tool with this name and schema" and calls it — whether that tool scans local files or hits a remote API is irrelevant. Because implementation and use are separated by the protocol, the same tool keeps working when you move it to a different model or a different client.

A minimal example

MCP servers usually talk over stdio or HTTP. You register a server in the client's config:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/dir"]
    }
  }
}

With that in place, the agent gains tools to read and write in that directory. The command and args say how to launch the server process — the example above uses npx to fetch and run the filesystem server package, passing the directory to grant access to as an argument. The client spawns this process as a child and exchanges JSON-RPC messages over its standard input/output (stdio).

Understanding the config structure

In practice you rarely attach just one server. List as many entries as you need under mcpServers, and each entry becomes a separate server process and a separate bundle of tools.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/repo"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "..." }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "postgres://..."]
    }
  }
}

Each server exposes only its own slice of capability. The filesystem server offers file read/write, the GitHub server offers issue and PR tools, the Postgres server offers SQL queries. Injecting secrets like tokens through env keeps them in the server process only, so credentials never get mixed into the model's prompt.

stdio or HTTP — choosing a transport

MCP standardizes two transports for carrying messages.

• stdio: the client launches the server as a local child process and exchanges JSON-RPC over standard input/output. Setup is simple and latency is low, which suits tools that run inside your own machine — a local filesystem, a local DB. Most people start here.
• HTTP: the server runs remotely and the client connects over the network. For an internal service shared by many users, or a server wrapping an already-deployed API, HTTP is the natural fit.

What to pick comes down to "where does the server run?" A resource inside your machine → stdio; a remote resource the team shares → HTTP. That one criterion usually settles it.

Why it matters

• Reusability: build a tool as an MCP server once instead of re-wiring it per client. One internal tool server your team builds is used as-is by every developer's every agent.
• Isolation: each server exposes only its own scope, which keeps access easy to control. Allow the file server only a specific directory, the DB server only a specific connection — keep the boundary narrow.
• Composability: attach several MCP servers to extend an agent's capabilities like Lego bricks. Attach files + GitHub + DB together and a single agent can read code, open issues, and query data in one smooth chain.

Security — keep the trust boundary narrow

Since you are handing the model powerful tools, always stay conscious of permission scope when using MCP. A few principles cut the risk sharply.

• Least privilege: grant a server only what it truly needs. For a file server, the working directory rather than the repo root; for a DB, start from a read-only connection.
• Isolate secrets: inject tokens and keys into the server process only (via env, as above), and keep them out of prompts and logs.
• Only trusted servers: attaching an arbitrary MCP server is like running arbitrary code. Register only servers of known provenance, and put a human-confirmation step in front of high-impact tools (delete, deploy, payment).

Marblo and MCP

Marblo supports MCP natively. When you run multiple AI agents at once, you can configure them to share the same set of MCP servers, keeping tools and context consistent. If every agent had its own scattered tools, results would drift apart; on a shared MCP layer, the state a backend agent produces is picked up by a frontend agent through the same tools.

Everything also runs locally, so sensitive data never leaves your machine. Use stdio-based local servers and an agent fleet collaborates while source code and data stay on your machine. Paired with the BYO-model structure, this is especially valuable in environments where compliance and security are sensitive.

Next steps

Once the MCP picture is clear, there are two paths forward. One is orchestration — assigning roles across several agents, where backend, frontend, and test agents mesh on top of a shared MCP layer. The other is building your own MCP server to expose internal tools — wrap your team's tools once and every agent uses them immediately. To start, paste the filesystem example above as-is and watch, with your own eyes, the round-trip of an agent calling a tool.