دليل عملي لإنشاء خوادم Model Context Protocol (MCP) للمنتجات SaaS

إذا كنت تتابع مساحة أدوات الذكاء الاصطناعي في عام 2025، فمن المحتمل أن تلاحظ أن Model Context Protocol (MCP) تطورت من "مواصفة مثيرة للاهتمام من Anthropic" إلى "شيء يحتاج كل منتج SaaS جاد إلى دعمه." ولسبب وجيه. يمنح MCP وكلاء الذكاء الاصطناعي -- Claude و assistants المستندة إلى GPT والوكلاء المخصصين -- طريقة موحدة لاكتشاف ناداء واستدعاء API الخاص بك. فكر فيها كـ OpenAPI لعصر الوكلاء، لكن مع الاتصال ثنائي الاتجاه في الوقت الفعلي مدمج فيه.

لقد قضيت الأشهر القليلة الماضية في بناء خوادم MCP لعدة منتجات SaaS، وأريد أن أشارك ما ينجح فعلاً، وما لا توضحه المستندات، والقرارات المعمارية التي تحدث فرقاً. هذا ليس إعادة صياغة للمواصفات. هذا هو الدليل الذي تمنيت أن أملكه عندما بدأت.

جدول المحتويات

• ما هو Model Context Protocol (MCP)؟
• لماذا يحتاج منتج SaaS الخاص بك إلى خادم MCP
• معمارية MCP: كيف تعمل فعلاً
• إعداد مشروع خادم MCP الخاص بك
• تعريف الأدوات والموارد والمطالبات
• الاتصال بـ SaaS API الخاص بك
• المصادقة والتعددية
• معالجة الأخطاء والتحقق
• اختبار خادم MCP الخاص بك
• النشر والاعتبارات الإنتاجية
• مثال من العالم الحقيقي: بناء خادم MCP لـ SaaS إدارة المشاريع
• الأسئلة الشائعة

ما هو Model Context Protocol (MCP)؟

MCP هي بروتوكول مفتوح أنشأته في الأصل Anthropic وتحدد كيفية تواصل نماذج الذكاء الاصطناعي مع الأدوات والمصادر الخارجية. تم إطلاقها في أواخر 2024 والوصول إلى استقرار v1.0 في أوائل 2025، وهي الآن مدعومة من قبل Claude Desktop و Cursor و Windsurf و OpenAI Agents SDK والعشرات من عملاء الذكاء الاصطناعي الآخرين.

الفكرة الأساسية: بدلاً من أن تكون كل تكامل ذكاء اصطناعي إضافة مخصصة بتنسيق مملوك، يوفر MCP بروتوكول واحد يمكن لأي عميل متوافق استخدامه لاكتشاف ما يقدمه الخدمة الخاصة بك والتفاعل معها.

إليك ما يحدده MCP:

• الأدوات -- الدوال التي يمكن للذكاء الاصطناعي استدعاؤها (مثل create_ticket و search_users و generate_report)
• الموارد -- البيانات التي يمكن للذكاء الاصطناعي قراءتها (مثل التوثيق وسجلات قاعدة البيانات وملفات الإعدادات)
• المطالبات -- قوالب مطالبات قابلة لإعادة الاستخدام يمكن لخادمك فضحها
• العينات -- القدرة على أن يطلب خادمك إكمالات LLM من العميل

تستخدم طبقة النقل JSON-RPC 2.0 إما عبر stdio (للخوادم المحلية) أو HTTP مع Server-Sent Events (SSE) للخوادم البعيدة. نقل Streamable HTTP الأحدث، الذي تم تقديمه في مراجعة المواصفات 2025-03، هو ما تريده لأي نشر SaaS إنتاجي.

لماذا يحتاج منتج SaaS الخاص بك إلى خادم MCP

دعني أكون صريحاً: إذا كان منتج SaaS الخاص بك يحتوي على API، فيجب عليك بناء خادم MCP الآن. إليك السبب.

