שרתי MCP — הפרוטוקול שמחבר AI לכל מערכת (מדריך 2026)

למי זה מתאים: מפתחים ואנשי פרודקט שהבחינו שכל אינטגרציה ל-AI היא פרויקט נפרד — כתבת פעם wrapper ל-Gmail, פעם ל-Notion, פעם ל-Firestore, וכל אחד עובד אחרת. המדריך הזה מסביר מה זה שרת MCP, למה זה השתנה ב-2026, ואיך לכתוב שרת MCP אחד שאחר כך עובד מול Claude Desktop, ChatGPT, Cursor, Windsurf ו-Vercel — בלי שתצטרך להתאים את הקוד לכל אחד מהם.

הבעיה שהיתה לפני MCP

אם בנית פעם אינטגרציה בין LLM למערכת חיצונית — אתה מכיר את הסיפור. ה-API של OpenAI מצפה ל-functions בפורמט אחד, Claude מצפה ל-tools בפורמט אחר, Gemini ל-function_declarations עם schema קצת שונה. כל פעם שהוספת tool כתבת אותו שלוש פעמים, וכל פעם שהחלפת מודל שיכפלת לוגיקה. מי שעבר את התהליך הזה יזהה אותו מהמדריך על בחירת מודל לעסק: שלושה ספקים, שלושה פורמטים, אפס תאימות.

ועד כאן מדובר רק על המודל הראשי. אם רצית שגם Cursor יעבוד עם אותם tools, וגם Claude Desktop, וגם הצ׳אט שלך באתר — היית צריך לעטוף את הלוגיקה בעוד שלוש שכבות, אחת לכל לקוח. רוב הצוותים לא טרחו: הם פשוט הדביקו במודל המקור JSON של הנתונים והתפללו שזה יספיק.

בנובמבר 2024 Anthropic הציגה את Model Context Protocol (MCP), פרוטוקול פתוח שמטרתו לפתור בדיוק את זה. במקום שכל לקוח LLM ידבר ישירות עם כל מערכת, מגדירים שרת אחד שחושף resources, tools ו-prompts, וכל לקוח שמדבר MCP יכול להתחבר. במרץ 2025 OpenAI הצטרפה לתקן רשמית (תמיכה ב-Agents SDK, ב-Responses API וב-ChatGPT), Google הצטרפה בהמשך השנה, ובדצמבר 2025 Anthropic תרמה את הפרוטוקול ל-Agentic AI Foundation תחת Linux Foundation — כך שהיום זה לא פורמט של חברה אחת אלא תקן ניטרלי בניהול קהילתי. בתחילת 2026 כבר אי אפשר להתעלם — MCP הוא הסטנדרט.

מה זה שרת MCP בעצם

שרת MCP הוא תהליך שמדבר בפרוטוקול JSON-RPC 2.0 ומגדיר שלוש קטגוריות עיקריות של מה שאפשר לחשוף ללקוח:

