Shadowing Practice: Demystifying MCP | Architect Insights - Learn English Speaking with Video

בחר מצב תרגול

כל מצב פותח חדר תרגול במסך מלא.

128 משפטים

אם המשפטים קצרים או ארוכים מדי, לחץ על ערוך כדי להתאים אותם.

Hi, I'm Scott Reila, Principal Architect Evangelist at Salesforce.

In this episode of Architect Insights, we're going to be exploring Model Context Protocol, or MCP.

Often called the USBC for AI, MCP is an open standard revolutionizing how AI agents dynamically connect to external tools and data.

Today, we will unpack how it works, examine the architectural trade-offs, and discuss why this new protocol complements your standard APIs.

Let's get started.

Before we dive in, please note that we may be discussing some forward-looking products and features today.

Please make all purchasing decisions based on what is currently available.

There are two types of MCP interactions at Salesforce.

On the left side, we have Agent Force acting as a client.

These are Agent Force agents

that need to connect to other external systems to get access to information like order status or inventory availability, or even to execute tasks based on the conversation.

On the right side, Salesforce acts as a server.

In this scenario, we have external or local agents that need to be able to use Salesforce data via Headless 360.

We'll be touching on both sides in our discussion today.

But before we go any further, we need to understand exactly what the model context protocol is.

MCP is the new open standard for connecting AI to outside tools and data.

It was introduced by Anthropic in November of 2024 to solve major integration bottlenecks.

Traditionally, if you wanted an agent to interact with a system, you would have to build custom skills or code API or SOC will calls for every single interaction.

MCP changes this by providing one unified connection standard, eliminating the need for those custom agent specific builds.

It allows AI models to consistently discover and use external features, and because it is open source, it works seamlessly across all AI providers.

MCP is often called the USBC for AI.

Just like you no longer want to carry around separate micro USB and Lightning cables,

MCP means we finally have a single unified configuration protocol for all of our AI agent integrations.

Now that we know the what, let's talk about how MCP actually works.

Let's start with the component view.

Looking at the left side of the screen, we have our hosts.

These could be chat interfaces like Claude or ChatGPT, code editors like VS Code or Claude Code or Cursor, or agents like AgentForce.

Each of these hosts has its own LLM connection and an embedded MCP client.

You can think of the host and the embedded client as sitting together as one unit for now.

In the middle, we have the MCP server.

The server handles the information discovery and setup, illustrating the different tools, resources, and prompts that are available to the host.

There are three types of interactions the MCP server provides.

First, we have tools, basically any callable code like APEX, API, whatever.

Tools are called dynamically by the agent.

For example, if I ask for an order status, the agent will gravitate towards an order status tool to make that call.

If there's no appropriate a tool, the LLM will tell me that it can't get the information, or worse, it may actually try to hallucinate the answer.

Guardrails are very important here.

Next are resources.

These represent data or files, and they are fundamentally different from tools because they are not directly callable by the agent.

To use the resource, the user must specifically mention it in their question, such as asking for a specific order using a manual pointer like at order 123.

Additionally, resources can handle notifications and follow-up information, which only trigger if the underlying system explicitly tells the MCP server that the resource was updated.

Lastly, we have prompts.

These are essentially just prompt templates.

It is critical to note that there is no LLM interaction on the MCP server side.

All LLM processing happens over on the host side.

Now that we know the components, let's discuss initialization.

Anytime you add a new mcp server

or start your agent an initialization step occurs exposing an mcp server without security is a bad idea even

if the data isn't highly sensitive like a weather app for

instance you absolutely must protect your server from denial of service attacks

if someone asks an open server for the weather in every

single us zip code it could easily crash your mcp server the admin or user

if local pre-configures the api key in the headers of the

host mcp json config file the host initiates the connection sending a request to the remote mcp server

while passing those authorization headers the server then validates the key

and if it is a valid api key the server successfully returns the tool list

and capabilities for the host to store we'll talk more about storage a little bit later

if the key is invalid

or missing the server immediately rejects the call with a 401 unauthorized

or a 403 forbidden error this step is essential

because it allows the mcp server to to identify exactly who is making the call, enabling the server to enforce strict rate limiting or resource throttling.