وكلاء الذكاء الاصطناعي يصبحون مستهلكي API الأساسيين. في Q1 2025، أفادت Anthropic أن مستخدمي Claude Desktop يستدعون أدوات MCP أكثر من مليوني مرة يومياً. هذا الرقم ينمو بسرعة. عملاؤك يحاولون بالفعل استخدام وكلاء الذكاء الاصطناعي للتفاعل مع منتجك -- والسؤال هو ما إذا كنت تجعل ذلك سهلاً أو محبطاً.

إنها قناة توزيع. عندما يثبت شخص ما Claude Desktop ويكتب "ساعدني في إدارة مشاريعي"، يمكن للذكاء الاصطناعي اكتشاف واستخدام خوادم MCP التي قام المستخدم بتكوينها. يصبح منتجك في متناول اللغة الطبيعية. هذا ليس خدعة -- إنه سطح جديد حقيقي لمنتجك.

منافسوك يفعلون ذلك. Stripe و Linear و Notion و GitHub و Sentry و Supabase جميعاً أطلقوا خوادم MCP في النصف الأول من 2025. إذا كنت في B2B SaaS ولا تملك واحداً، فأنت تتخلف.

العامل	REST API فقط	REST API + خادم MCP
إمكانية الوصول للوكيل الذكي	يتطلب تكامل مخصص لكل وكيل	أي عميل MCP يعمل تلقائياً
الاكتشاف	يقرأ المطورون المستندات	يكتشف الذكاء الاصطناعي الإمكانيات في وقت التشغيل
الوقت حتى التكامل الأول	ساعات إلى أيام	دقائق
التفاعل باللغة الطبيعية	غير ممكن بدون غلاف	مدمج
عبء الصيانة	قاعدة أكواد واحدة	قاعدتا أكواد (لكن MCP تغلفها)

معمارية MCP: كيف تعمل فعلاً

قبل أن نكتب الأكواد، دعنا نصحح المعمارية. يتكون نشر MCP من ثلاثة أجزاء:

1. عميل MCP -- تطبيق الذكاء الاصطناعي (Claude Desktop و Cursor والوكيل المخصص الخاص بك). يكتشف إمكانيات خادمك ويستدعيها.
2. خادم MCP -- الأكواد الخاصة بك. يفضح الأدوات والموارد والمطالبات عبر بروتوكول MCP. هذا ما نبنيه.
3. SaaS API الخاص بك -- واجهة برمجة التطبيقات الفعلية الخاصة بك التي يستدعي خادم MCP الخاص بك للقيام بالأشياء.

يبدو التدفق كما يلي:

المستخدم → عميل الذكاء الاصطناعي → عميل MCP → خادم MCP → SaaS API الخاص بك
                                                      ↓
                                            يتدفق الرد للخلف

خادم MCP الخاص بك هو في الأساس محول بروتوكول. يترجم بين بروتوكول MCP (الذي يتحدثه عملاء الذكاء الاصطناعي) و API REST/GraphQL الموجود لديك. هذا يعني أنك لا تحتاج إلى تعديل API الموجود لديك على الإطلاق. يجلس خادم MCP بجانبه.

خيارات النقل

بالنسبة لمنتجات SaaS، لديك خياران واقعيان للنقل:

• Streamable HTTP (موصى به): يستخدم طلبات HTTP القياسية مع SSE اختياري للبث. يعمل خلف موازن الأحمال و CDNs والبنية التحتية القياسية. هذا ما تريده للخوادم البعيدة/المستضافة.
• SSE (القديم): نقل الخوادم البعيدة الأصلي. لا يزال يعمل لكن المواصفات توصي بـ Streamable HTTP للتطبيقات الجديدة.

نقل Stdio رائع للأدوات المحلية لكنه غير قابل للتطبيق لخادم MCP لمنتج SaaS.

إعداد مشروع خادم MCP الخاص بك

دعنا نبني هذا مع TypeScript. الحزمة الرسمية @modelcontextprotocol/sdk محفوظة بشكل جيد وهي الخيار الصحيح للاستخدام الإنتاجي. Python لديها mcp (مجموعة أدوات Python الرسمية) إذا كان هذا هو الخيار الخاص بك، لكنني سأركز على TypeScript لأن معظم backends SaaS التي أعمل معها تستخدم Node.js.

