explore

Footprints

Open the places and fragments left along the way

construction

Tools

A growing place for small tools and experiments

code

Open Source

Sharing and documenting excellent open source projects worth following

person

About

Learn who I am and what this site keeps circling back to

Theme

Switch to a reading atmosphere that fits the moment

Language

Switch the language of articles and moments

Recent Status

Last weekend, I spent two days driving 2,000 kilometers from Zhengzhou to Mudanjiang, Heilongjiang. Driving a Tesla Model Y 2023 Long Range…

Tech1 views

Tool Overload: The Pain Points of Vercel AI SDK's Tool-Only Architecture

AIMCP

In the previous article, we have already achieved: you write a few tool(...), wrap functions like checking time and weather, and then the model can automatically invoke these capabilities.

With just this one trick, you can already make quite a few practical small things: internal customer service assistants, knowledge base Q&A, and AI mini-features in SaaS.

Then the question arises: What happens if you keep going?

At this point, relying solely on the 'Vercel AI SDK Tool' layer starts to become difficult. In this article, we won't rush into MCP; instead, we'll clearly lay out the problems that the 'pure Tool architecture' will encounter.

1. Review: The ideal world of only Tool

First, a quick review of the 'previous episode' model:

From an architecture diagram perspective, it looks roughly like this flat structure:

User → Next.js API Route → Vercel AI SDK → Model Model ←→ Tool (encapsulates your business functions)

Everything is in one project:

For a 'single application, single team' project, this is very comfortable:

2. First layer of complexity: maintenance pressure from the surge in the number of tools

Let's first not introduce 'multiple applications' or 'multiple hosts'; just look within the same project.

2.1 From 'a few tools' to 'a bunch of tools'

Imagine you are building a backend operations assistant, roughly with these Tools:

Each Tool itself is not complex, but together they amount to dozens of files:

In the short term, this is not a problem; the Tool is your project's 'AI layer API gateway'.

2.2 Code starts to exhibit three types of 'duplication and fragmentation'

As the number of tools grows, three subtle problems emerge:

  1. Same business capabilities are repeatedly encapsulated

    • Your old backend already has a set of 'business APIs', and now you wrap them again at the Tool layer.

    • If other projects also need these capabilities, they have to wrap them again (in their own Tools).

  2. Types and validation rules are scattered

    • Originally, domain models (orders, tickets, users) already have types and validation in the backend.

    • The Tool layer writes JSON Schema / Zod again, making it easy for 'not updated together' issues to occur one day.

  3. Permission logic is scattered across multiple Tools

    • You might do checks like 'does the current user have permission to operate this order' in each Tool's execute function.

    • This seems correct, but when dozens of Tools do similar checks, it becomes very difficult to globally tighten or relax a certain permission.

At this stage, the pure Tool architecture can still fully hold up, but the maintenance experience starts to worsen. You will start to think: Can we make the 'tool layer' into a more independent, reusable thing, instead of being tightly bound within this project?

This is the first small step towards MCP, but we are not in a hurry yet.

3. Second layer of complexity: the calling environment goes from one to multiple

Take one step further: tools are not only used by your current web application, but also want to be used by other hosts.

3.1 Typical scenarios of multiple hosts

You may have such a combination of needs:

The common point of these three hosts is: they all want to call the same set of business capabilities.

If you only use Vercel AI SDK's Tool, each host will likely do the same things:

In the long run, this will become a typical 'bunch of isolated islands':

3.2 This is actually a 'missing protocol layer' problem

Note, this problem has gone beyond 'how good a certain SDK is'; it's more like:

Does our company have a 'unified AI tool access layer'? Or does each project build its own?

One thing Vercel AI SDK does very well is: it unifies different vendor interfaces for you in the 'model invocation' segment. But it is not responsible for answering 'how tools are exposed externally and how they are shared by different hosts', which is precisely where protocols like MCP have room to play.

4. Third layer of complexity: cross-team collaboration and external publishing

Going up another dimension, you are no longer just 'internal reuse', but you want to publish tools as a 'product'.

4.1 What you want becomes a 'tool platform'

For example, your team develops a set of very useful tools:

You will start to have these demands:

At this point, 'just writing some Vercel AI SDK Tools' is no longer enough:

The Model Context Protocol (MCP) proposed by Anthropic works at this layer:

You can think of it as:

5. From the AI SDK perspective, what exactly are the 'boundaries'?

Going back to the specific product of Vercel AI SDK, combining official documentation and community discussions, we can summarize the boundaries/pain points of 'relying only on Tool' into several categories.

5.1 The scope of Tool is mainly 'inside the application'

The official positioning of AI SDK is: help you quickly build AI applications and Agents in environments like Next.js and Node.js. Its Tool abstraction is mainly designed around this goal:

But it is not an 'external standard':

5.2 From an ecosystem perspective: each SDK has its own Tool abstraction

Not only Vercel AI SDK, but LangChain, LlamaIndex, and various self-developed Agent frameworks all have their own way of 'tool definition'.

If you only stay at the SDK layer (including AI SDK's Tool), you will find that:

This is the problem that protocols like MCP try to solve: making tools a 'common language' that can cross frameworks, products, and companies.

5.3 Some practical feedback: when the project becomes complex, you will build a layer of 'platform' yourself

There are already many developers in the community who heavily use Vercel AI SDK discussing:

This is essentially a 'protocolization' trend: It's just that this protocol currently stays at the level 'inside your organization', while MCP opens it up as an ecosystem-level standard.

6. Looking at MCP from the Tool perspective: what exactly are we missing?

We can use a very practical analogy to summarize the previous discussion.

From the perspective of Vercel AI SDK Tool:

The two are not conflicting, just at different levels:

7. Laying the groundwork for the next article: How will we use MCP?

In this article, we deliberately did not dive into the technical details of MCP; we only explained its motivation from the perspective of 'what happens when you push Tool to its limits':

In the next article, we will focus on MCP itself:

SHARE

Share

Share this article.

𝕏Xr/RedditfFacebook@ThreadsinLinkedIn