Now let's talk about user authentication, which is what Salesforce uses for Headless 360.

This one starts off the same way, where the user or admin configures their host.

Looking at step one, the initial connection attempt goes from the client host to the remote MCP server.

However, it returns a 401 unauthorized, which prompts the host to fire up a browser and go to the token URL.

This takes us to step two where the user logs in through a PKCE or Pixie challenge.

Once the user authenticates, Salesforce uses the external app to grant your scopes and determine which MCP servers your user can access.

Moving down to step three, the code is exchanged for a bearer and access token.

The host connects the user using that bearer token, And as long as the user has the right scopes,

the server returns the tool list and capabilities that the user is allowed to access.

As you can see, this is a little bit more involved.

But this is exactly where we start talking about why it is so important to know who the user is.

Every user in Salesforce has different permissions and capabilities.

And in this OAuth flow, it ensures that our agent

and our chat client can only execute what is specifically available to

that user and only access the MCP servers that are enabled.

Now that the MCP is initialized, let's talk about the actual tool invocation.

Let's say a user asks a question like, what's the humidity level in Chicago?

Starting on step one of the diagram, the host app sends the user's prompt alongside a list of available tools stored in the host to the LLM.

This is a critical detail depending on how many MCP servers you have connected.

The first call can consume a massive amount of your context window

because every single associated tool is sent to the LLM with the question in context.

The LLM then evaluates the tool descriptions to decide which one to call.

Once the tool is selected, like get current weather, we move to step two.

The host sends the tool call request, including inferred arguments like the Chicago zip code, to the MCP server.

The server executes the action with the external system and then returns the raw data back to the host.

Finally, in step three, the host passes the original question alongside that raw tool result back to the LLM.

The LLM extracts the specific data, like finding the 76% humidity from a large block of data, and generates the final natural language response for the user.

Notice the token burn happening here.

We are making multiple LLM calls per interaction, consuming tokens during both the tool selection phase and the final answer generation phase,

which is why managing your context window is very important.

Now that we have an idea of what MCP call looks like, let's check out a quick demo.

I have an MCP server for weather connected right here.

When I initialize my connection, look at the list of tools that populate.

We have get current weather, get weather conditions, get current air quality, and so on.

Notice that there isn't a tool in this list that explicitly mentions humidity levels.

This means the LLM actually has to go through each of the tool descriptions to understand

which one is the best fit for our question.

In this case, it decides get current weather is the best call.

100

Now let's look at the contract happening under the covers.

101

You can see the tool is looking for a location parameter, like Chicago.

102

When we run this, it goes out to the external system and returns an answer, but it doesn't just return a clean 53%.

103

Look at this large blob of data right here.

104

This is the entire result set that gets passed back to the LLM.

105

If I scan through it, I can see the humidity level is 53%, buried right here.

106

In order for the LLM to give that simple answer, the LLM has to process this entire raw result set alongside the user's original question and context.

107

This is where more token burn happens.

108

You are consuming a large amount of tokens based on the

109

sizable tool result just to extract one specific data point and generate a final natural language answer.

110

For an agent interaction, this is necessary to give the exact answer.

111

Is the same level of processing and token burn needed for a system-to-system integration?

112

Based on this analysis, we need to understand each use case and determine if MCP or API should be used.

113

Let's take a look at a side-by-side comparison of why both exist.

114

Looking at the left side, APIs are built for integration.

115

They rely on programmatic code and deterministic contracts.

116

Because there is no LLM interpreting the request or response, there is zero token cost and the data structure is strict and static.

117

Now looking at the right side, MCP is built for interaction.

118

It relies on the probabilistic reasoning of an LLM, which as we saw in the demo, consumes tokens to select a tool and generate the final answer.

119

However, MCP has dynamic discovery.

120

If you add a new tool to your server, the agent knows it exists after the next initialization

121

and how to use it without you having to build out custom agent-specific integrations.

122

For AgentForce, this is slightly different because the admin has to enable each of the tools for security reasons.

123

For system-to-system integrations, APIs remain as the go-to standard due to their deterministic nature and strict processing on the client side.

124