mkdir my-saas-mcp-server
cd my-saas-mcp-server
npm init -y
npm install @modelcontextprotocol/sdk zod express
npm install -D typescript @types/node @types/express tsx

قم بإعداد tsconfig.json الخاص بك:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "Node16",
    "moduleResolution": "Node16",
    "outDir": "./dist",
    "rootDir": "./src",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true
  },
  "include": ["src/**/*"]
}

الآن دعنا ننشئ البنية الأساسية للخادم:

// src/server.ts
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";
import express from "express";

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

const server = new McpServer({
  name: "my-saas-mcp",
  version: "1.0.0",
  description: "MCP server for My SaaS Product",
});

// سنضيف أدوات وموارد ومطالبات هنا

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

app.get("/mcp", async (req, res) => {
  // نقطة نهاية SSE لاستجابات البث
  const transport = new StreamableHTTPServerTransport({
    sessionIdGenerator: () => crypto.randomUUID(),
  });
  
  await server.connect(transport);
  await transport.handleRequest(req, res);
});

const PORT = process.env.PORT || 3001;
app.listen(PORT, () => {
  console.log(`MCP server running on port ${PORT}`);
});

هذا هو الهيكل الأساسي الخاص بك. دعنا نملأه.

تعريف الأدوات والموارد والمطالبات

الأدوات

الأدوات هي الأولوية الأكثر أهمية. كل أداة هي دالة يمكن للذكاء الاصطناعي استدعاؤها مع معاملات منظمة. إليك كيفية تعريف واحدة:

import { z } from "zod";

server.tool(
  "create_project",
  "Create a new project in the workspace",
  {
    name: z.string().describe("The project name"),
    description: z.string().optional().describe("Project description"),
    team_id: z.string().describe("ID of the team that owns this project"),
  },
  async ({ name, description, team_id }) => {
    // استدع SaaS API الخاص بك هنا
    const project = await apiClient.createProject({ name, description, team_id });
    
    return {
      content: [
        {
          type: "text",
          text: JSON.stringify(project, null, 2),
        },
      ],
    };
  }
);

عدد من الأشياء التي تعلمتها عن تصميم الأدوات:

كن محدداً مع الأوصاف. يستخدم الذكاء الاصطناعي وصف الأداة الخاصة بك وأوصاف المعاملات لتقرر متى وكيفية استدعاؤها. الأوصاف الغامضة تؤدي إلى اختيار أداة خاطئ. "إنشاء مشروع جديد" حسناً. "أنشئ مشروع جديد في مساحة عمل المستخدم. يتطلب team_id التي يمكن الحصول عليها من أداة list_teams" أفضل بكثير.

حافظ على عدد الأدوات قابلاً للإدارة. رأيت أشخاصاً يكشفون 50+ أداة ويتساءلون لماذا يرتبك الذكاء الاصطناعي. ابدأ بـ 10-15 عمليات أساسية. يمكنك دائماً إضافة المزيد.

أرجع بيانات منظمة. أرجع دائماً JSON في محتوى نصك. يحللها الذكاء الاصطناعي بشكل أفضل من الرثاء.

الموارد

الموارد توفر بيانات قابلة للقراءة. فكر فيها كنقاط نهاية GET لاستهلاك الذكاء الاصطناعي:

server.resource(
  "project-list",
  "projects://list",
  "List of all projects in the workspace",
  async () => {
    const projects = await apiClient.listProjects();
    return {
      contents: [
        {
          uri: "projects://list",
          mimeType: "application/json",
          text: JSON.stringify(projects, null, 2),
        },
      ],
    };
  }
);

المطالبات

المطالبات هي قوالب قابلة لإعادة الاستخدام. هي مستخدمة بشكل ناقص لكنها قوية:

server.prompt(
  "weekly-report",
  "Generate a weekly status report for a project",
  {
    project_id: z.string().describe("The project ID to report on"),
  },
  async ({ project_id }) => {
    const stats = await apiClient.getProjectStats(project_id);
    return {
      messages: [
        {
          role: "user",
          content: {
            type: "text",
            text: `Generate a weekly status report based on this data: ${JSON.stringify(stats)}. Include completed tasks, blockers, and upcoming deadlines.`,
          },
        },
      ],
    };
  }
);

الاتصال بـ SaaS API الخاص بك

يحتاج خادم MCP الخاص بك إلى التحدث إلى API الموجود لديك. أنصح بإنشاء فئة عميل API بنوع:

// src/api-client.ts
class SaaSApiClient {
  private baseUrl: string;
  private apiKey: string;

  constructor(baseUrl: string, apiKey: string) {
    this.baseUrl = baseUrl;
    this.apiKey = apiKey;
  }

  private async request<T>(path: string, options?: RequestInit): Promise<T> {
    const response = await fetch(`${this.baseUrl}${path}`, {
      ...options,
      headers: {
        "Authorization": `Bearer ${this.apiKey}`,
        "Content-Type": "application/json",
        ...options?.headers,
      },
    });

    if (!response.ok) {
      const error = await response.text();
      throw new Error(`API error ${response.status}: ${error}`);
    }

    return response.json() as T;
  }

  async createProject(data: CreateProjectInput): Promise<Project> {
    return this.request<Project>("/api/v1/projects", {
      method: "POST",
      body: JSON.stringify(data),
    });
  }

  async listProjects(): Promise<Project[]> {
    return this.request<Project[]>("/api/v1/projects");
  }

  // ... المزيد من الطرق
}

حافظ على هذا العميل رقيقاً. إنه تمرير، وليس طبقة منطق العمل.

المصادقة والتعددية

هنا حيث تصبح الأمور مثيرة للاهتمام -- وحيث تتغاضى معظم البرامج التعليمية عن الأجزاء الصعبة.

يحتاج خادم MCP الخاص بك إلى المصادقة في طريقتين:

1. عميل MCP يوثق نفسه لخادم MCP الخاص بك ("هل هذا مستخدم صالح؟")
2. خادم MCP الخاص بك يوثق SaaS API الخاص به ("تصرف بالنيابة عن هذا المستخدم")

OAuth 2.0 (موصى به للإنتاج)

تتضمن مواصفات MCP إطار عمل تفويض قائم على OAuth 2.1. لمنتج SaaS، هذا هو النهج الصحيح:

// Middleware لاستخراج والتحقق من رمز OAuth
app.use("/mcp", async (req, res, next) => {
  const authHeader = req.headers.authorization;
  if (!authHeader?.startsWith("Bearer ")) {
    return res.status(401).json({ error: "Missing authorization" });
  }

  const token = authHeader.slice(7);
  
  try {
    const user = await validateOAuthToken(token);
    req.user = user;
    next();
  } catch {
    return res.status(401).json({ error: "Invalid token" });
  }
});

ثم مرر سياق المستخدم في معالجات الأدوات الخاصة بك. هذا حرج لـ multi-tenancy -- كل استدعاء API يجب أن يكون محدوداً بمساحة عمل المستخدم المصرح.

نهج مفتاح API (أبسط، للاستخدام الداخلي/المرحلة المبكرة)

إذا كنت في المرحلة المبكرة أو كان هذا داخليًا فقط، فإن مفاتيح API تعمل بشكل جيد:

const apiKey = req.headers["x-api-key"] as string;
const client = new SaaSApiClient(process.env.API_BASE_URL!, apiKey);

يوفر المستخدم مفتاح API الخاص به عند تكوين خادم MCP في العميل الخاص به، ويتم تمريره إلى API الخاص بك.

معالجة الأخطاء والتحقق

وكلاء الذكاء الاصطناعي يحتاجون إلى رسائل خطأ واضحة. عندما تفشل أداة، يحتاج الذكاء الاصطناعي إلى فهم السبب حتى يتمكن من إما إصلاح المدخل أو شرح المشكلة للمستخدم.