Resources — מקורות מידע שהמודל יכול לקרוא. קובץ, רשומה במסד נתונים, תוצאה של חיפוש. הם מקבילים ל-GET ב-REST. בדרך כלל מזוהים על ידי URI (file:///path/to/doc, firestore://users/abc123, notion://page/xyz).

Tools — פעולות שהמודל יכול לקרוא להן. הן מקבילות ל-POST ב-REST או ל-function call של OpenAI. לכל tool יש שם, תיאור, ו-JSON Schema של הפרמטרים. השרת מבצע את הפעולה ומחזיר תוצאה.

Prompts — תבניות פרומפט מובנות שהשרת יכול להציע. למשל, שרת ל-GitHub יכול להציע prompt בשם code-review שמייבא בתוכו את ה-diff של ה-PR. המשתמש בוחר אותו ב-UI של הלקוח, וה-LLM מקבל את הפרומפט המוכן.

הלקוח (Claude Desktop, ChatGPT, Cursor וכו׳) מתקשר עם השרת דרך אחד משני transports עיקריים ב-2026:

• stdio — השרת רץ כסאב-פרוסס של הלקוח, מתקשרים דרך stdin/stdout. הכי פשוט, הכי פופולרי. מתאים לשרתים מקומיים שצריכים גישה למחשב.
• Streamable HTTP — השרת רץ כשרת רגיל מאחורי HTTPS, הלקוח שולח בקשות POST ומקבל תשובות (כולל streaming דרך SSE כשצריך). זה ה-transport המומלץ לשרתים מרוחקים, והוא החליף את ה-HTTP+SSE הישן שהיה בגרסאות הראשונות.

הערה חשובה ל-2026: אם בנית שרת מרוחק בעבר מול ה-transport הישן של SSE — שדרג ל-Streamable HTTP. הליבה החדשה היא stateless: שרת מרוחק שפעם דרש sticky sessions ו-session store משותף יכול עכשיו לרוץ מאחורי load balancer רגיל של round-robin, מה שמוריד דרמטית את עלות התשתית.

Resources, Tools ו-Prompts — מתי משתמשים במה

ההבחנה לא תמיד ברורה למתחילים. כלל אצבע פשוט:

טעות נפוצה: לעטוף הכול כ-Tools. אם המידע סטטי וקריא — Resource זול יותר בקונטקסט ולא דורש מהמודל ״להחליט״ לקרוא לו.

למה זה משנה — מעבר לעוד buzzword

הסיבה ש-MCP תפס מהר היא לא טכנית — היא כלכלית. לפניו, אם בנית tool שמועיל למפתחים (נגיד, integration עם Linear), היית צריך להכניס אותו לתוך פלטפורמה מסוימת. אם הצלחת, קיבלת חשיפה רק במסגרת הפלטפורמה הזו; אם הפלטפורמה החליטה להחליף אותך — נגמר הסיפור.

עם MCP, אתה כותב שרת אחד והוא עובד בכל מקום. ה-Linear MCP server שכתבה Linear עצמה — אותו קוד רץ ב-Claude Desktop, ב-ChatGPT, ב-Cursor, ב-Windsurf, ב-Vercel AI SDK, ובכל לקוח עתידי. זה הזיז את הכוח מהפלטפורמות למי שבונה את ה-tools. זו אותה דינמיקה בדיוק שדחפה את Vercel AI Gateway, שכבת ביניים אחת שמדברת מול הכול, רק שכאן זה לרוחב הלקוחות ולא לרוחב המודלים.

השוק ב-2026 גדול: ה-MCP Registry הרשמי, שעלה לאוויר בספטמבר 2025, חצה את רף 10,000 השרתים הציבוריים הפעילים לפי דיווח Anthropic מסוף 2025, וה-SDKs של TypeScript ו-Python לבדם מדווחים על כ-97 מיליון הורדות בחודש. כמה שרתים בולטים:

• GitHub MCP (רשמי) — קריאת issues, יצירת PRs, חיפוש קוד ברפו.
• Linear MCP (רשמי) — ניהול issues ו-cycles.
• Slack MCP (קהילתי) — קריאת ערוצים ושליחת הודעות.
• Gmail / Google Calendar / Drive (Google, רשמי) — גישה לתיבת הדואר והקלנדר.
• Vercel MCP — deploy, env vars, logs.
• Stripe MCP — בדיקת חיובים, יצירת invoices.
• Notion MCP — קריאה וכתיבה לדפים.
• Filesystem / SQLite / PostgreSQL — שרתים בסיסיים שנשלחים עם ה-SDK.

איפה מוצאים אותם? אין רישום קנוני יחיד — Anthropic תרמה את התקן ובכוונה לא מפעילה חנות מרכזית. בפועל יש את ה-Registry הרשמי בתור clearinghouse, ולצידו כמה hubs קהילתיים מובילים: mcp.so, Smithery ו-PulseMCP. ל-Claude Desktop ב-2026 יש marketplace מובנה שמאפשר התקנה בקליק; Cursor ו-Windsurf מקבלים אותם דרך הגדרות הפרויקט; Vercel הוסיפה תמיכה ב-MCP ל-AI SDK כדי שתוכל להכניס שרתים לאפליקציות הצ׳אט שלך עצמך.

ארכיטקטורה — מה רץ איפה

נסתכל על תרחיש קונקרטי. נניח שאתה כותב שרת MCP שחושף את מסד הנתונים של ה-CRM שלך (Firestore) ל-Claude Desktop. הזרימה היא כזו:

1. המשתמש שואל את Claude — ״כמה לידים חדשים נכנסו השבוע?״
2. Claude (הלקוח) מסתכל ברשימת ה-tools הזמינים מהשרת שלך, ורואה tool בשם query_leads עם schema של פרמטרים (since, until, status).
3. Claude מחליט שצריך לקרוא ל-query_leads עם since=2026-06-15, until=2026-06-22.
4. השרת שלך מקבל את הבקשה כ-JSON-RPC, מריץ query על Firestore, מחזיר את התוצאה כ-JSON.
5. Claude מסכם את התוצאה למשתמש בעברית.

השרת שלך לא יודע שזה Claude — אם המשתמש משתמש ב-Cursor או ב-ChatGPT במקום, אותה זרימה בדיוק. השרת רק מקבל בקשות JSON-RPC ומחזיר תשובות. זה הקסם של הפרוטוקול: כתבת פעם אחת, עובד מול כל לקוח שמדבר MCP.

MCP מול function calling רגיל — מתי בכלל צריך שרת

שאלה לגיטימית: אם אני בונה צ׳אט בודד עם מודל אחד, למה לא פשוט להגדיר tools ישירות ב-API? התשובה תלויה בכמה לקוחות וכמה מודלים יש בתמונה.

הכלל הפרקטי: לצ׳אט בודד עם tool פנימי אחד — function calling ב-API מספיק והוא פחות overhead. ברגע שיש יותר מלקוח אחד, או שאתה רוצה שאנשים אחרים בארגון ישתמשו במערכת דרך ה-LLM שהם מעדיפים — שרת MCP מחזיר את ההשקעה. זו אותה החלטת ״כמה מהמערכת לחשוף ולמי״ שמופיעה גם בהקמת RAG ל-PDF פנימי.

דוגמה ראשונה — שרת ב-TypeScript שחושף Firestore

נכתוב שרת פשוט שחושף collection אחת מ-Firestore — leads — עם שני tools: list_leads ו-add_note_to_lead. נשתמש ב-SDK הרשמי @modelcontextprotocol/sdk.

npm init -y
npm install @modelcontextprotocol/sdk firebase-admin zod
npm install -D typescript @types/node tsx
npx tsc --init

הקובץ הראשי, src/server.ts:

import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import {
  CallToolRequestSchema,
  ListToolsRequestSchema,
} from '@modelcontextprotocol/sdk/types.js';
import { initializeApp, cert } from 'firebase-admin/app';
import { getFirestore } from 'firebase-admin/firestore';
import { z } from 'zod';

// Firebase init
initializeApp({
  credential: cert(process.env.GOOGLE_APPLICATION_CREDENTIALS!),
});
const db = getFirestore();

// MCP server
const server = new Server(
  { name: 'crm-firestore', version: '1.0.0' },
  { capabilities: { tools: {} } },
);

// Schemas
const ListLeadsArgs = z.object({
  status: z.enum(['new', 'contacted', 'closed']).optional(),
  limit: z.number().int().min(1).max(100).default(20),
});

const AddNoteArgs = z.object({
  leadId: z.string().min(1),
  note: z.string().min(1).max(2000),
});

// Tool list
server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [
    {
      name: 'list_leads',
      description: 'מחזיר רשימת לידים מה-CRM, אפשר לסנן לפי סטטוס',
      inputSchema: {
        type: 'object',
        properties: {
          status: { type: 'string', enum: ['new', 'contacted', 'closed'] },
          limit: { type: 'number', minimum: 1, maximum: 100, default: 20 },
        },
      },
    },
    {
      name: 'add_note_to_lead',
      description: 'מוסיף הערה ללייד קיים',
      inputSchema: {
        type: 'object',
        properties: {
          leadId: { type: 'string' },
          note: { type: 'string' },
        },
        required: ['leadId', 'note'],
      },
    },
  ],
}));