However, if natural language processing or additional reasoning is needed, like in an agentic interaction, then MCP would be desirable.

125

Ultimately, MCP is a powerful standard that complements your APIs.

126

It does not replace them.

127

By understanding the strengths and limitations of both, you can build smarter agentic interactions while maintaining the reliability of your system to system integrations.

128

Thanks for watching and see you next time.

הורד אפליקציה

כל מה שאתה צריך כדי לדבר בשטף

הגיית AIציון לכל משפט

תרגול IPAשלוט בכל צליל

אוצר מיליםבנה את מאגר המילים שלך

משחק אוצר מיליםלמד תוך כדי משחק

סרוק QR

Download on theApp Store Get it onGoogle Play

FOR YOU

המלץ על סרטון

497 משפטים

Technical deep dive on Managed Instance for App Service | BRK102

Daily ConversationWorking Adults

392 משפטים

Ultimate Claude Guide: How to Use Claude AI for Beginners in 2026

Daily ConversationWorking Adults

364 משפטים

Running AI Agents in Secure Sandboxes with E2B & Docker MCP | Docker’s AI Guide to the Galaxy

Daily ConversationUniversity StudentsWorking Adults

114 משפטים

אוצר מילים והערות הגייה לשיעור הזה

שיעור הדיבור הזה ברמה C1 מבוסס על הסרטון “Demystifying MCP”. המילים שחוזרות הכי הרבה: mcp, server, tool, host, agent. בסרטון הזה יש 128 משפטים ו-1875 מילים לתרגול Shadowing. הדיבור נמשך 10:19. הדובר מדבר מהר, כ-182 מילים בדקה, אז צפו לצלילים מחוברים ומקוצרים. רק 79% מהמילים נמצאות בין 3,000 המילים הנפוצות ביותר באנגלית, כך שאוצר המילים מאתגר.

אוצר מילים מרכזי בסרטון הזה

15 המילים המתקדמות ביותר בסרטון, עם ההגייה והמשמעות שלהן:

מילה	הגייה	משמעות
token שם עצם	/ˈtoʊkən/	אֲסִימוֹן, זִ׳יטוֹן
humidity שם עצם	/hjuːˈmɪd.ə.ti/	לַחוּת
consume פועל	/kənˈsum/	צרך
execute פועל	/ˈɛksɪˌkjuːt/	להוציא להרוג
embed פועל	/ɪmˈbɛd/	לְשַׁבֵּץ
initialize פועל	/ɪˈnɪʃəlaɪz/	אִתְחֵל
extract שם עצם	/ˈɛkstɹækt/	תַּמְצִית
demo שם עצם	/ˈdɛm.oʊ/	דמו
throttle שם עצם	/ˈθɹɔ.tl̩/	מַשְׁנֵק, מַצְעֶֽרֶת
forbid פועל	/fɚˈbɪd/	אָסַר
template שם עצם	/ˈtɛm.plɪt/	תַּבְנִית, שַׁבְּלוֹנָה
illustrate פועל	/ˈɪl.əˌstɹeɪt/	הִמְחִישׁ
authorization שם עצם	/ˌɔːθəɹaɪˈzeɪʃən/	הַסְמָכָה
fundamentally תואר הפועל		עֶקְרוֹנִית
microwave שם עצם	/ˈmaɪkɹoʊˌweɪv/	מִיקְרוֹגַל

Phrasal verbs שתשמעו

מילה	משמעות
check out פועל	בדק

הגייה ששווה לשים לב אליה

הדובר משתמש ב-8 קיצורים וצורות מקוצרות, כמו isn't, we'll, can't. אמרו אותם בצורה הקצרה, כפי שאתם שומעים אותם.

