Definition

Model Context Protocol (MCP)

The Model Context Protocol is an open standard that lets AI assistants discover and invoke tools from external systems. It is the bridge that lets a CRM assistant query a lakehouse, place an ERP order, or run any sanctioned operation in another system.

Last updated

Definition

The Model Context Protocol (MCP) is an open protocol for connecting AI assistants to external tools and data sources. An MCP server advertises a set of tools, resources, and prompts that an MCP client (an AI assistant) can discover, invoke, and reason about. The protocol was published by Anthropic in late 2024 and has since become the de facto standard for AI tool-use across Claude, Cursor, OpenAI's responses API, and most AI-native enterprise products.

What MCP solves

Before MCP, every AI assistant integration was bespoke. To let an assistant query Snowflake, you wrote a custom plugin. To let it write to Salesforce, you wrote another. To let it read from your wiki, a third. Every assistant ecosystem (ChatGPT plugins, Anthropic tools, Cursor commands) had its own format, its own auth model, its own discovery surface.

MCP collapses this into one protocol. A single MCP server speaks to any MCP client. A single MCP client (an assistant) can wire up to many MCP servers without per-server code.

The analogy that gets used is "USB for AI": the protocol is the connector, the servers are the peripherals, and the assistants are the devices. Once you ship an MCP server, you are addressable by every conforming assistant.

What an MCP server exposes

An MCP server publishes three kinds of capability:

  • Tools. Functions the assistant can call with structured arguments. Each tool has a name, a description, and a JSON schema for its parameters. Example: query_databricks that takes a SQL string and returns rows.
  • Resources. Read-only data the assistant can reference by URI. Example: a document, a record, a file from an internal wiki.
  • Prompts. Pre-built prompt templates the user can pick from. Less common, mostly used for guided workflows.

The protocol is transport-agnostic. Servers can speak over stdio (the common pattern for local servers), HTTP / SSE (for hosted servers), or WebSocket.

How Factory Labs uses MCP

Factory Labs uses MCP in both directions:

  • As a client. The Factory Assistant connects to external MCP servers (Databricks Genie, Snowflake Snowpark, customer-specific internal tools) so the assistant can query lakehouse data and other systems on demand. See /docs/lakehouse/mcp-bridge.
  • As a server. Factory Labs exposes its own MCP server, so Claude, Cursor, Mosaic AI agents, or any conforming MCP client can drive the CRM with the same tool surface and guardrails as a logged-in user.

The bidirectional pattern is why MCP matters operationally: the same CRM data is reachable by every AI surface you might use, without per-surface integration code.

Why MCP is structurally important

MCP shifts AI integration from "vendor-specific plugins" to "shared protocol." That has implications for B2B software architecture:

  • Vendor lock-in shrinks. Switching AI assistants no longer means rewriting integrations.
  • Tool surfaces become reusable. A well-built MCP server is useful across every AI ecosystem.
  • The lakehouse and the CRM become peers. Either system can be the client or the server; the protocol does not care.

For B2B distributors, this means the AI Assistant you pick (or build) is no longer a gating decision for the CRM. The CRM is reachable from any conforming surface.

  • Lakehouse-Native CRM. The architectural pattern that MCP makes practical.
  • Delta Sharing. The complementary outbound protocol for bulk data.
  • AI Assistant. The general term for the consumer side of MCP.

Further reading