// Tool handler
server.setRequestHandler(CallToolRequestSchema, async (req) => {
  if (req.params.name === 'list_leads') {
    const { status, limit } = ListLeadsArgs.parse(req.params.arguments);
    let q = db.collection('leads').orderBy('createdAt', 'desc').limit(limit);
    if (status) q = q.where('status', '==', status);
    const snap = await q.get();
    const leads = snap.docs.map((d) => ({ id: d.id, ...d.data() }));
    return {
      content: [{ type: 'text', text: JSON.stringify(leads, null, 2) }],
    };
  }

  if (req.params.name === 'add_note_to_lead') {
    const { leadId, note } = AddNoteArgs.parse(req.params.arguments);
    await db.collection('leads').doc(leadId).collection('notes').add({
      text: note,
      createdAt: new Date(),
    });
    return { content: [{ type: 'text', text: `הערה נוספה ללייד ${leadId}` }] };
  }

  throw new Error(`Unknown tool: ${req.params.name}`);
});

// Transport
const transport = new StdioServerTransport();
await server.connect(transport);

זה הכל. השרת רץ עם npx tsx src/server.ts, מאזין על stdin, ומחזיר תשובות ל-stdout. הלוגים הולכים ל-stderr (חשוב — אם תכתוב ל-stdout משהו שאינו פרוטוקול, הלקוח יקרוס).

