An AI application becomes useful when it can reach other systems: read a ticket, query a database, post a message. Without a shared standard, every application connects to every system by hand. Five applications and ten systems (GitHub, Slack, Postgres, Jira...) can add up to fifty separate integrations, each with its own format, login and bugs.

The Model Context Protocol () is a shared standard for those connections. This lesson covers what MCP standardizes, what it deliberately leaves to you, and how to use it in both directions, consuming other systems' tools and exposing your own, without giving up the control built in Tool calling and harnesses.

What MCP standardizes

Think of a universal plug: once every device and socket share one shape, you stop needing an for each pair. MCP plays that role for AI applications and the systems they use. Each side implements the protocol once, so five applications and ten systems need fifteen implementations, not fifty. LSP, the standard that lets any code editor support any programming language, works the same way.

There are three parts, and the diagram shows how they connect:

Hosteditor, agent or chat; holds the model
- Model
- Host logic
Clientsinside the host, one connection per server
Serverseach one offers one system's capabilities
- GitHub
- Files
- Postgres

The host talks to each server through its own client. Every server speaks the same protocol, so adding a system means adding a server, not rewriting the host.

The host is the application that holds the model and makes decisions.
A client is the piece inside the host that keeps a connection to one server.
A server is a program that offers capabilities from some system.

A server can offer tools (actions the model can ask to run), resources (data the application can read, such as a file) and (reusable message templates a user can pick). When a client connects, it asks the server for its list of tools, and each one comes with a name, a description and the shape of its arguments: exactly what the model needs to decide when to use it. The server can run as a local program the host starts on the same machine, or as a remote service over the web.

What it leaves to you

MCP solves connection, not trust. For remote servers, it defines how a client logs in and gets permission to talk to the server. That answers "may this application talk to this server?". It does not answer "should this agent make this call, with these arguments, right now?". That decision still belongs to the host.

Connecting a server means letting someone else's work in at three levels:

Code: a local server is a program running on your machine, with your permissions.
Text the model reads: tool descriptions and tool results both enter the model's context, and both can carry hidden instructions (see Sandboxing and agent security).
Actions: tools act on real systems, often with your credentials.

Question	Weak answer	Better answer
Who decides how risky a tool is?	"the server says it is read-only"	the host; unknown means risky
Who decides whether a call may run?	the server	the host, by its own rules, on every call
Who records the action?	the server, if it wants to	the host, before running it
Who holds the credentials?	the model or the prompt	the server or a proxy, with the least access needed

Using other systems' tools without giving up control

The safe pattern is simple to state: a tool that arrives over MCP goes through the same single checkpoint as your own tools, where permissions are checked and the call is recorded. MCP is only the delivery route.

How docket answers the questions in the table:

Names: remote tools get a prefix chosen by the operator, never by the server, so they cannot pose as built-in tools or replace one that exists.
Screening: each tool's name and description pass through the same rules as other untrusted input, and a tool that fails is not added.
Risk: since nothing proves a remote tool only reads, every one is treated as able to change things. A role without write access gets no MCP tools at all.
Isolation: each exchange with a local server runs in a fresh process with a time limit. A failing server is skipped and logged without breaking the agent's turn.

In docket

Server's tool listwhatever the server offers
Renamed and screenedprefix chosen by the operator
Narrowed by roleno write access, no remote tools
Checkpointrules, approval and audit on every call
Fresh processone exchange, with a time limit

A remote tool passes the same gates as a built-in one before it can run. MCP only carries it to the door. Source: DOCKET Architecture · Command reference

The limits, stated plainly: a read-only role cannot use even a harmless documentation server; every configured server is restarted on every turn (the project measured roughly 0.6 seconds each), both listed in docket's README; and screening covers descriptions, not results. What a server returns enters the context unfiltered, so the defense lies in what the agent is allowed to do next.

Exposing your system over MCP

MCP also lets someone else's AI application drive your system. The rule does not change: the protocol is one more door to the same controls, not a shortcut around them.

In Tack

Tack's MCP server (MCP Server) never touches the database. Its tools call Tack's own web API, like the command line does, so the board's rules (which moves between columns are allowed, how many items a column may hold) apply to an agent exactly as to a person, and an agent cannot overwrite a person's edit made since it read the item. Administrative actions stay off it, such as registering a new (which returns a one-time secret) or resolving runs with an uncertain outcome. The stated limits: the server uses the command line's access , with no narrower permissions per tool, and the tools that run agents are newer than the published release, installing for now from the develop branch.

In Tack

Clientsall take the same route
- An agent, via MCP
- The command line
Web APIchecks the board's rules for everyone
Databaseonly the API writes to it

Tack's MCP server is one more client of the web API. The rules live in one place, so an agent cannot reach the data by a side door. Source: MCP Server

Putting it into practice

Decide who enforces the rules before connecting a server. If your application has no checkpoint of its own on every call, you are handing your security to each server's author.
Treat everything a server sends as untrusted, descriptions and results alike.
Give remote tools the least access that works, and default unknown tools to the risky category.
Before exposing your system, decide what stays off the protocol. Anything that returns secrets or makes operator decisions should be out of an agent's reach.

Go deeper

The docket and Tack documentation cover both directions in more detail:

Own the loop, rent the protocols (ADR 0002) records the decision behind docket's stance: it keeps the loop, the tool list and every gate, and uses MCP only to plug in tool servers.
Command reference lists, in its mcp section, the tools docket offers as a server and how an operator adds an outside server.
MCP Server covers Tack's server: why it runs as a local process instead of a web endpoint, every tool it offers, and which actions stay command-line only.

Key takeaways

MCP is a shared standard for how AI applications find and use tools, data and prompts offered by other systems.
It settles who may connect, not whether a specific action should run; that stays with the host.
An MCP server's descriptions and results are untrusted input.
Tools that arrive over MCP should go through the same checkpoint as your own.
An MCP server you expose should use the same checked paths as your other interfaces and leave administrative actions out.

Check yourself

What problem does MCP solve, and what problem does it leave open?

It solves connection: any application that speaks MCP can use any system that offers an MCP server, without a custom integration for each pair. It leaves open whether a specific call, with its arguments, should run; the host has to decide that on every call.

Why does docket treat every remote tool as one that can change things?

Because nothing proves a remote tool only reads. Assuming the risky case is the safe default: a role without write access simply receives none of them.

What stops an agent using Tack's MCP server from breaking the board's rules?

The server never writes to the database directly. It goes through the same web API as everyone else, and that API checks the board's rules for every client.