server.tool(
  "get_project",
  "Get project details by ID",
  { project_id: z.string().uuid().describe("The project's UUID") },
  async ({ project_id }) => {
    try {
      const project = await apiClient.getProject(project_id);
      return {
        content: [{ type: "text", text: JSON.stringify(project, null, 2) }],
      };
    } catch (error) {
      const message = error instanceof Error ? error.message : "Unknown error";
      return {
        isError: true,
        content: [
          {
            type: "text",
            text: `Failed to get project: ${message}. Make sure the project_id is a valid UUID and the project exists in your workspace.`,
          },
        ],
      };
    }
  }
);

لاحظ العلم isError: true. يخبر هذا عميل الذكاء الاصطناعي أن استدعاء الأداة فشل، لذا يمكنه التعامل معه بشكل مناسب. قم دائماً بتضمين إرشادات قابلة للتنفيذ في رسائل الخطأ.

اختبار خادم MCP الخاص بك

أصبح اختبار خوادم MCP أسهل كثيراً في 2025. إليك خياراتك:

مفتش MCP

مفتش MCP الرسمي هو أفضل صديق لك أثناء التطوير:

npx @modelcontextprotocol/inspector

يعطيك واجهة ويب حيث يمكنك الاتصال بخادمك، واستعراض الأدوات/الموارد، واستدعاؤها بشكل تفاعلي. استخدمه باستمرار.

الاختبار الآلي

للـ CI/CD، اختبر أدواتك كدوال async عادية:

import { describe, it, expect } from "vitest";

describe("create_project tool", () => {
  it("should create a project with valid input", async () => {
    const result = await createProjectHandler({
      name: "Test Project",
      team_id: "team-123",
    });

    expect(result.isError).toBeUndefined();
    const data = JSON.parse(result.content[0].text);
    expect(data.name).toBe("Test Project");
  });

  it("should return error for missing team_id", async () => {
    // يجب أن يقبض التحقق من Zod هذا قبل تشغيل المعالج
    // اختبر طبقة التحقق
  });
});

اختبار التكامل مع Claude Desktop

بمجرد تشغيل الخادم الخاص بك، أضفه إلى إعدادات Claude Desktop:

{
  "mcpServers": {
    "my-saas": {
      "url": "http://localhost:3001/mcp",
      "headers": {
        "Authorization": "Bearer your-test-token"
      }
    }
  }
}

ثم فقط تحدث إلى Claude وحاول استخدام أدواتك بشكل طبيعي. ستجد بسرعة الحالات الحدية التي تفتقدها الاختبارات الآلية.

النشر والاعتبارات الإنتاجية

مكان النشر

خادم MCP الخاص بك هو مجرد تطبيق Express. نشره أينما تنشر خدمات Node.js. بعض الخيارات الجيدة:

المنصة	بدء البرد	التكلفة (est.)	الأفضل لـ
Railway	لا شيء	~$5-20/mo	SaaS صغير متوسط
Fly.io	<500ms	~$5-15/mo	التوزيع العالمي
AWS ECS/Fargate	لا شيء	~$15-50/mo	الشركات، AWS الموجودة
Vercel (Edge)	<100ms	$0-20/mo	إذا كنت بالفعل على Vercel
Cloudflare Workers	<5ms	$0-5/mo	حرج الأداء

تحديد معدل

وكلاء الذكاء الاصطناعي قد يكونون يثرثرون. قد تؤدي محادثة مستخدم واحدة إلى تشغيل 20-30 استدعاء أداة. تنفيذ تحديد معدل سخي بما يكفي لاستخدام الذكاء الاصطناعي الطبيعي لكن يمنع الإساءة:

import rateLimit from "express-rate-limit";

const limiter = rateLimit({
  windowMs: 60 * 1000, // 1 دقيقة
  max: 60, // 60 طلب لكل دقيقة لكل مستخدم
  keyGenerator: (req) => req.user?.id || req.ip,
});

