シャドーイング練習: 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発音採点文ごとに採点

IPA練習すべての音をマスター

単語学習自分の単語帳を作る

単語ゲーム遊びながら覚える

QRをスキャン

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です。話す速さは速く、1分あたり約180語です。音のつながりや弱く発音される音が多くなります。英語の頻出3,000語に含まれる単語は81%だけなので、語彙は難しめです。

この動画の重要語彙

動画の中で特に難しい単語15語を、発音と意味つきで紹介します。

単語	発音	意味
neon 名詞	/ˈniˌɑn/	ネオン
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/	晒す, 暴く
shortcut 名詞	/ˈʃɔːtkʌt/	近道
attach 動詞	/əˈtæt͡ʃ/	付ける, 添付する
straightforward 形容詞	/ˌstɹeɪtˈfɔː(ɹ)wə(ɹ)d/	率直, まっすぐ
secondly 副詞	/ˈsɛk.(ə)ndli/	第二に
virtue 名詞	/ˈvɝt͡ʃu/	力天使
organize 動詞	/ˈɔɹɡənaɪz/	組織する

動画に出てくる句動詞

単語	発音	意味
blow up 動詞		爆破する, 爆発する
check out 動詞		試験する, 検査する
go ahead 動詞	/ˌɡoʊ əˈhɛd/	どうぞお先に
slow down 動詞		遅らせる
take over 動詞		引き受ける

注意したい発音

話し手はI'll, isn't, we'reなど、短縮形や弱形を5回使っています。聞こえたとおりの短い形で発音しましょう。

「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/

日本語話者が苦手な音：

/f/ — 「フ」ではなく、上の歯と下唇で出す: workflow /ˈwɝkfloʊ/, foremost /ˈfɔː.məʊst/, straightforward /ˌstɹeɪtˈfɔː(ɹ)wə(ɹ)d/
子音の連続 — 間に母音を入れない: workflow /ˈwɝkfloʊ/, compute /kəmˈpjuːt/, sandbox /ˈsæn(d).bɑks/, bundle /ˈbʌn.dl̩/, expose /ɪkˈspoʊz/

この動画での練習方法

まず声を出さずに動画を最後まで聞き、知らない単語をメモします。
まず0.75倍速で一文ずつシャドーイングし、慣れてきたら通常の速度に戻します。
自分の声を録音して元の音声と比べます。neon, workflow, computeなどの単語に特に注意しましょう。

シャドーイングとは？英語上達に効果的な理由

シャドーイング（Shadowing）は、もともとプロの通訳者養成プログラムで開発された言語学習法で、多言語習得者として知られるDr. Alexander Arguelles によって広く普及されました。方法はシンプルですが非常に効果的：ネイティブスピーカーの英語を聞きながら、1〜2秒の遅延で声に出してすぐに繰り返す——まるで「影（shadow）」のように話者を追いかけます。文法ドリルや受動的なリスニングと異なり、シャドーイングは脳と口の筋肉が同時にリアルタイムで英語を処理・再現することを強制します。研究により、発音精度、抑揚、リズム、連音、リスニング力、そして会話の流暢さが大幅に向上することが確認されています。IELTSスピーキング対策や自然な英語コミュニケーションを目指す方に特におすすめです。

シャドーイングのやり方: ステップ別の完全ガイドを読む →

シャドーイング練習: 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

Wrote My Own Memory Allocator (and ran DOOM with It)

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