טיפ דיבוג: לפני שמחברים ללקוח אמיתי, הרץ את השרת מול MCP Inspector (npx @modelcontextprotocol/inspector npx tsx src/server.ts). זה כלי web שמראה את רשימת ה-tools, נותן לקרוא להם ידנית, ומדפיס את ה-JSON-RPC הגולמי. חוסך שעות של ניחושים מול Claude Desktop שפשוט ״לא רואה״ את השרת.

חיבור ל-Claude Desktop

עכשיו צריך להגיד ל-Claude Desktop להריץ את השרת. הקובץ הוא ~/Library/Application Support/Claude/claude_desktop_config.json (Mac) או %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "crm": {
      "command": "npx",
      "args": ["tsx", "/Users/noam/projects/crm-mcp/src/server.ts"],
      "env": {
        "GOOGLE_APPLICATION_CREDENTIALS": "/Users/noam/secrets/firebase-key.json"
      }
    }
  }
}

אחרי restart של Claude Desktop, תראה את ה-tools בתפריט. תכתוב למשל ״תראה לי 5 לידים חדשים״ — Claude יזהה שיש tool מתאים ויקרא לו אוטומטית.

דוגמה שנייה — שרת HTTP מרוחק

אם אתה רוצה ששרת ירוץ בענן (לא במחשב של המשתמש), Streamable HTTP הוא הדרך. נכתוב מינימום:

import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StreamableHTTPServerTransport } from '@modelcontextprotocol/sdk/server/streamableHttp.js';
import express from 'express';

const app = express();
app.use(express.json());

const mcp = new Server(
  { name: 'remote-tools', version: '1.0.0' },
  { capabilities: { tools: {} } },
);

// ... רישום tools כמו בדוגמה הקודמת ...

app.all('/mcp', async (req, res) => {
  const transport = new StreamableHTTPServerTransport({
    sessionIdGenerator: () => crypto.randomUUID(),
  });
  await mcp.connect(transport);
  await transport.handleRequest(req, res, req.body);
});

app.listen(3000);

ב-Claude Desktop מחברים אותו עם:

{
  "mcpServers": {
    "remote": {
      "url": "https://your-server.example.com/mcp",
      "headers": { "Authorization": "Bearer xxxxx" }
    }
  }
}

אימות והרשאות — OAuth, לא רק Bearer token

שרת מקומי (stdio) רץ עם ההרשאות של המשתמש שמריץ אותו, אז האבטחה שם היא בעיקר ״אל תיתן לו לעשות נזק״. שרת מרוחק זה סיפור אחר — הוא נגיש ברשת, ולכן ב-2026 התקן מגדיר שכבת authorization מסודרת מעל Streamable HTTP.

הגרסאות החדשות של הספק מאמצות OAuth 2.1: שרת MCP מוגן מתפקד כ-OAuth 2.1 resource server, והלקוח מתפקד כ-OAuth 2.1 client שמבצע בקשות בשם בעל המשאב. בפועל זה אומר:

1. הלקוח פונה לשרת בלי token, מקבל 401 עם מידע על שרת ה-authorization (לפי תקן Protected Resource Metadata).
2. הלקוח מבצע OAuth flow מול שרת ה-authorization, מקבל access token.
3. כל בקשת MCP נושאת את ה-token ב-Authorization: Bearer, והשרת מאמת אותו ובודק scopes.

היתרון על Bearer token סטטי שאתה מדביק ב-config: לכל משתמש token משלו עם scopes משלו, ה-tokens פגי-תוקף ומתחדשים, ואין סוד אחד משותף שדליפתו פותחת את כל הדלת. ל-MVP פנימי — Bearer token מספיק. לכל דבר שמשרת יותר ממך — לך על OAuth.