הצלילים של “th”: authenticate /ɔˈθɛn.tɪ.keɪt/, authentication /ɔːˌθɛntɪˈkeɪʃn̩/, throttle /ˈθɹɔ.tl̩/, authorization /ˌɔːθəɹaɪˈzeɪʃən/
הצלילים של “sh” ו-“zh”: initialize /ɪˈnɪʃəlaɪz/, authentication /ɔːˌθɛntɪˈkeɪʃn̩/, invocation /ˌɪn.voʊˈkeɪ.ʃən/, revolutionize /ˌɹɛv.əˈl(j)u.ʃəˌnaɪz/, limitation /lɪmɪˈteɪʃən/
מילים ארוכות — שימו לב להטעמה: humidity /hjuːˈmɪd.ə.ti/, capability /ˌkeɪ.pəˈbɪl.ɪ.ti/, deterministic /dɪˌtɜː.mɪˈnɪs.tɪk/, initialize /ɪˈnɪʃəlaɪz/, authenticate /ɔˈθɛn.tɪ.keɪt/

צלילים שדוברי עברית מתקשים בהם:

/æ/ — פתוח יותר מה-“אֶ” העברית, לא כמו “a” ב-“cup”: admin /ˈædˌmɪn/, extract /ˈɛkstɹækt/, gravitate /ˈɡɹævɪteɪt/, programmatic /ˌpɹəʊ.ɡɹəˈmæt.ɪk/, unpack /ʌnˈpæk/
/r/ — הלשון לא נוגעת בשום מקום, לא ה-“ר” הגרונית: prompt /pɹɑmpt/, bearer /ˈbeɹɚ/, configure /kənˈfɪɡə(ɹ)/, extract /ˈɛkstɹækt/, gravitate /ˈɡɹævɪteɪt/
עיצור קולי בסוף מילה — /b/, /d/, /g/, /z/, /v/ בלי להפוך אותם לאטומים: embed /ɪmˈbɛd/, initialize /ɪˈnɪʃəlaɪz/, config /ˌkənˈfɪɡ/, revolutionize /ˌɹɛv.əˈl(j)u.ʃəˌnaɪz/, forbid /fɚˈbɪd/

איך לתרגל עם הסרטון הזה

הקשיבו לכל הסרטון פעם אחת בלי לדבר, ורשמו את המילים שאתם לא מכירים.
התחילו במהירות 0.75×, תרגלו Shadowing משפט אחר משפט, וחזרו למהירות רגילה כשזה מרגיש קל.
הקליטו את עצמכם והשוו למקור, תוך תשומת לב למילים כמו token, humidity, consume.

מהי טכניקת השאדואינג?

שאדואינג היא טכניקת למידת שפה מבוססת מדע שפותחה במקור להכשרת מתורגמנים מקצועיים ופופולרית על ידי הפוליגלוט ד"ר אלכסנדר ארגואלס. השיטה פשוטה אך עוצמתית: אתה מקשיב לאודיו באנגלית ילידית וחוזר עליו בקול רם מיד — כמו צל העוקב אחרי הדובר עם עיכוב של 1–2 שניות בלבד. בניגוד להאזנה פסיבית או תרגילי דקדוק, שאדואינג מכריח את המוח והשרירים בפה לעבד ולשחזר דפוסי דיבור אמיתיים בו זמנית. מחקרים מראים שזה משפר משמעותית את דיוק ההגייה, האינטונציה, הקצב, הדיבור המחובר, הבנת השמיעה ושטף הדיבור — מה שהופך אותו לאחת השיטות היעילות ביותר להכנה לIELTS Speaking ולתקשורת באנגלית בעולם האמיתי.

טכניקת Shadowing: קרא את המדריך המלא שלב אחר שלב →

Shadowing Practice: Demystifying MCP | Architect Insights - Learn English Speaking with Video

בחר מצב תרגול

הורד אפליקציה

Technical deep dive on Managed Instance for App Service | BRK102

Ultimate Claude Guide: How to Use Claude AI for Beginners in 2026

Running AI Agents in Secure Sandboxes with E2B & Docker MCP | Docker’s AI Guide to the Galaxy

Harnessing generative AI in architecture, engineering & construction

CAP Theorem Simplified

Trust the Process: How to Design Teams That Actually Work

十年後的電腦會長什麼樣？黃仁勳：就像今天的手機，最少拿來打電話｜中英字幕

MCP vs API: The protocol every developer needs to know

Agentic AI Frameworks Explained: Workflows, Multi-Agent, & Production

Why Coding Agents Keep Making Your Codebase Worse

What is NLP? Neuro Linguistic Programming

BGP Overview