app.use("/mcp", limiter);

المراقبة

سجل كل استدعاء أداة مع معرف المستخدم واسم الأداة والكمون. تريد الرؤية في الأدوات الأكثر استخداماً وأكثرها فشلاً وأين اختناقات الكمون. Datadog و Axiom أو حتى سجلات JSON منظمة إلى CloudWatch تعمل بشكل جيد.

الإصدار

سيتطور خادم MCP الخاص بك. استخدم حقل version في بيانات خادمك وفكر في تشغيل عدة إصدارات خلف بادئة المسار (/mcp/v1 و /mcp/v2) أثناء الانتقالات.

مثال من العالم الحقيقي: بناء خادم MCP لـ SaaS إدارة المشاريع

دعني أمر عبر مثال حقيقي. لنقل أنك تبني خادم MCP لأداة إدارة مشاريع (فكر في Linear أو Asana المبسطة).

إليك مجموعة الأدوات التي سأكشفها:

// أدوات CRUD الأساسية
server.tool("list_projects", ...);
server.tool("get_project", ...);
server.tool("create_project", ...);
server.tool("update_project", ...);

// إدارة المهام
server.tool("list_tasks", ...);  // مع مرشحات للحالة والمُعين والمشروع
server.tool("create_task", ...);
server.tool("update_task", ...); // حالة التحديث والمُعين والأولوية
server.tool("add_comment", ...);

// البحث والتقارير
server.tool("search", ...);      // البحث النصي الكامل عبر المشاريع والمهام
server.tool("get_project_stats", ...); // إحصائيات الملخص لمشروع

// الموارد
server.resource("workspace-info", ...); // تكوين مساحة العمل وأعضاء الفريق

// المطالبات
server.prompt("standup-report", ...);   // إنشاء تقرير standup من النشاط الأخير
server.prompt("sprint-planning", ...);  // المساعدة في تخطيط sprint

هذا 12 أداة و 1 مورد و 2 مطالبة. كافية لتكون مفيدة حقاً دون إرباك اختيار أداة الذكاء الاصطناعي.

تبدو تجربة المستخدم على النحو التالي: يفتح شخص ما Claude Desktop ويقول "ما المهام المتأخرة في مشروع Backend Rewrite؟" Claude يستدعي list_tasks مع مرشح الحالة واسم المشروع، يحصل على النتائج، ويقدمها باللغة الطبيعية. يقول المستخدم "عين مهمة المصادقة لـ Sarah وارفعها إلى أولوية عالية." Claude يستدعي update_task. يشعر وكأنه سحر، وهو في الواقع مجرد سباكة البروتوكول.

إذا كنت تبني شيئاً مثل هذا وتريد المساعدة مع واجهة أمامية Next.js أو طبقة CMS بدون رأس التي غالباً ما تصاحب هذه المشاريع، هذا شيء نفعله كثيراً في Social Animal. لكن خادم MCP نفسه؟ هذا شيء يمكنك بالتأكيد بناؤه داخلياً باستخدام هذا الدليل.

الأسئلة الشائعة

ما الفرق بين MCP واستدعاء الدالة؟ استدعاء الدالة (مثل استدعاء الدالة من OpenAI أو استخدام الأداة من Claude) هو كيف يقرر نموذج ذكاء اصطناعي استدعاء دالة ضمن استدعاء API واحد. MCP هي البروتوكول الذي يسمح لعميل ذكاء اصطناعي باكتشاف ما الدوال المتاحة من الخوادم الخارجية. يعملان معاً -- يستخدم عميل الذكاء الاصطناعي استدعاء الدالة داخلياً لتقرير متى يستدعي أداة MCP. فكر في MCP كسباكة بين الأنظمة، واستدعاء الدالة كعملية صنع القرار للنموذج.

