Model Context Protocol (MCP)

Before a protocol existed, every combination of assistant and data source needed its own connector: one integration for this IDE and that ticket tracker, another for a different assistant and the same tracker. MCP inverts that by making the data source expose a standard server. The server advertises tools (functions the model may call), resources (content the client may read into context) and prompts (reusable templates), and the client handles discovery, invocation and the plumbing of results back into the model’s context.

The value shows up when the number of integrations grows. Building one server for your internal knowledge base makes it available to every MCP-capable client at once, and swapping the model or the assistant does not invalidate the connector. Transports cover both local processes over standard input and output and remote servers over HTTP, so the same interface works for a developer’s laptop and a hosted deployment.

The security implication is the part most often skipped. A protocol that makes it easy to attach tools also makes it easy to attach the wrong ones. Content returned by an MCP resource is untrusted input that lands directly in the model’s context, which is exactly the channel an indirect prompt injection travels through. Servers should scope credentials narrowly, actions with side effects should be distinguishable from reads, and a client that can install servers should treat that as a supply-chain decision, not a configuration tweak.