Elicitation — כשהשרת צריך לשאול את המשתמש באמצע

עד 2026 שרת MCP היה צד פסיבי לחלוטין: מקבל בקשה, מחזיר תשובה, נקודה. אבל מה אם tool צריך מידע שלא הגיע בפרמטרים — נגיד, אישור סופי לפני חיוב, או בחירה בין שתי כתובות משלוח?

לזה נכנס elicitation: השרת יכול, תוך כדי טיפול בבקשה של הלקוח, לבקש מהלקוח להציג למשתמש שאלה ולהחזיר תשובה. חשוב הניסוח — server-initiated request מותר רק כשהשרת באמת מעבד בקשה פעילה של הלקוח. המשמעות: משתמש לא יקבל פתאום פופ-אפ ״משום מקום״; כל elicitation מתחקה אחורה למשהו שהוא (או הסוכן שלו) התחיל. זה תיקון אבטחה חשוב — שרת לא יכול לנדנד למשתמש או לדוג מידע ביוזמתו.

הגרסה של נובמבר 2025 פיצלה את elicitation לשני מצבים שכדאי להכיר ב-2026:

• form-mode — השרת מבקש מהלקוח להציג טופס מובנה (לפי JSON Schema) ולהחזיר את הערכים. זה המצב לבחירה בין כמה תוצאות, אישור ״כן/לא״, או השלמת שדה חסר.
• url-mode — השרת שולח את המשתמש ל-URL חיצוני מהימן כדי להשלים פעולה שאסור שתעבור דרך הלקוח: זרימת OAuth, הזנת סוד, או הקמת אמצעי תשלום. אחרי שהמשתמש סיים, השרת ממשיך מהנקודה שבה עצר. זה הכלי הנכון כשהשאלה כרוכה בסוד שאסור שהמודל יראה.

מתי זה שימושי בפועל: tool שמבצע פעולה כספית ורוצה ״כן/לא״ מפורש (form-mode); tool שצריך שהמשתמש יחבר חשבון Stripe לפני שאפשר לחייב (url-mode); tool שמצא כמה תוצאות תואמות ורוצה שהמשתמש יבחר; כל זרימה שבה עדיף לעצור ולשאול מאשר לנחש. אם בנית פעם בוט WhatsApp שצריך לאשר הזמנה לפני שליחה (המדריך על סוכן AI ב-WhatsApp נוגע בדיוק בדפוס הזה) — elicitation הוא המקבילה הנקייה בעולם ה-MCP. הדפוס דומה גם לאישורי-ביניים שמופיעים במדריך סוכני קול ב-AI, שם עצירה לאישור אנושי לפני פעולה היא קריטית.

מודל אבטחה — מה צריך לדעת

זה החלק שהכי הרבה מפתחים מפספסים. הלקוח (Claude) מבצע כל קריאה לפי שיקול דעתו של המודל, לפעמים אחרי אישור משתמש ולפעמים לא. זה אומר שצריך להניח: המודל יכול לקרוא לכל tool עם כל פרמטר חוקי, גם אם זה לא מה שהמשתמש התכוון.

הכללים הבסיסיים:

1. כל tool צריך לאמת את הפרמטרים שלו עם schema אמיתי (כמו zod למעלה), לא לסמוך על המודל.
2. לעולם אל תאפשר tools שמבצעים פעולות הרסניות לא הפיכות (נגיד, delete_database) בלי אישור משתמש מפורש — וכאן elicitation הוא הכלי הנכון. Claude Desktop ממילא מציג dialog לפני קריאה ל-tool, אבל אל תסמוך על זה לבד.
3. הגבל הרשאות ברמת השרת, לא ברמת המודל. אם המשתמש לא צריך גישה למחיקה — אל תרשום את ה-tool למחיקה בכלל.
4. לוג כל קריאה — מי קרא, מתי, עם איזה פרמטרים. כשמשהו ישתבש, תרצה לדעת.
5. שרת HTTP מרוחק חייב authentication — OAuth 2.1 עדיף, Bearer token כמינימום. אל תפתח endpoint MCP פתוח לציבור.
6. היזהר מ-prompt injection דרך נתונים. אם tool מחזיר טקסט שמקורו במשתמש קצה (תוכן issue, הודעת לקוח) — המודל עלול לפרש אותו כהוראות. אל תיתן ל-tool אחד להחזיר תוכן זר שמפעיל tool רגיש אחר בלי בקרה.

