DEV Community: Seey

Why We Built MCPSDK

Seey — Mon, 09 Feb 2026 10:54:22 +0000

This isn’t a product launch announcement. We just want to share why we built this and how it might be useful to you.

A Recurring Problem

Over the past year, our team has been building AI Agent projects. And every time we start something new, we run into the same issue:

Integrating MCP Servers.

MCP itself is a great protocol. It allows AI systems to call external tools — which is essential if you want Agents to actually do things instead of just generating text.

But the integration process is almost always the same:

Find the server’s repository
Read the documentation and figure out the configuration
Write config files
Set up environment variables
Possibly spin up a Docker container
Deal with permission issues
Hope everything works

Integrating one server is manageable.

But when your Agent needs GitHub, Slack, Calendar, Email, and a database — all at once — the process quickly becomes painful.

Our Initial Solution

At first, we wrote internal scripts to simplify this workflow.

Over time, those scripts evolved into a small SDK.

The core question we kept asking ourselves was:

Can we reduce “integrating an MCP Server” to a single line of code?

Ideally, something like this:

const github = await mcpsdk.connect('github');

No config files.
No Docker management.
No permission juggling.

Just specify the server you want — and let the SDK handle the rest.

How It Works

Under the hood, MCPSDK does a few key things:

1. Unified Registry

We aggregate MCP Servers from multiple sources — official, community, and third-party.

Currently, there are 5000+ available servers accessible through a unified interface.

2. Cloud Sandbox Execution

Servers don’t run locally.

They run inside secure sandboxes built on Sandock.ai.

This eliminates:

Local environment inconsistencies
Permission conflicts
Manual process management
Security isolation headaches

3. Standardized Interface

No matter:

What language the underlying server is written in
How it’s configured internally
Where it’s hosted

The interface you call remains consistent.

From the developer’s perspective, everything feels uniform.

This Isn’t a Silver Bullet

We want to be honest about trade-offs.

This approach has limitations:

Latency — Cloud execution introduces network round trips. Not ideal for latency-sensitive workloads.
Cost — Sandbox execution isn’t free. High-frequency workloads must account for this.
Customization — Deep customization may still be easier with local deployment.

We’re not trying to replace local setups.

Instead, we’re offering a “quick start” path.

When you’re prototyping or validating an idea, you shouldn’t have to spend half a day configuring infrastructure.

Who Might Use This

From our experience, MCPSDK may be useful for:

Teams building AI Agents that need fast multi-service integration
Workflow automation products connecting multiple APIs
Developers experimenting with MCP who want to avoid configuration overhead

Want to Try It?

If this sounds relevant to what you’re building:

Visit https://mcpsdk.dev

Documentation: https://mcpsdk.dev/docs

You can also open an issue on GitHub or reach out via Discord.

We’re still iterating. Many features aren’t fully polished yet.

But if you're willing to try it — we’d genuinely love your feedback.

If you'd like, I can also produce:

A slightly more narrative / story-driven Medium version
A more technical version for Hacker News
A more opinionated version for X / LinkedIn
Or a sharper, punchier version optimized for engagement

Just tell me which direction you want.

MCPSDK vs Agentic

Seey — Fri, 06 Feb 2026 03:26:40 +0000

Comparing Agentic and MCPSDK MCP integration approaches and developer experience

Both Agentic and MCPSDK provide hosted MCP servers, eliminating the need to manage local processes. The core differences lie in curation approach, pricing model, and community contribution.

One-sentence summary: Agentic is a paid official curation (~20 tools), MCPSDK is an open-source registry with 7,800+ MCP Tools.

1. At a Glance

Dimension	Agentic	MCPSDK
Core Positioning	Hosted MCP Server + Paid Curated Tools	Hosted MCP Server + Open Registry API
Tool Count	~20 curated tools	7,800+ Tools
Tool Source	Official vetted `@agentic/*`	Open-source registry (GitHub PRs)
Pricing Model	Pay-per-call (with free tier)	Free to use, manage 3rd-party API keys
New Tool Availability	Added by official team	Added via community PR (open-source)
Integration Method	`AgenticToolClient.fromIdentifier()`	`toolSDK.package().tool()`
3rd-party API Keys	Managed by Agentic	Developer-configured in `package()`
Client Lifecycle	Auto-managed	Auto-managed
Tool Invocation	AI invocation only	AI invocation + Direct developer invocation
Multi-framework Support	Vercel AI SDK, LangChain, etc.	Vercel AI SDK, OpenAI SDK, etc.

