跟读练习: MCP Just Got a Whole Lot Better - 通过视频学习英语口语

选择练习模式

每种模式都会打开全屏练习室。

61 句

如果句子过短或过长，请点击 Edit 进行调整。

MCP is blowing up right now.

Agents' usage of MCP is increasing exponentially and it's not showing any signs of slowing down.

But at the same time, many agents are now changing the way that they handle tools

and starting to take over responsibilities that used to belong to the server.

So what does all of this mean for the way that we build MCP servers?

Well, let's break it all down.

When MCP first hit the scene, one of the most common approaches for building MCP servers was

to just map each of your API endpoints to its own tool.

And by doing this, an agent was able to access the full range of your API surface area.

And this implementation worked, but it presented two major issues.

First, if your API had hundreds of endpoints, then that meant your MCP server had hundreds of tools.

And all of these tools would be loaded into the context window up front, meaning that before you even started your session, your context window could have been completely bloated by MCP tools.

And secondly, if you had lots of endpoints that were similar to each other, an agent might end up getting confused and not pick the right tool for the job.

In order to solve some of these problems, a lot of MCP servers adopted a layered tool call approach.

So now, instead of listing out hundreds of tool calls, you might just have two or three, You might have a tool to search all of the available endpoints,

a tool to inspect the definition of a specific endpoint, and a tool to execute the request.

This pattern has seen a lot of adoption, but this is now where the big change happens.

Traditionally, this pattern was implemented on the MCP server side.

But more recently, many MCP clients, especially many popular coding agents, are implementing this pattern on the client side.

The pattern is now called progressive tool discovery, and it's a recommended best practice for MCP clients.

In addition, a lot of these agents, like Codex or ClaudeCode, are implementing what's called programmatic tool calling, also known as code mode.

With code mode, instead of calling tools one at a time, the agent will go ahead and write a script that chains those tools together in a sandbox environment.

The script then runs in the sandbox, and then only the final result is returned back to the model.

Between progressive discovery handling tool call selection and then code mode handling tool composition,

the clients are now starting to take more ownership of the problems that servers originally were trying to solve.

So surely this means we can just go back to the

original method of doing a one-to-one mapping of API endpoints to tool calls, right?

Not quite.

While an agent certainly can accomplish everything it needs to just by having access to tools that represent every API endpoint,

that isn't necessarily always the most efficient way to interact with an API.

For any given API, there are often very common tasks or workflows that require stringing together multiple API calls.

And if an agent has to figure out that chain on its own every single time, that's a lot of wasted tokens.

And this is the same reason that SDKs exist.

They give you the raw endpoints but also bundle common workflows into single operations.

And we can apply that same idea to the tools that we expose through our MCP server.

So for example, with Neon, we have this idea of creating a branch.

But it turns out that creating a branch is actually three separate API calls under the hood.

You have to first create the branch itself, but then make a separate call to attach compute resources to the branch, and make a third call to get the connection string.

In the SDK, we bundle those three API calls into one method called createWithCompute.

So as this relates to our MCP server, in order to give MCP clients the most token-efficient path possible,

it's helpful to expose operations like this that they can take advantage of in some of these common use cases.

Of course, if your API is relatively simple and straightforward, a one-to-one mapping might be totally fine.

But for something like Neon, where there's some complexity in provisioning infrastructure,

these ergonomic shortcuts save the agent from making the same mistakes over and over again.

So at Neon, we have an SDK which is generated from from our open API spec.

So that way it covers every API endpoint.

But on top of that generated layer, we also have another thinner layer that adds the ergonomic methods that we were just talking about, things like create with compute.

From here, in order for this to be usable by agents, we need to convert all of these methods into tool calls.

So that's exactly what we did with a package that we call neon tools.

So that includes both the raw endpoints and the ergonomic workflows, all as tool calls.

And by virtue of pulling these tools out into a separate package, we're able to serve a few different use cases.

First and foremost, in the Neon MCP server, the server imports this package to surface all of these tools to any MCP client.

But on top of that, we can also take this package and build adapters around it for different agent frameworks.

So for example, we have adapters for both Mastra and Eve for anyone building custom agents with those frameworks.

And one more thing worth noting is that these tools are organized into categories, so that way you can scope down exactly which tools you want the agent to have access to.

All in all, the big idea here is that the server is controlling what tools are available,

but then the client handles discovering and executing those tools in whatever way it sees fit.

All of this is open source, so if you want to dive through the code and see exactly how everything is implemented, I'll have some links down in the description for you to check out.

ways that you're approaching building your own MCP server?

Let us know down in the comments.

Thank you so much for watching and I'll see you in the next one.

下载应用

流利口语所需的一切

AI 发音评分逐句打分

音标练习掌握每个音

词汇学习建立你的词库

词汇游戏边玩边学

扫码

Download on theApp Store Get it onGoogle Play

FOR YOU

本课的词汇与口语要点

这节 C1 级别的口语课以视频“MCP Just Got a Whole Lot Better”为素材。视频中反复出现的词有：tool, Mcp, agent, Api, server。这段视频共有 61 个句子、1064 个单词可供跟读。讲话部分时长为 5:55。说话人语速较快，每分钟约 180 个词，会出现较多连读和弱读。只有 81% 的单词属于英语最常用的 3,000 词，词汇难度较高。