ב-Claude Desktop יש גם permission scopes — אפשר להגדיר ששרת מסוים יכול רק לקרוא, או רק בתוך תיקייה מסוימת. השתמש בזה. אם אתה בונה משהו ציבורי, כדאי גם להבין את נושא זיהוי בוטים והגנה על endpoints — שרת MCP מרוחק הוא בדיוק סוג ה-endpoint שתוקפים אוטומטיים אוהבים.

טעויות נפוצות

אל תכתוב tools עם תיאורים מעורפלים. המודל מסתמך על ה-description כדי להחליט מתי לקרוא. description: "API call" הוא חסר ערך. כתוב description: "מחזיר לידים מה-CRM, מסונן לפי סטטוס. השתמש כשהמשתמש שואל על לקוחות פוטנציאליים." המודל יבחר טוב יותר.

אל תחשוף יותר מדי tools. מודל שמקבל 80 tools מתבלבל ובוחר רע. אם יש לך הרבה — חלק לשרתים שונים, ותן למשתמש להתקין רק את אלה שהוא צריך.

אל תחזיר נתונים גדולים בלי pagination. המודל יקבל את כל הטקסט בקונטקסט וישתגע. תחזיר את ה-20 הראשונים, ותציע tool נפרד ל-fetch_more.

אל תכתוב ל-stdout בשרת stdio מעבר לתשובות הפרוטוקול. שום console.log של debug. אם תרצה — כתוב ל-stderr עם console.error.

אל תניח שהמודל יזכור context בין קריאות. כל קריאה ל-tool היא עצמאית. אם השרת שלך זקוק ל-session — תחזיר session token בתשובה ותדאג שה-tool הבא יקבל אותו.

איפה זה הולך

ב-2026 MCP הוא כבר לא חידוש — הוא תשתית. כמעט כל פלטפורמת AI שאתה משתמש בה תומכת בו, והממשל עבר ל-Linux Foundation כך שאף ספק לא שולט בכיוון לבדו. השאלה הפתוחה היא לא ״האם להשתמש״ אלא ״מה לחשוף״. אם יש לך מערכת פנימית שצוות שלך משתמש בה — שרת MCP מאפשר לכל אחד מהם לעבוד מולה דרך ה-LLM שהוא מעדיף, בלי שתצטרך לבנות עוד UI.

שני כיוונים מעניינים שכבר נכנסו לטיוטות התקן ב-2026 דוחפים את MCP מ״שכבת tools״ ל״שכבת אפליקציות״ של ממש:

• MCP Apps — היכולת של שרת להחזיר UI אינטראקטיבי, לא רק טקסט או JSON. במקום ש-tool יחזיר טבלה של מספרים שהמודל מנסה לתאר במילים, הוא יכול להחזיר תצוגה ויזואלית (דשבורד, גרף, טופס בחירה) שהלקוח מרנדר בתוך השיחה. זה הופך שרת analytics או שרת הזמנות מ״מקור נתונים״ ל״מיני-אפליקציה״ שחיה בתוך הצ׳אט.
• Tasks — דפוס ״call-now, fetch-later״. בקשה כבדה (נגיד, סריקה של אלפי רשומות או רינדור וידאו) מחזירה מיד task handle, העבודה האמיתית רצה ברקע, והלקוח מושך את התוצאה כשהיא מוכנה. זה פותר את הבעיה שבה tool ארוך חוסם את השיחה או נופל על timeout.

מעבר לשני אלה, הכיוון הגדול של 2026 הוא statelessness ברמת הפרוטוקול: שורת ה-transport של Streamable HTTP דורשת עכשיו headers כמו Mcp-Method ו-Mcp-Name, כך ש-load balancer או gateway יכול לנתב ולתעדף בקשות בלי לפתוח את גוף ה-JSON-RPC. בפועל זה אומר ששרת MCP מרוחק נראה ומתנהג כמו כל microservice REST מודרני, ואפשר לתפעל אותו עם אותם כלי תשתית.

שאלות נפוצות

מה ההבדל בין שרת MCP ל-API רגיל?