2. Deep Dive

2.1 Agentic: Hosted MCP Server + Paid Curated Tools

Agentic provides hosted MCP servers (agentic.so) with approximately 20 curated tools, charged per-call.

Advantages:

☁️ No need to manage local processes (cloud-hosted)
🎯 High Tool Quality: All tools are hand-optimized by the Agentic team, carefully designed for LLM use cases ("Agentic UX")
📦 Unified Experience: Consistent API design style with a gentle learning curve
🔄 Automatic client lifecycle management
🌐 Multi-SDK Support: First-class support for Vercel AI SDK, OpenAI, LangChain, LlamaIndex, and other major frameworks

Architecture Characteristics:

💰 Paid Model: Pay-per-call pricing (includes 3 free calls for testing)
📚 Curation Strategy: ~20 official tools (@agentic/*), prioritizing quality over quantity
⏳ Centralized Management: New tools are reviewed and added by the official team
📦 100% Open Source: Core code is open-sourced on GitHub (TypeScript)

Vercel AI SDK Integration Code:

import { createAISDKTools } from '@agentic/ai-sdk'
import { AgenticToolClient } from '@agentic/platform-tool-client'
import { openai } from '@ai-sdk/openai'
import { generateText } from 'ai'

// Load tool from Agentic's standard library
const searchTool = await AgenticToolClient.fromIdentifier('@agentic/search')

const result = await generateText({
  model: openai('gpt-4o-mini'),
  tools: createAISDKTools(searchTool),
  prompt: 'What is the latest news about AI?'
})

Architecture Trade-offs:

🔒 Curated & Closed: Only ~20 officially vetted tools
💵 Pay-per-Call: Uses Stripe for per-call billing
🤖 AI Invocation Only: Tools must be invoked through AI SDK

2.2 MCPSDK: Hosted MCP Server + Open-Source Registry API

MCPSDK provides hosted MCP servers with access to the massive MCP ecosystem via its open-source registry.

Advantages:

🌐 Massive Ecosystem: Access to 7,800+ Tools
🆓 Free to use (manage your own 3rd-party API keys)
⚡ Unified API: Every tool is called via the same package().getAISDKTool() pattern
📦 Community Driven: New tools added daily via community GitHub PRs
🎮 Flexible Invocation: Supports both AI invocation and direct developer invocation
🔄 Automatic client lifecycle management

Architecture Characteristics:

⚡ All MCP Servers Always-On: No installation or startup needed, use on demand
🚀 Zero Cold Start: All MCP servers preloaded in cloud for instant response
🔌 Unified API Gateway: Access the entire registry through a single entry point

Vercel AI SDK Integration Code:

import { generateText } from 'ai';
import { openai } from '@ai-sdk/openai';
import { MCPSDKApiClient } from 'toolsdk/api';

// 1. Initialize MCPSDK
const toolSDK = new MCPSDKApiClient({ 
  apiKey: process.env.TOOLSDK_API_KEY 
});

// 2. Get tool (Uniform pattern: package -> tool)
const searchTool = await toolSDK
  .package('@mcpsdk.dev/tavily-mcp', { TAVILY_API_KEY: 'xxx' })
  .getAISDKTool('tavily-search');

// 3. Use directly
const result = await generateText({
  model: openai('gpt-4o'),
  tools: { searchTool },
  prompt: 'What is the latest news about AI?'
});

The Power of Open Ecosystem:

MCPSDK allows you to use any of the 7,800+ MCP Tools in the registry with the exact same simple API:

// Example 1: Use database tools
const dbTool = await toolSDK
  .package('@modelcontextprotocol/server-sqlite', { db: '/path/to/db' })
  .getAISDKTool('query');

// Example 2: Use community Slack tools
const slackTool = await toolSDK
  .package('@community/slack-mcp', { SLACK_TOKEN: 'xxx' })
  .getAISDKTool('post-message');

// Example 3: Use any custom MCP submitted to the registry
const myTool = await toolSDK
  .package('my-username/my-custom-mcp', { API_KEY: 'xxx' })
  .getAISDKTool('my-action');

Key difference: While both require a registry, Agentic is limited to ~20 official tools, whereas MCPSDK provides a uniform API to access 7,800+ community-driven tools.

3. Code Comparison: Side by Side

Let's compare implementing the same functionality: Using a search tool to query the latest AI news

3.1 Agentic Approach

import { createAISDKTools } from '@agentic/ai-sdk'
import { AgenticToolClient } from '@agentic/platform-tool-client'
import { openai } from '@ai-sdk/openai'
import { generateText } from 'ai'

// Load tool from Agentic's standard library
const searchTool = await AgenticToolClient.fromIdentifier('@agentic/search')

const result = await generateText({
  model: openai('gpt-4o-mini'),
  tools: createAISDKTools(searchTool),
  prompt: 'What is the latest news about AI?'
})
// ⚠️ Requires payment (only 3 free calls)

Lines of Code: 9 lines

Cost: Pay-per-call (only 3 free calls)

Tool Selection: Limited to ~20 official tools

3.2 MCPSDK Approach

import { generateText } from 'ai';
import { openai } from '@ai-sdk/openai';
import { MCPSDKApiClient } from 'toolsdk/api';

// 1. Initialize
const toolSDK = new MCPSDKApiClient({ apiKey: 'xxx' });

// 2. Get tool (Uniform pattern)
const searchTool = await toolSDK
  .package('@mcpsdk.dev/tavily-mcp', { TAVILY_API_KEY: 'xxx' })
  .getAISDKTool('tavily-search');

// 3. Use tool
const result = await generateText({
  model: openai('gpt-4o'),
  tools: { searchTool },
  prompt: 'What is the latest news about AI?'
});

Lines of Code: 12 lines

Cost: Free (manage your own API keys)

Tool Selection: 7,800+ MCP tools available

3.3 Multi-Tool Integration Scenario

Let's compare implementing a "Research + Email" Agent (search news and send email):

Agentic Approach

// Can only use tools from Agentic's standard library
const searchTool = await AgenticToolClient.fromIdentifier('@agentic/search')

// ⚠️ Agentic must have this specific tool in its ~20 items
const emailTool = await AgenticToolClient.fromIdentifier('@agentic/email')

const result = await generateText({
  model: openai('gpt-4o'),
  tools: createAISDKTools([searchTool, emailTool]),
  prompt: 'Search AI news and send to john@example.com'
})

The Problem: If the curated list of 20 tools doesn't include an email tool, you cannot implement this.

MCPSDK Approach

const toolSDK = new MCPSDKApiClient({ apiKey: 'xxx' })

// Access any of the 7,800+ MCP tools in the registry
const [searchTool, emailTool] = await Promise.all([
  toolSDK
    .package('@mcpsdk.dev/tavily-mcp', { TAVILY_API_KEY: 'xxx' })
    .getAISDKTool('tavily-search'),
  toolSDK
    .package('@mcpsdk.dev/mcp-send-email', { RESEND_API_KEY: 'xxx' })
    .getAISDKTool('send-email'),
]);

const result = await generateText({
  model: openai('gpt-4o'),
  tools: { searchTool, emailTool },
  prompt: 'Search AI news and send to john@example.com'
})

Advantage: You have immediate access to thousands of tools contributed by the community.

3.4 Additional Scenario: Direct Developer Tool Invocation

Sometimes you need to invoke tools directly without AI.

Agentic Approach

❌ Does not support direct developer tool invocation

Agentic can only pass tools to AI SDK.

MCPSDK Approach

✅ Supports direct tool invocation

import { MCPSDKApiClient } from 'toolsdk/api';

const toolSDK = new MCPSDKApiClient({ apiKey: 'xxx' });

// Direct invocation (Uniform API: package -> run)
const result = await toolSDK
  .package('@mcpsdk.dev/github', { GITHUB_TOKEN: 'xxx' })
  .run({
    toolKey: 'create-issue',
    inputData: {
      title: 'New Issue',
      body: 'Issue description'
    }
  });

console.log(result); // Get execution result directly

4. When to use which?

4.1 Choose Agentic if...

✅ You want to use deeply optimized official tools (Agentic UX)
✅ Your needs are covered by Agentic's ~20 curated tools
✅ You prioritize official curation over community scale
✅ You're willing to pay per usage for a managed experience

4.2 Choose MCPSDK if...

✅ You need access to the massive 7,800+ MCP tools ecosystem
✅ You want a free, open-source registry model (GitHub PRs)
✅ You need a uniform API for both AI and direct developer invocation
✅ You want to manage your own 3rd-party API keys to control costs
✅ You want to easily publish and use your own MCP packages

5. The Core Difference

	Agentic	MCPSDK
Design Philosophy	Official curation	Open-source registry
Tool Count	~20 curated tools	7,800+ MCP Tools
Pricing Model	Pay-per-call	Free to use
Tool Extensibility	Official only	Community GitHub PRs
Contribution Model	Centralized	Decentralized
Invocation Method	AI only	AI + Direct developer invocation
API Pattern	`fromIdentifier()`	Uniform `package().getAISDKTool()`
API Key Mgmt	Managed by Agentic	Self-managed by developers

Analogy:

Agentic is like an "Editor's Choice" list (High quality, but very few items).
MCPSDK is like npm (A massive registry where everything is accessible via one uniform command).

Core Difference: Official Curation vs 7,800+ MCP Tool Registry

Scenario	Agentic	MCPSDK
Tool Selection Strategy	Official curation (~20 tools)	Registry (7,800+ Tools)
Adding Your Own MCP	Official review only	Submit PR to open registry
Using Notion API	Wait for official team	Use any community Notion MCP
Direct Tool Invocation	Not supported	Fully supported via `.run()`
3rd-party API Key Mgmt	Managed (paid)	Self-managed (free)

6. Try MCPSDK

Experience the 7,800+ tool MCP ecosystem:

npm install toolsdk

Uniform 2-line integration:

const toolSDK = new MCPSDKApiClient({ apiKey: 'xxx' });
const [searchTool, emailTool] = await Promise.all([
  toolSDK.package('@mcpsdk.dev/tavily-mcp', {...}).getAISDKTool('tavily-search'),
  toolSDK.package('@mcpsdk.dev/mcp-send-email', {...}).getAISDKTool('send-email'),
]);

View complete examples →

MCPSDK vs Smithery

Seey — Fri, 06 Feb 2026 03:18:37 +0000

Comparing Smithery and MCPSDK integration approaches for Vercel AI SDK

Both Smithery and MCPSDK provide hosted MCP servers, eliminating the need to manage local processes. The core differences lie in integration approach and developer experience.

One-sentence summary: Smithery requires manual MCP client management, while MCPSDK provides zero-config tool functions.

1. At a Glance

Dimension	Smithery	MCPSDK
Core Positioning	Hosted MCP Server + Registry	Hosted MCP Server + Developer API
Server Hosting	Cloud-hosted (HTTP)	Cloud-hosted (API)
Server State	Local MCP needs preloading / Remote MCP direct	Always-on / No type distinction
Integration Method	`experimental_createMCPClient`	`getAISDKTool()` / `getOpenAISDKTool()`
Authentication	OAuth Provider	API Key
Multi-tool Management	Manual aggregation of clients	Unified API client
Client Lifecycle	Manual `close()` required	Automatic management
API Key Management	Handled in OAuth	Configured in `package()` call
Tool Invocation	AI invocation only	AI invocation + Direct developer invocation

2. Deep Dive

2.1 Smithery: Hosted MCP Server + HTTP Integration

Smithery provides hosted MCP servers (server.smithery.ai) accessible via HTTP transport protocol, suitable for use with Vercel AI SDK.

Advantages:

☁️ No need to manage local processes (cloud-hosted)
🌐 HTTP access (suitable for Serverless environments)
📚 Beautiful tool registry and documentation
🔒 OAuth authentication mechanism

Architecture Characteristics:

🔄 MCP Type Separation: Distinguishes between Local MCP and Remote MCP
- Local MCP: Requires preloading to server, cannot be invoked directly (cold start)
- Remote MCP: Direct access via dedicated endpoints (e.g., server.smithery.ai/exa)
⚠️ Invocation Complexity: Developers need to understand and distinguish between different MCP types

Vercel AI SDK Integration Code:

import { experimental_createMCPClient as createMCPClient } from '@ai-sdk/mcp';
import { streamText } from 'ai';
import { openai } from '@ai-sdk/openai';

// 1. Create MCP client (experimental API)
const mcpClient = await createMCPClient({
  transport: {
    type: 'http',
    url: 'https://server.smithery.ai/exa',
    authProvider: myOAuthClientProvider,  // OAuth configuration required
  },
});

// 2. Get tool list
const tools = await mcpClient.tools();

// 3. Use in AI calls
const result = await streamText({
  model: openai('gpt-4o-mini'),
  tools,
  prompt: 'Search the web for the latest AI news',
  onFinish: async () => {
    await mcpClient.close();  // Manual client closure required
  },
});

Multi-tool Integration (Manual Aggregation Required):

import { experimental_createMCPClient as createMCPClient } from '@ai-sdk/mcp';

// Need to create separate clients for each server
const servers = [
  'https://server.smithery.ai/exa',
  'https://server.smithery.ai/@anthropics/brave-search',
];

const clients = await Promise.all(
  servers.map(url =>
    createMCPClient({
      transport: { type: 'http', url, authProvider: myOAuthClientProvider },
    })
  )
);

// Manually aggregate all tools
const allTools = Object.assign(
  {}, 
  ...(await Promise.all(clients.map(c => c.tools())))
);

Key Considerations:

⚠️ Uses experimental_createMCPClient (experimental API, subject to change)
⚠️ Requires OAuth Provider configuration (additional authentication complexity)
⚠️ Manual management of multiple clients for multiple tools
⚠️ Manual close() calls required for lifecycle management
⚠️ Third-party tool API keys (e.g., Exa) handled in OAuth (opaque)
⚠️ Local MCP requires preloading: Cannot be invoked directly, slower response
⚠️ MCP type distinction required: Local MCP and Remote MCP have different invocation patterns

2.2 MCPSDK: Hosted MCP Server + Developer-Friendly API

MCPSDK also provides hosted MCP servers, but with higher-level API wrapping optimized for developer experience.

Advantages:

🎯 Stable API (non-experimental)
🔑 Simple API key authentication
🛠️ Zero-config tool function generation
🔄 Automatic client lifecycle management
📦 Unified third-party tool API key management
🎮 Flexible invocation: Supports both AI invocation and direct developer invocation

Architecture Characteristics:

⚡ All MCP Servers Always-On: No installation or startup needed, use on demand
🚀 Zero Cold Start: All tool packages preloaded in cloud, faster response
🔌 Unified API Gateway: Access all tool packages through single entry point
🎯 No Type Distinction: Local MCP and Remote MCP handled uniformly, transparent to developers

Vercel AI SDK Integration Code:

import { generateText } from 'ai';
import { openai } from '@ai-sdk/openai';
import { MCPSDKApiClient } from 'toolsdk/api';

// 1. Initialize MCPSDK (simple API key)
const toolSDK = new MCPSDKApiClient({ 
  apiKey: process.env.TOOLSDK_API_KEY 
});

// 2. Get tool (chained call, one line)
const searchTool = await toolSDK
  .package('tavily-mcp', { TAVILY_API_KEY: process.env.TAVILY_API_KEY })
  .getAISDKTool('tavily-search');

// 3. Use directly (no manual close)
const result = await generateText({
  model: openai('gpt-4o'),
  tools: { searchTool },
  prompt: 'What is the latest news about AI?'
});

Direct Developer Tool Invocation (No AI Required):

import { MCPSDKApiClient } from 'toolsdk/api';

const toolSDK = new MCPSDKApiClient({ apiKey: 'xxx' });

// Invoke tool directly without AI
const result = await toolSDK
  .package('github', { GITHUB_TOKEN: 'xxx' })
  .run({
    toolKey: 'create-issue',
    inputData: {
      title: 'New Issue',
      body: 'Issue description'
    }
  });

console.log(result); // Get tool execution result directly

Multi-tool Integration (Unified Client):

import { generateText } from 'ai';
import { openai } from '@ai-sdk/openai';
import { MCPSDKApiClient } from 'toolsdk/api';

const toolSDK = new MCPSDKApiClient({ apiKey: 'xxx' });

// Parallel tool fetching (Promise.all + chaining)
const [searchTool, emailTool] = await Promise.all([
  toolSDK
    .package('tavily-mcp', { TAVILY_API_KEY: 'xxx' })
    .getAISDKTool('tavily-search'),
  toolSDK
    .package('@mcpsdk.dev/mcp-send-email', { RESEND_API_KEY: 'xxx' })
    .getAISDKTool('send-email'),
]);

// Use directly
const result = await generateText({
  model: openai('gpt-4o'),
  tools: { searchTool, emailTool },
  prompt: 'Search AI news and send to john@example.com'
});

Developer Experience Advantages:

✅ Stable API (not experimental_)
✅ No OAuth Provider configuration required
✅ Unified API client manages all tools
✅ Transparent third-party API key management
✅ Automatic client lifecycle management (no close())
✅ Better TypeScript type inference
✅ No MCP type distinction: Local and Remote MCP handled uniformly
✅ Flexible invocation: Can be used by AI or invoked directly by developers

3. Code Comparison: Side by Side

Let's compare implementing the same functionality: Using a search tool to query the latest AI news

3.1 Smithery Approach

import { experimental_createMCPClient as createMCPClient } from '@ai-sdk/mcp';
import { streamText } from 'ai';
import { openai } from '@ai-sdk/openai';

// 1. Create MCP client (experimental API)
const mcpClient = await createMCPClient({
  transport: {
    type: 'http',
    url: 'https://server.smithery.ai/exa',
    authProvider: myOAuthClientProvider,  // ⚠️ OAuth configuration required
  },
});

// 2. Get tools
const tools = await mcpClient.tools();

// 3. Use tool
const result = await streamText({
  model: openai('gpt-4o-mini'),
  tools,
  prompt: 'Search the web for the latest AI news',
  onFinish: async () => {
    await mcpClient.close();  // ⚠️ Manual closure required
  },
});

Lines of Code: 18 lines

Configuration Required: OAuth Provider

Manual Management: Client lifecycle (close)

3.2 MCPSDK Approach

import { generateText } from 'ai';
import { openai } from '@ai-sdk/openai';
import { MCPSDKApiClient } from 'toolsdk/api';

// 1. Initialize (simple API key)
const toolSDK = new MCPSDKApiClient({ apiKey: 'xxx' });

// 2. Get tool (chained call)
const searchTool = await toolSDK
  .package('tavily-mcp', { TAVILY_API_KEY: 'xxx' })
  .getAISDKTool('tavily-search');

// 3. Use tool
const result = await generateText({
  model: openai('gpt-4o'),
  tools: { searchTool },
  prompt: 'Search the web for the latest AI news'
});

Lines of Code: 12 lines

Configuration Required: API Key (standard)

Manual Management: None

3.3 Additional Scenario: Direct Developer Tool Invocation

Sometimes you need to invoke tools directly without AI.

Smithery Approach

❌ Does not support direct developer tool invocation

Smithery's MCP client can only pass tools to AI SDK, cannot execute tools directly.

MCPSDK Approach

✅ Supports direct tool invocation

import { MCPSDKApiClient } from 'toolsdk/api';

const toolSDK = new MCPSDKApiClient({ apiKey: 'xxx' });

// Invoke tool directly (no AI)
const result = await toolSDK
  .package('github', { GITHUB_TOKEN: 'xxx' })
  .run({
    toolKey: 'create-issue',
    inputData: {
      title: 'New Issue',
      body: 'Issue description'
    }
  });

console.log(result); // Get tool execution result directly

Lines of Code: 8 lines

Use Cases: Background tasks, scheduled jobs, webhook handlers, and other non-AI scenarios

4. When to use which?

4.1 Choose Smithery if...

✅ You prefer OAuth authentication (over API keys)
✅ You're comfortable using experimental APIs (experimental_createMCPClient)
✅ You need specific tools from the Smithery registry (e.g., Brave Search)
✅ You need to use tools in both Claude Desktop and code

4.2 Choose MCPSDK if...

✅ You want to use stable APIs (non-experimental)
✅ You need to manage multiple tools uniformly (no need to create clients for each)
✅ You want transparent third-party API key management (e.g., Tavily, Resend)
✅ You don't want to handle client lifecycle (automatic management)
✅ You need better TypeScript type support
✅ You want to uniformly invoke all MCP types (no Local/Remote distinction, no cold start)
✅ You need direct developer tool invocation (background tasks, scheduled jobs, webhooks, and other non-AI scenarios)

5. The Core Difference

	Smithery	MCPSDK
Design Philosophy	Hosted server + Low-level MCP client	Hosted server + High-level developer API
MCP Types	Distinguishes Local MCP and Remote MCP	Handles all MCP types uniformly
Server Architecture	Local MCP needs preloading, Remote MCP dedicated endpoints	All always-on, unified gateway
Startup Method	Local MCP has cold start, Remote MCP direct	Preloaded always-on (zero cold start)
Invocation Method	AI invocation only	AI invocation + Direct developer invocation
Integration Layer	Protocol layer (`createMCPClient`)	Application layer (`getAISDKTool` / `run`)
Complexity	Requires understanding MCP types, clients, transport, lifecycle	One line to get/execute tool
Use Cases	Deep MCP integration customization	AI apps + Background tasks + Automation

Analogy:

Smithery is like AWS SDK (you manage clients, connections, authentication)
MCPSDK is like Firebase (you just call simple APIs)

Server Architecture Analogy:

Smithery is like hybrid cloud (Local MCP = on-premise deployment needs preloading, Remote MCP = cloud direct)
MCPSDK is like unified fully-managed service (all MCPs always-on in cloud, instant response)

6. Try MCPSDK

Experience zero-config MCP tool integration:

npm install toolsdk

2 lines of code to integrate search + email tools:

const toolSDK = new MCPSDKApiClient({ apiKey: 'xxx' });
const [searchTool, emailTool] = await Promise.all([
  toolSDK.package('tavily-mcp', {...}).getAISDKTool('tavily-search'),
  toolSDK.package('@mcpsdk.dev/mcp-send-email', {...}).getAISDKTool('send-email'),
]);

View complete examples →

MCPSDK vs Official MCP SDK

Seey — Fri, 06 Feb 2026 03:16:10 +0000

Why use MCPSDK over the official Model Context Protocol SDK?

The Official MCP SDK is a low-level protocol implementation for deep customization, while MCPSDK is a high-level abstraction designed to help AI applications quickly integrate with the MCP tool ecosystem.

One-sentence summary: Official MCP SDK is for building servers; MCPSDK is for using tools in AI apps.

1. At a Glance

Dimension	Official MCP SDK	MCPSDK
Positioning	Protocol implementation library	Developer experience layer
Best For	Building MCP servers/clients	Using MCP tools in AI apps
Setup Complexity	High (manual transport config)	Low (Hosted + API Key)
AI SDK Integration	Manual bridging required	Out-of-the-box (AI SDK / OpenAI)
Deployment	Requires process management	Cloud-hosted, no local process

2. Deep Dive

2.1 Official SDK: Full Control, Full Responsibility

The official SDK provides a complete implementation of the Model Context Protocol. It is ideal if you are:

Building your own MCP server from scratch.
Need deep control over transport layers (stdio/SSE/WebSocket).
Need to understand the low-level details of the protocol.

Advantages:

🛠️ Full Control: Direct access to every protocol feature and extension.
🤝 No Middleman: Direct connection between your client and server.
🏛️ Official Support: Maintained by the protocol creators (Anthropic).

The Cost: You must manage process lifecycles, transport configurations, and manual tool call serialization yourself.

import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";

// 1. Manually configure transport
const transport = new StdioClientTransport({
  command: "npx",
  args: ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/dir"],
});

// 2. Initialize client
const client = new Client(
  { name: "my-client", version: "1.0.0" },
  { capabilities: { tools: {} } }
);

await client.connect(transport);

// 3. List tools
const { tools } = await client.listTools();

// 4. Manually call tools
const result = await client.callTool({
  name: "read_file",
  arguments: { path: "file.txt" },
});

// 5. Manual bridging logic needed for Vercel AI SDK or others

2.2 MCPSDK: Optimized for AI Applications

MCPSDK assumes your goal is to use MCP tools in an AI application, not to implement the protocol itself. It provides:

Hosted Runtime: MCP servers run in the cloud; no local processes to manage.
Plug-and-play Integration: Directly generates tools compatible with Vercel AI SDK, OpenAI SDK, etc.
API Key Management: Unified management for third-party tool keys (e.g., Tavily, Resend).

import { generateText } from 'ai';
import { openai } from '@ai-sdk/openai';
import { MCPSDKApiClient } from 'toolsdk/api';

// 1. Initialize MCPSDK (API Key only)
const toolSDK = new MCPSDKApiClient({ 
  apiKey: 'your-toolsdk-api-key' 
});

// 2. Load tool package (MCPSDK hosts the MCP server)
const searchPackage = await toolSDK.package(
  '@mcpsdk.dev/tavily-mcp', 
  { TAVILY_API_KEY: 'xxx' }
);

// 3. Get AI SDK Tool (Zero bridging code)
const searchTool = await searchPackage.getAISDKTool('tavily-search');

// 4. Use directly in AI call
const result = await generateText({
  model: openai('gpt-4o'),
  tools: { searchTool },
  prompt: 'What is the latest news about AI?'
});

3. When to use which?

3.1 Choose Official SDK if...

✅ You are building an MCP server or protocol-level tooling.
✅ You need absolute control over the transport layer (e.g., custom protocol extensions).
✅ Your application already has a robust process management system.
✅ You want to avoid any third-party service dependencies.

3.2 Choose MCPSDK if...

✅ You are building an AI Agent, Chatbot, or Workflow.
✅ You use Vercel AI SDK, OpenAI SDK, or Anthropic SDK.
✅ You want to quickly integrate existing MCP tools (Search, Mail, DB, etc.).
✅ You want to avoid the complexity of process management and deployment.
✅ You need to run in Edge Runtime or Serverless environments.

4. The Core Difference

	Official MCP SDK	MCPSDK
Design Philosophy	Protocol implementation	Developer-centric API
Setup Complexity	High (Process & Transport)	Zero (Hosted & API-based)
AI SDK Integration	Manual (Requires bridging)	Native (getAISDKTool)
Deployment	Local processes / Manual setup	Always-on Cloud Runtime
Maintenance	Manual (Updates & SDK sync)	Auto-managed by MCPSDK

Analogy:

Official MCP SDK is like building a car from components (you get the engine, chassis, and wheels, but you must assemble them).
MCPSDK is like renting a fleet via an app (the cars are ready, maintained, and you just drive them).

5. Try MCPSDK

Experience zero-config MCP tool integration:

npm install toolsdk

Uniform 2-line integration for search + email tools:

const toolSDK = new MCPSDKApiClient({ apiKey: 'your-api-key' });
const [searchTool, emailTool] = await Promise.all([
  toolSDK.package('@mcpsdk.dev/tavily-mcp', { TAVILY_API_KEY: 'xxx' }).getAISDKTool('tavily-search'),
  toolSDK.package('@mcpsdk.dev/mcp-send-email', { RESEND_API_KEY: 'xxx' }).getAISDKTool('send-email'),
]);

View complete examples on GitHub →