كم تكلفة بناء وتشغيل خادم MCP؟ الخادم نفسه خفيف الوزن. بالنسبة لمنتج SaaS نموذجي يحتوي على 10-20 أداة، تنظر إلى بضع مئات من أسطر TypeScript. تكاليف الاستضافة من $5-50/الشهر اعتماداً على الحركة والمنصة. التكلفة الحقيقية هي وقت المطور -- ميزانية 2-4 أسابيع لخادم MCP بجودة الإنتاج مع المصادقة ومعالجة الأخطاء والمراقبة والاختبارات. إذا بدا الأمر محفوفاً بالمخاطر، فقد ساعدنا فريق في شحن هذه بشكل أسرع. تحقق من صفحة التسعير للحصول على التفاصيل.

هل يمكنني استخدام Python بدلاً من TypeScript؟ بالتأكيد. مجموعة أدوات Python الرسمية (pip install mcp) ممتازة وربما لديها ergonomics أفضل لتعريفات الأدوات. استخدم أياً كان فريقك يعرفه. البروتوكول لا يعتمد على اللغة. إذا كان backend SaaS الخاص بك Python (Django و FastAPI)، فإن بناء خادم MCP في Python يكون أكثر منطقية حيث يمكنك مشاركة النماذج ومنطق التحقق.

هل أحتاج إلى تعديل API الموجود لدي؟ لا. خادم MCP الخاص بك هو خدمة منفصلة تستدعي API الموجود لديك. إنه طبقة محول. أي أنك قد تجد نفسك تريد إضافة عدد من نقاط النهاية في API خصيصاً لاستهلاك الذكاء الاصطناعي -- مثل نقطة نهاية البحث التي تعيد سياق أكثر من احتياجات واجهة المستخدم الخاصة بك. هذا حسن. لكن إضافي، وليس تعديل.

كيف أتعامل مع العمليات طويلة الأجل؟ قد تؤدي بعض الأدوات إلى تشغيل عمليات تستغرق دقائق (مثل إنشاء تقرير أو معالجة استيراد كبير). استخدم ميزة إخطار التقدم في MCP للحفاظ على اطلاع العميل. يمكن لمعالج الأداة الخاصة بك إرسال تحديثات التقدم أثناء انتظار العملية المكتملة. بالنسبة للعمليات الطويلة جداً (>30 ثانية)، فكر في الإرجاع الفوري برقم وظيفة وتوفير أداة منفصلة check_job_status.

هل MCP مستقرة بما يكفي للإنتاج؟ نعم، اعتباراً من منتصف 2025. وصلت المواصفات إلى v1.0 في مارس 2025، والمراجعة 2025-03-26 (التي أضافت Streamable HTTP) هي ما اعتمدته العملاء الرئيسيين. Anthropic و Microsoft و Google و OpenAI جميعاً يستثمرون في البروتوكول. لن يختفي. أي أنه قد تبقى مراقب لتحديثات المواصفات -- هناك اقتراحات نشطة حول تدفقات المصادقة الأفضل والاتصال بين الخوادم والخوادم.

ما أفضل طريقة للتعامل مع الترقيم في أدوات MCP؟ أرجع صفحة معقولة من النتائج (20-50 عنصر) بشكل افتراضي، واقبل معاملات cursor أو page. قم بتضمين بيانات الترقيم في الاستجابة حتى يعرف الذكاء الاصطناعي أن هناك المزيد من النتائج. شيء مثل: { results: [...], next_cursor: "abc123", total_count: 342 }. سيسأل الذكاء الاصطناعي بشكل طبيعي الصفحة التالية إذا احتاج المستخدم إلى بيانات أكثر.

هل يمكن لخادم MCP واحد أن يدعم عملاء الذكاء الاصطناعي المتعددين في نفس الوقت؟ نعم، ويجب أن يفعل. خادم MCP الخاص بك هو مجرد خادم HTTP يتعامل مع الطلبات المتزامنة. يتضمن كل طلب رمز المصادقة للمستخدم، لذا تقتصر كل شيء على المستأجر الصحيح. لا توجد حالة محددة العميل للقلق بشأنها إذا كنت تستخدم نقل Streamable HTTP بشكل صحيح. تعامل معها مثل أي خادم API بدون حالة أخرى.