视频中的重点词汇

视频中最难的 15 个单词，附发音和释义：

单词	发音	释义
endpoint 名词		端點 /端点
neon 名词	/ˈniˌɑn/	ne, 氖
workflow 名词	/ˈwɝkfloʊ/	工作流
compute 动词	/kəmˈpjuːt/	計算 /计算
sandbox 名词	/ˈsæn(d).bɑks/	砂箱
adapter 名词	/əˈdæptəɹ/	適配器 /适配器
token 名词	/ˈtoʊkən/	代幣 /代币, 籌碼 /筹码
bundle 名词	/ˈbʌn.dl̩/	捆, 包
execute 动词	/ˈɛksɪˌkjuːt/	處決 /处决, 處死 /处死
expose 动词	/ɪkˈspoʊz/	揭露, 暴露
exponentially 副词	/ɛkspə(ʊ)ˈnɛnʃəli/	指数地
shortcut 名词	/ˈʃɔːtkʌt/	捷徑 /捷径, 近路
usable 形容词	/ˈjuː.zə.bəl/	可用
inspect 动词	/ɪnˈspɛkt/	調查 /调查, 檢查 /检查
attach 动词	/əˈtæt͡ʃ/	附上, 附

视频中出现的短语动词

单词	发音	释义
blow up 动词		炸掉, 爆破
check out 动词		退房
end up 动词		到达
figure out 动词		弄清楚
go ahead 动词	/ˌɡoʊ əˈhɛd/	請便 /请便
slow down 动词		減速 /减速, 放慢
take over 动词		接管, 接手
turn out 动词		原來 /原来

需要注意的发音

说话人用了 5 次缩略和弱读形式，例如 I'll, isn't, we're。请按听到的简短形式来说。

“sh” 和 “zh” 音: exponentially /ɛkspə(ʊ)ˈnɛnʃəli/, shortcut /ˈʃɔːtkʌt/, speculation /ˌspɛk.jəˈleɪ.ʃən/, accomplish /əˈkɑm.plɪʃ/, traditionally /tɹəˈdɪʃ.ə.nə.li/
长单词——注意重音位置: exponentially /ɛkspə(ʊ)ˈnɛnʃəli/, programmatic /ˌpɹəʊ.ɡɹəˈmæt.ɪk/, speculation /ˌspɛk.jəˈleɪ.ʃən/, complexity /kəmˈplɛk.sɪ.ti/, traditionally /tɹəˈdɪʃ.ə.nə.li/

中文母语者容易读错的音：

词尾辅音 — 要读清楚，后面不要加元音: compute /kəmˈpjuːt/, sandbox /ˈsæn(d).bɑks/, execute /ˈɛksɪˌkjuːt/, expose /ɪkˈspoʊz/, programmatic /ˌpɹəʊ.ɡɹəˈmæt.ɪk/
/æ/ — 嘴张大，不要读成 /e/: sandbox /ˈsæn(d).bɑks/, adapter /əˈdæptəɹ/, programmatic /ˌpɹəʊ.ɡɹəˈmæt.ɪk/, attach /əˈtæt͡ʃ/, interact /ɪn.təˈɹækt/

如何用这段视频练习

先完整听一遍视频，不要开口，记下不认识的单词。
先用 0.75 倍速逐句跟读，熟练之后再回到正常速度。
录下自己的声音并与原声对比，特别注意 endpoint, neon, workflow 这类单词。

什么是跟读法？

跟读法 (Shadowing) 是一种有科学依据的语言学习技巧，最初开发用于专业口译员的培训，并由多语言者Alexander Arguelles博士普及。这个方法简单而强大：您在听英语母语原声的同时立即大声重复——就像是一个延迟1-2秒紧跟说话者的影子。与被动听力或语法练习不同，跟读法强迫您的大脑和口腔肌肉同时处理并模仿真实的讲话模式。研究表明它能显着提高发音准确性，语调，节奏，连读，听力理解和口语流利度——使其成为雅思口语备考和真实英语交流最有效的方法之一。

影子跟读法: 阅读完整分步指南 →

跟读练习: MCP Just Got a Whole Lot Better - 通过视频学习英语口语

选择练习模式

下载应用

推荐视频

MCP vs API: The protocol every developer needs to know

Claude Code: The Advanced Guide (99% of Devs Skip These Features)

Introducing the Agents API

Business Partner C1. Unit 1. Video 1.1.1.

I've Changed My Opinion On DEVELOPERS Vibe Coding

What Are Microservices Really All About? (And When Not To Use It)

Connect Slack to Salesforce with Hosted MCP Servers | Salesforce Headless 360 Decoded

Unreal Engine 5.8 - Experimental MCP Server Support Walkthrough | State of Unreal 2026

Easy Migration from Postgres to Databricks Lakebase

The mystery is solved... and the answer is 40x cheaper than Claude

CAP Theorem in System Design Interviews

Give Me 18 Minutes and I’ll Make you Dangerously Smart (with AI)