Why Model Context Protocol is Key for AI Growth

Full video transcript

Model context protocol is an open protocol that enables seamless integration between AI apps or agents and your tools and data sources — it’s what allows us to be able to start connecting our own data into our interactions with our large language models. Roger Campbell II, founder of GemStack and co-founder of the AI Business Foundry, walked through what MCP is and why it matters, noting it had only been out for about four months at the time of the talk.

At GemStack, Roger works with companies in a fractional capacity to figure out their AI strategy, and from there has helped many of them with team enablement and upskilling — whether using existing tools or building custom solutions. He has spent 15 years as a technologist across education, software engineering, blockchain, and machine learning, including work with companies like Amazon and Microsoft.

The stated goals for the session were threefold: show real MCP demos (in Cursor and in a custom-built application), explain what MCP is as a protocol and how it’s used, and answer questions throughout — with an explicit note that the goal was not to make everyone an “MCP champion” walking away ready to implement everything, but to provide a foundational understanding so people could continue learning. This was not framed as a step-by-step tutorial for building an MCP server.

To set up the problem MCP solves, Roger described the basic interaction with a large language model as very linear: a prompt goes in, the model draws on its training, and a response comes back — similar to writing a report purely from memory. Adding web search lets the model go find information first, similar to picking up a textbook or searching online before writing. The real friction shows up with personal data: emails, Notion, Slack, Teams, TikTok, Instagram. Getting a model to act on that data typically means what Roger called the “copy and paste workflow” — copying an email into ChatGPT, having it rewritten, copying the response back into the email client, realizing it needs edits, and repeating the loop. Some connectivity was starting to appear (Claude connecting directly to Google Drive, ChatGPT accessing other tools), but the underlying problem — RAG-style workarounds, agent architectures bolted on — remained largely unsolved.

Before demoing, Roger explained the word “protocol” itself: a predetermined way of sending and receiving information, the same way a polite conversation follows an expected back-and-forth. MCP, in that frame, is an open protocol that gives AI tools and data sources a shared, predictable way to exchange information.

The first demo used Cursor, an IDE that also supports installing MCP servers, running Claude 3.7 Sonnet as the model. With a file system MCP server installed, Roger asked it to create a text file with a haiku about “my first MCP server.” The model attempted to write to a directory it didn’t have permission for, got a denied-path error, then used a “list allowed directories” function to find where it could write, and completed the task in the downloads folder — all visible to Roger as it happened. He then asked it to read a marketing document already in that folder and summarize it, which it did by searching for the file, reading it, and generating the summary. As a further step, he asked it to turn that summary into a full landing page (HTML and CSS), which it built and saved to the same folder while he took audience questions.

A participant, Omar, asked how this scales down to a small business without dedicated technical staff, rather than an enterprise. Roger acknowledged the file-system demo was on the geekier end, but pointed to the next demo — Slack — as showing an already-built, open-source integration anyone could install without engineering it themselves. He emphasized that MCP’s value for small teams is less about building servers and more about being aware of which pre-built ones fit a given need.

In the Slack demo, Cursor was connected to Roger’s Slack workspace. He asked it to list the Slack channels it had access to, which it did by calling a “list channels” function. He then asked it to tag a specific teammate, Chelsea, in a message letting her know a new landing page had been created, and the model posted that message in real time. Roger framed this as a preview of a broader pattern: getting off a call, having the model turn a transcript into a marketing report, and having it Slack that report to teammates automatically.

A follow-up question asked how much of this can run automatically versus requiring manual approval at each step. Roger explained that in this Cursor environment he was deliberately keeping the interactions manual — approving each tool call — so the audience could see the underlying mechanics: searching a file directory, checking channel access, finding a person, sending a message. He noted that MCP does not require this level of manual interaction; it can be made much more autonomous depending on how it’s implemented.

A participant compared MCP to TCP/IP for LLM-to-app communication, which Roger confirmed as broadly accurate — MCP gives large language models a standard way to talk to external apps and databases, similar to how a computer uses HTTP to talk to the internet. Another participant, working in brand strategy, described a use case of taking call transcripts and having a model extract and structure the standard fields of a brand guide, then generate a PDF automatically — Roger confirmed this is exactly the kind of connector-based workflow MCP is meant to make easier, and noted that a large share of needed servers already exist as open source rather than requiring custom builds.

Roger then explained MCP’s architecture more formally: a host or client (Cursor, Claude desktop, Windsurf, or a custom application) connects to a large language model and can use installed MCP servers to do work. The server is the installable piece — built by someone else, in most cases — that connects the client to a specific data source or tool, whether that’s a file system, Slack, Gmail, Asana, Jira, or GitHub. At a high level, an MCP client invokes tools, queries for results, and can insert preconfigured prompts; the server is what makes those tools, that data, and those prompts available in the first place.

The final demo used a small custom-built chatbot application connected to Gmail. Roger asked it to review all unread emails and sort them into high, medium, and low priority, giving the sender, subject, a brief overview, and a priority rating for each. The model processed the inbox and returned a prioritized breakdown in real time. He noted this same workflow could be scheduled to run automatically on a recurring basis rather than triggered manually. He then asked the model to draft replies to the two most urgent messages, which it did, ready for review before sending.

A participant asked how this compares to using HTTP connections in Make or n8n. Roger explained MCP doesn’t necessarily remove those tools from the picture — an MCP server could be built to call a Make or n8n webhook, letting a workflow kick off from inside Claude desktop rather than requiring you to leave the chat interface. He was clear that MCP does not currently work with ChatGPT, since OpenAI has not enabled the protocol, so this pattern currently requires Claude or another MCP-compatible client.

Asked whether MCP servers will eventually replace APIs and webhooks, Roger said he didn’t think so — Anthropic’s own stated goal is not to replace backend development, but to give large language models an easier way to call into existing APIs. He used the Asana MCP server as an example: out of the box it can list workspaces, search for projects and tasks, and create tickets, meaning a model could take a call transcript, extract what belongs in a new ticket, and — after approval — write it directly to Asana. He estimated that what might have previously cost $50,000 to $200,000 in custom integration work is now often available as a simple install.

On security, Roger flagged that because MCP is open source, there are real concerns worth taking seriously, and he does not recommend installing servers indiscriminately — platforms like Goose are starting to make available options somewhat safer to use. Asked whether apps like Make will start connecting to external sources via MCP instead of APIs, Roger said he sees a mixed future: some workflows may move entirely into an MCP-driven client, while others will still need Make or a similar layer for more complex connections, with MCP potentially meeting that layer partway.

Roger also mentioned that Anthropic has published a tutorial for using Claude itself to build MCP servers, which he had used personally to create one. As an aside, he described a personal project using a web-scraping tool (referenced as “Crawl for AI”) that turns any webpage into markdown a model can read — built by prompting Claude rather than hand-writing the scraper — as a way to get around inconsistent results when asking a model to read documentation pages directly.

Closing out, Roger’s recommendation for anyone getting started was to begin with the official Model Context Protocol documentation, then move to YouTube for more in-depth tutorials, and to choose whichever client environment (Claude desktop, Cursor, or otherwise) they were already most comfortable in — noting that Cursor, as an IDE for writing code, is likely not the best starting point for a non-technical user, and that ChatGPT is not currently an option since the protocol isn’t supported there.