API רגיל נבנה לתוכנה שיודעת מראש מה לקרוא ועם אילו פרמטרים. שרת MCP נבנה כך ש-LLM יוכל לגלות את היכולות בעצמו (דרך tools/list) ולהחליט מתי לקרוא להן, על בסיס תיאורים בשפה טבעית. בפועל, שרת MCP הוא לרוב עטיפה דקה מעל API קיים, עם schema-ים ותיאורים שכתובים בשביל מודל ולא בשביל מתכנת.

צריך לבנות שרת MCP נפרד לכל מודל (Claude, ChatGPT, Gemini)?

לא — זה כל הרעיון. שרת MCP אחד עובד מול כל לקוח שמדבר את הפרוטוקול. Claude, ChatGPT (דרך תמיכת OpenAI מ-2025), Cursor, Windsurf ו-Vercel AI SDK כולם מתחברים לאותו שרת בלי שינוי קוד בצד השרת.

האם שרת MCP בטוח לחשוף נתונים רגישים?

תלוי איך בונים אותו. שרת מקומי (stdio) רץ עם ההרשאות של המשתמש; שרת מרוחק חייב authentication — רצוי OAuth 2.1 — ובקרת scopes. הכלל המרכזי: הגבל הרשאות ברמת השרת (אל תרשום בכלל tool שמסוכן), אמת כל פרמטר עם schema, ודרוש אישור משתמש (elicitation) לפעולות הרסניות. לעולם אל תפתח endpoint MCP מרוחק בלי אימות.

stdio או HTTP — מה לבחור?

stdio אם השרת רץ על אותו מחשב כמו הלקוח וצריך גישה לקבצים/מערכת מקומית — זה פשוט יותר ולא חושף כלום לרשת. Streamable HTTP אם השרת רץ בענן ומשרת כמה משתמשים. אם אתה בונה משהו חדש מרוחק — Streamable HTTP, לא ה-SSE הישן שכבר מוחלף.

כמה זמן לוקח לבנות שרת MCP בסיסי?

שרת עם 2-3 tools שעוטף מערכת קיימת — שעה עד שעתיים, כולל בדיקה ב-MCP Inspector. רוב הזמן הולך לא לכתיבת ה-MCP אלא להחלטה אילו tools לחשוף ואיך לכתוב להם תיאורים טובים שהמודל יבין. ה-SDK הרשמי (TypeScript או Python) מסיר כמעט את כל ה-boilerplate.

איפה מוצאים שרתי MCP מוכנים?

ב-MCP Registry הרשמי (clearinghouse שעלה ב-2025 עם אלפי שרתים), ובכמה hubs קהילתיים — mcp.so, Smithery ו-PulseMCP הם השלושה הגדולים. ל-Claude Desktop יש marketplace מובנה להתקנה בקליק. חברות גדולות (GitHub, Linear, Stripe, Notion, Google, Vercel) מפרסמות שרתים רשמיים משלהן.

לסיכום

שרת MCP פותר בעיה אמיתית: במקום לכתוב את אותה אינטגרציה שלוש פעמים לשלושה מודלים ועוד שלוש לשלושה לקוחות — אתה כותב שרת אחד, וכל לקוח שמדבר MCP מתחבר אליו. הליבה היא JSON-RPC עם שלושה primitives (Resources, Tools, Prompts), שני transports (stdio מקומי, Streamable HTTP מרוחק), ושכבת אבטחה שב-2026 כוללת OAuth 2.1 ו-elicitation. הצעד הראשון הפרקטי: קח מערכת אחת שיש לך כבר API אליה, עטוף 2-3 פעולות ב-SDK הרשמי, בדוק ב-MCP Inspector, וחבר ל-Claude Desktop. שעה עבודה, והמערכת שלך פתאום נגישה מכל לקוח AI.

למי לפנות

אם אתה שוקל לבנות שרת MCP פנימי לארגון שלך, או שיש לך מערכת עם API קיים שאתה רוצה לעטוף — שלח לי הודעה דרך טופס יצירת הקשר או ב-WhatsApp ב-wa.me/972585802298. בדרך כלל אפשר לעצב את הארכיטקטורה הבסיסית בשיחה של חצי שעה.

מקורות

• Model Context Protocol — Specification
• Anthropic — Introducing the Model Context Protocol
• MCP — Authorization (OAuth 2.1)
• MCP TypeScript SDK on GitHub
• Awesome MCP Servers — קטלוג קהילתי
• Claude Desktop — MCP user guide
• Cursor — MCP integration docs
• Vercel AI SDK — MCP support