آموزش و راهنما

MCP Server Discovery چیست؟ آموزش server/discover و حذف initialize

در نسخه ۲۰۲۶ پروتکل MCP، متد server/discover جایگزین مهمی برای شناسایی اولیه Server است. در این راهنما ساختار پیام‌ها، حذف initialize و کاربرد Discovery در AI Agentهای متصل به API درواره را بررسی می‌کنیم.

پیش از آنکه یک AI Agent بتواند از MCP Server استفاده کند، باید بداند Server چه قابلیت‌هایی دارد.

آیا Server ابزار ارائه می‌کند؟ آیا Resource دارد؟ از Prompt پشتیبانی می‌کند؟ کدام نسخه‌های پروتکل را می‌شناسد؟ آیا Extension خاصی مانند MCP Tasks فعال است؟

در نسخه‌های قدیمی Model Context Protocol یا MCP، این اطلاعات هنگام اجرای فرایند initialize میان Client و Server مبادله می‌شد. پس از آن، Client باید Session ایجادشده را در درخواست‌های بعدی حفظ می‌کرد.

اما در نسخه 2026-07-28، معماری MCP تغییر کرد:

فرایند initialize و notifications/initialized حذف شد.
پروتکل در سطح ارتباط Stateless شد.
هدر Mcp-Session-Id حذف شد.
اطلاعات Client در هر درخواست ارسال می‌شود.
متد جدید server/discover برای شناسایی Server معرفی شد.

قابلیت Server Discovery به Client اجازه می‌دهد نسخه‌ها، قابلیت‌ها و هویت MCP Server را پیش از فراخوانی Tool یا Resource دریافت کند.

MCP Server Discovery چیست؟

Server Discovery فرایندی است که در آن MCP Client درباره یک Server اطلاعات اولیه دریافت می‌کند.

در نسخه جدید MCP این کار با متد زیر انجام می‌شود:

server/discover

پاسخ این متد می‌تواند شامل اطلاعات زیر باشد:

نسخه‌های پشتیبانی‌شده پروتکل
قابلیت‌های Server
نام Server
نسخه نرم‌افزار Server
توضیحات مربوط به نحوه استفاده
Extensionهای فعال
مدت اعتبار پاسخ برای Cache
عمومی یا خصوصی بودن Cache

تمام MCP Serverهای سازگار با نسخه 2026-07-28 باید متد server/discover را پیاده‌سازی کنند.

بااین‌حال، فراخوانی این متد برای Client همیشه اجباری نیست. Client می‌تواند مستقیماً یک عملیات مانند tools/list یا tools/call را اجرا و خطای ناسازگاری نسخه را مدیریت کند.

معماری قدیمی MCP چگونه بود؟

در نسخه‌های مبتنی بر سال ۲۰۲۵، ارتباط معمولاً با درخواست initialize آغاز می‌شد.

Client اطلاعات خود را ارسال می‌کرد:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {},
    "clientInfo": {
      "name": "darvareh-agent",
      "version": "1.0.0"
    }
  }
}

Server نسخه انتخاب‌شده و قابلیت‌های خود را برمی‌گرداند. سپس Client یک Notification با نام notifications/initialized ارسال می‌کرد.

در Streamable HTTP، Server ممکن بود یک Session ID نیز ایجاد کند:

Mcp-Session-Id: example-session-id

Client باید این شناسه را در درخواست‌های بعدی ارسال می‌کرد.

این معماری برای Serverهای Local مناسب بود، اما در زیرساخت‌های توزیع‌شده مشکلاتی ایجاد می‌کرد:

وابستگی درخواست‌ها به Session
نیاز به Sticky Session
پیچیدگی اجرای چند Instance
نیاز احتمالی به Session Store مشترک
دشواری بازیابی پس از قطع اتصال
وابستگی اطلاعات قابلیت‌ها به Handshake قبلی

نسخه جدید MCP این وابستگی را از سطح Protocol حذف کرده است.

معماری جدید MCP چگونه کار می‌کند؟

در نسخه 2026-07-28 هر درخواست اطلاعات لازم برای پردازش خود را همراه دارد.

اطلاعاتی مانند این موارد در _meta درخواست قرار می‌گیرند:

نسخه پروتکل
نام و نسخه Client
قابلیت‌های Client
Extensionهای پشتیبانی‌شده
تنظیمات مرتبط با همان درخواست

بنابراین Server نباید فرض کند یک درخواست به Handshake یا درخواست قبلی وابسته است.

یک درخواست مستقل می‌تواند به این شکل باشد:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "darvareh-agent",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

هر Instance سازگار از MCP Server می‌تواند این درخواست را پردازش کند و نیازی به دسترسی به Session قبلی ندارد.

درخواست server/discover

درخواست Discovery پارامتر عملیاتی خاصی ندارد. اطلاعات استاندارد Client در _meta ارسال می‌شوند:

{
  "jsonrpc": "2.0",
  "id": "discover-1",
  "method": "server/discover",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "darvareh-agent",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

این درخواست اعلام می‌کند Client ترجیح می‌دهد با نسخه 2026-07-28 ارتباط برقرار کند.

Server می‌تواند همان نسخه را بپذیرد یا نسخه‌های پشتیبانی‌شده خود را اعلام کند.

پاسخ server/discover

یک پاسخ کامل می‌تواند به این شکل باشد:

{
  "jsonrpc": "2.0",
  "id": "discover-1",
  "result": {
    "resultType": "complete",
    "supportedVersions": [
      "2026-07-28"
    ],
    "capabilities": {
      "tools": {},
      "resources": {}
    },
    "_meta": {
      "io.modelcontextprotocol/serverInfo": {
        "name": "Darvareh Content Tools",
        "version": "1.0.0"
      }
    },
    "instructions": "این Server ابزارهای خلاصه‌سازی، استخراج اطلاعات و تولید گزارش را ارائه می‌کند.",
    "ttlMs": 3600000,
    "cacheScope": "public"
  }
}

اکنون Client می‌داند:

Server از نسخه 2026-07-28 پشتیبانی می‌کند.
قابلیت Tools فعال است.
قابلیت Resources فعال است.
نام Server مشخص است.
پاسخ Discovery برای مدتی قابل Cache است.
اطلاعات برای همه کاربران یکسان است.

supportedVersions چیست؟

فیلد supportedVersions فهرست نسخه‌هایی است که Server می‌تواند پردازش کند:

{
  "supportedVersions": [
    "2026-07-28"
  ]
}

یک Server دارای سازگاری گسترده‌تر ممکن است چند نسخه را اعلام کند:

{
  "supportedVersions": [
    "2026-07-28",
    "2025-11-25"
  ]
}

Client باید نسخه‌ای را انتخاب کند که هر دو طرف پشتیبانی می‌کنند.

اگر نسخه مشترکی وجود نداشته باشد، Client نباید درخواست را با ساختاری نامشخص ادامه دهد.

capabilities چیست؟

فیلد capabilities قابلیت‌های MCP Server را اعلام می‌کند.

برای مثال:

{
  "capabilities": {
    "tools": {},
    "resources": {},
    "prompts": {}
  }
}

این پاسخ نشان می‌دهد Server از سه قابلیت اصلی پشتیبانی می‌کند:

Tools
Resources
Prompts

Client می‌تواند براساس این اطلاعات رابط کاربری خود را آماده کند یا عملیات موردنیاز را فراخوانی کند.

برای مثال:

اگر tools فعال باشد، Client می‌تواند tools/list را اجرا کند.
اگر resources فعال باشد، Client می‌تواند Resourceها را نمایش دهد.
اگر prompts فعال باشد، Client می‌تواند Promptهای Server را دریافت کند.

Discovery فهرست کامل Toolها یا Resourceها را برنمی‌گرداند. برای دریافت جزئیات همچنان باید متدهای مخصوص آن‌ها فراخوانی شوند:

tools/list
resources/list
prompts/list

چرا Discovery جایگزین tools/list نیست؟

server/discover نمایی کلی از Server ارائه می‌کند، اما tools/list جزئیات هر Tool را برمی‌گرداند.

پاسخ Discovery ممکن است فقط اعلام کند:

{
  "capabilities": {
    "tools": {}
  }
}

اما پاسخ tools/list شامل این اطلاعات است:

نام Tool
عنوان
توضیحات
Input Schema
Output Schema
Annotationها
آیکون‌ها
مشخصات موردنیاز برای فراخوانی

بنابراین جریان مناسب می‌تواند چنین باشد:

فراخوانی server/discover
بررسی قابلیت tools
فراخوانی tools/list
انتخاب Tool مناسب
فراخوانی tools/call

اگر Client از قبل می‌داند Server فقط برای یک Tool مشخص استفاده می‌شود، می‌تواند Discovery را کنار بگذارد و مستقیماً همان Tool را فراخوانی کند.

serverInfo چیست؟

Server می‌تواند نام و نسخه نرم‌افزار خود را در _meta پاسخ قرار دهد:

{
  "_meta": {
    "io.modelcontextprotocol/serverInfo": {
      "name": "Darvareh Content Tools",
      "version": "1.0.0"
    }
  }
}

این اطلاعات برای موارد زیر مفید است:

نمایش نام Server به کاربر
Logging
عیب‌یابی
مانیتورینگ نسخه‌ها
تشخیص Serverهای قدیمی
مدیریت فهرست Integrationها

اطلاعات serverInfo توسط خود Server اعلام می‌شوند و پروتکل آن‌ها را تأیید نمی‌کند. بنابراین Client نباید تصمیم‌های حساس خود را صرفاً براساس نام یا نسخه ادعاشده Server بگیرد.

instructions چیست؟

Server می‌تواند یک توضیح طبیعی درباره نحوه استفاده ارائه کند:

{
  "instructions": "از ابزار summarize برای خلاصه‌سازی اسناد فارسی استفاده کنید."
}

این توضیحات ممکن است توسط Host یا مدل زبانی خوانده شوند تا استفاده مناسب‌تری از Server داشته باشند.

یک instructions مناسب می‌تواند توضیح دهد:

Server برای چه کاری ساخته شده است.
چه نوع داده‌هایی را پردازش می‌کند.
چه Toolهایی باید در اولویت باشند.
چه محدودیت‌هایی وجود دارد.
چه زمانی نباید از Server استفاده کرد.
خروجی‌ها با چه زبان یا قالبی ارائه می‌شوند.

متن Instructions باید کوتاه، دقیق و عملیاتی باشد.

نمونه مناسب:

این Server ابزارهای تحلیل اسناد فارسی را ارائه می‌کند. برای خلاصه‌سازی از summarize_document و برای استخراج داده ساختاریافته از extract_fields استفاده کنید. پیش از فراخوانی، زبان و نوع خروجی را مشخص کنید.

نمونه نامناسب:

این بهترین و قدرتمندترین Server جهان است و می‌تواند همه کارها را انجام دهد.

Instructions مبهم به Agent برای انتخاب Tool مناسب کمکی نمی‌کند.

معرفی Extensionها در Discovery

نسخه جدید MCP دارای چارچوب رسمی Extension است.

Server می‌تواند Extensionهای پشتیبانی‌شده را در Capabilities اعلام کند:

{
  "capabilities": {
    "tools": {},
    "extensions": {
      "io.modelcontextprotocol/tasks": {}
    }
  }
}

این پاسخ نشان می‌دهد Server علاوه بر Tools، از Extension مربوط به MCP Tasks نیز پشتیبانی می‌کند.

Client باید بررسی کند خودش نیز Extension موردنظر را می‌شناسد. فعال‌بودن یک Extension فقط در Server برای استفاده از آن کافی نیست.

اگر Client از Extension پشتیبانی نکند، باید:

به رفتار Core Protocol بازگردد؛ یا
درخواست را با خطای مناسب متوقف کند.

رفتار دقیق Fallback به همان Extension بستگی دارد.

حذف initialize چه مزیتی دارد؟

حذف Handshake اولیه فقط یک تغییر در نام متدها نیست. این تصمیم معماری MCP را تغییر داده است.

حذف وابستگی به Session

هر درخواست اطلاعات نسخه و قابلیت‌های Client را همراه دارد. Server مجبور نیست Session قبلی را پیدا کند.

اجرای ساده‌تر پشت Load Balancer

درخواست اول می‌تواند توسط Instance اول و درخواست بعدی توسط Instance دوم پردازش شود.

حذف Sticky Session

Load Balancer مجبور نیست تمام درخواست‌های یک Client را به Server مشخصی بفرستد.

بازیابی ساده‌تر پس از خطا

اگر یک Instance از دسترس خارج شود، درخواست بعدی می‌تواند به Instance دیگری ارسال شود.

مناسب‌تر برای Serverless

هر درخواست می‌تواند در یک اجرای مستقل پردازش شود.

مشاهده‌پذیری بهتر

نسخه پروتکل، نام Client و قابلیت‌های آن همراه هر درخواست ثبت می‌شوند و برای تحلیل ترافیک به State قبلی نیاز نیست.

Stateless بودن به معنی بدون State بودن برنامه نیست

حذف Session پروتکل به این معنی نیست که MCP Server نمی‌تواند Workflow چندمرحله‌ای یا داده دائمی داشته باشد.

برنامه همچنان می‌تواند State خود را در Database، Cache یا Storage نگه دارد.

تفاوت در این است که State باید با یک شناسه صریح مدیریت شود.

برای مثال، یک Tool می‌تواند Workspace ایجاد کند:

{
  "name": "create_workspace",
  "arguments": {
    "title": "تحلیل قرارداد"
  }
}

Server یک شناسه برمی‌گرداند:

{
  "workspace_id": "ws_12345"
}

Toolهای بعدی باید این شناسه را به‌صورت صریح دریافت کنند:

{
  "name": "analyze_document",
  "arguments": {
    "workspace_id": "ws_12345",
    "document": "..."
  }
}

در این معماری، State وجود دارد اما به اتصال شبکه یا Session پنهان وابسته نیست.

استفاده از server/discover در یک MCP Client

یک Client ساده می‌تواند درخواست Discovery را با HTTP ارسال کند.

نمونه Python:

import os

import httpx

MCP_SERVER_URL = os.environ["MCP_SERVER_URL"]


async def discover_mcp_server() -> dict:
    payload = {
        "jsonrpc": "2.0",
        "id": "discover-1",
        "method": "server/discover",
        "params": {
            "_meta": {
                "io.modelcontextprotocol/protocolVersion": "2026-07-28",
                "io.modelcontextprotocol/clientInfo": {
                    "name": "darvareh-agent",
                    "version": "1.0.0",
                },
                "io.modelcontextprotocol/clientCapabilities": {},
            }
        },
    }

    headers = {
        "Content-Type": "application/json",
        "Accept": "application/json, text/event-stream",
        "MCP-Protocol-Version": "2026-07-28",
        "Mcp-Method": "server/discover",
    }

    async with httpx.AsyncClient(timeout=20) as client:
        response = await client.post(
            MCP_SERVER_URL,
            json=payload,
            headers=headers,
        )
        response.raise_for_status()
        return response.json()

در این نمونه، درخواست مستقیماً به Endpoint مربوط به MCP Server ارسال می‌شود.

در پروژه واقعی باید هر دو نوع پاسخ زیر را در نظر بگیرید:

application/json
text/event-stream

Server می‌تواند پاسخ را به‌صورت JSON معمولی یا SSE مرتبط با همان درخواست برگرداند.

پردازش نتیجه Discovery

پس از دریافت پاسخ، Client باید ساختار نتیجه را بررسی کند:

SUPPORTED_PROTOCOL_VERSION = "2026-07-28"


def parse_discovery_response(response: dict) -> dict:
    if "error" in response:
        raise RuntimeError(response["error"])

    result = response.get("result", {})

    if result.get("resultType") != "complete":
        raise RuntimeError("Unexpected discovery result type")

    supported_versions = result.get("supportedVersions", [])

    if SUPPORTED_PROTOCOL_VERSION not in supported_versions:
        raise RuntimeError("No compatible MCP protocol version")

    return {
        "server_info": result.get("_meta", {}).get(
            "io.modelcontextprotocol/serverInfo",
            {},
        ),
        "capabilities": result.get("capabilities", {}),
        "instructions": result.get("instructions"),
        "ttl_ms": result.get("ttlMs", 0),
        "cache_scope": result.get("cacheScope"),
    }

سپس Client می‌تواند قابلیت‌های Server را بررسی کند:

discovery = parse_discovery_response(response)

capabilities = discovery["capabilities"]

if "tools" in capabilities:
    print("Tools are supported")

if "resources" in capabilities:
    print("Resources are supported")

if "prompts" in capabilities:
    print("Prompts are supported")

Cache کردن پاسخ Discovery

پاسخ server/discover از نتایج قابل Cache در نسخه جدید MCP است.

Server باید دو مقدار مهم را اعلام کند:

{
  "ttlMs": 3600000,
  "cacheScope": "public"
}

ttlMs

فیلد ttlMs مشخص می‌کند Client تا چه مدت می‌تواند پاسخ را تازه در نظر بگیرد.

اگر مقدار صفر باشد، Client باید پاسخ را بلافاصله Stale در نظر بگیرد.

اگر Server قابلیت‌های ثابتی دارد، می‌تواند TTL طولانی‌تری انتخاب کند. اگر قابلیت‌ها براساس تنظیمات یا نسخه استقرار مرتب تغییر می‌کنند، TTL کوتاه‌تر مناسب‌تر است.

cacheScope

مقدار cacheScope می‌تواند یکی از این دو حالت باشد:

public
private

public یعنی پاسخ برای کاربران مختلف یکسان است و می‌تواند در Cache مشترک ذخیره شود.

private یعنی پاسخ ممکن است براساس کاربر، Token یا سطح دسترسی متفاوت باشد و نباید میان Authorization Contextهای مختلف به اشتراک گذاشته شود.

برای مثال، اگر کاربران سازمانی Toolهای متفاوتی مشاهده می‌کنند، Discovery باید با Scope خصوصی Cache شود.

چه زمانی server/discover را فراخوانی کنیم؟

فراخوانی Discovery در این سناریوها مفید است:

Client به Serverهای مختلف و ناشناخته متصل می‌شود.
رابط کاربری باید قابلیت‌های Server را نمایش دهد.
Client باید قبل از استفاده، سازگاری نسخه را بررسی کند.
Server ممکن است Extensionهای مختلف داشته باشد.
Client از نسخه‌های قدیمی و جدید MCP پشتیبانی می‌کند.
ابزارهای یک Server ممکن است براساس استقرار تغییر کنند.
Agent از Marketplace یا Registry برای اتصال Serverها استفاده می‌کند.

چه زمانی Discovery ضروری نیست؟

Client می‌تواند server/discover را اجرا نکند و مستقیماً درخواست اصلی را بفرستد.

این روش در شرایط زیر قابل‌بررسی است:

Client و Server با هم توسعه داده شده‌اند.
نسخه پروتکل از قبل مشخص است.
تنها یک Tool ثابت فراخوانی می‌شود.
کاهش یک Round Trip اهمیت زیادی دارد.
Client خطای ناسازگاری نسخه را به‌درستی مدیریت می‌کند.

حتی در این حالت، Server باید متد server/discover را پیاده‌سازی کرده باشد؛ زیرا الزام Server و انتخاب Client دو موضوع متفاوت‌اند.

سازگاری با MCP Serverهای قدیمی

یکی از کاربردهای مهم Discovery، تشخیص Serverهای Legacy است.

در ارتباط stdio، یک Client که هم نسخه جدید و هم نسخه قدیمی را پشتیبانی می‌کند، بهتر است ابتدا server/discover را ارسال کند.

سه نتیجه ممکن است رخ دهد.

Server پاسخ معتبر Discovery می‌دهد

Server از معماری جدید پشتیبانی می‌کند. Client یک نسخه مشترک را انتخاب و ارتباط را ادامه می‌دهد.

Server خطای شناخته‌شده نسخه جدید می‌دهد

ممکن است نسخه پیشنهادی Client پشتیبانی نشود، اما Server همچنان Modern است. Client باید یکی از نسخه‌های اعلام‌شده را انتخاب کند و نباید به initialize بازگردد.

Server خطای نامشخص می‌دهد یا پاسخ نمی‌دهد

احتمالاً Server از نسل Legacy است. Client دوحالته می‌تواند به فرایند قدیمی initialize بازگردد.

Fallback نباید فقط به یک Error Code خاص وابسته باشد؛ زیرا Serverهای قدیمی ممکن است برای متد ناشناخته رفتارهای متفاوتی داشته باشند.

ارتباط Server Discovery با API درواره

MCP و LLM API دو مسئولیت متفاوت دارند.

MCP ابزارها، منابع و قابلیت‌های خارجی را در اختیار Agent قرار می‌دهد.
LLM API مدل هوش مصنوعی را برای تحلیل، تصمیم‌گیری و تولید پاسخ اجرا می‌کند.

یک Agent می‌تواند هنگام راه‌اندازی:

از طریق server/discover قابلیت‌های MCP Server را شناسایی کند.
در صورت پشتیبانی، فهرست Toolها را دریافت کند.
توضیحات Toolها را در اختیار مدل قرار دهد.
مدل را از طریق API درواره اجرا کند.
Tool انتخاب‌شده توسط مدل را روی MCP Server فراخوانی کند.
نتیجه Tool را دوباره به مدل بدهد.
پاسخ نهایی را تولید کند.

Base URL رسمی API درواره:

https://api.darvareh.ir/v1

این تفکیک باعث می‌شود Agent به مدل یا MCP Server خاصی وابسته نباشد.

ساخت Agent متصل به API درواره

ابتدا Client مدل را ایجاد می‌کنیم:

import os

from openai import AsyncOpenAI

llm_client = AsyncOpenAI(
    api_key=os.environ["DARVAREH_API_KEY"],
    base_url="https://api.darvareh.ir/v1",
)

MODEL_ID = os.environ["DARVAREH_MODEL_ID"]

پس از اجرای Discovery و دریافت Toolها، تعریف آن‌ها را به مدل می‌دهیم:

async def run_agent(
    user_message: str,
    tools: list[dict],
):
    return await llm_client.chat.completions.create(
        model=MODEL_ID,
        messages=[
            {
                "role": "system",
                "content": (
                    "شما یک AI Agent هستید. "
                    "فقط در صورت نیاز از ابزارهای موجود استفاده کنید."
                ),
            },
            {
                "role": "user",
                "content": user_message,
            },
        ],
        tools=tools,
        tool_choice="auto",
    )

در این معماری:

API درواره دسترسی به مدل را فراهم می‌کند.
MCP Server ابزارها را ارائه می‌دهد.
server/discover قابلیت‌های Server را مشخص می‌کند.
tools/list Schema ابزارها را برمی‌گرداند.
مدل تصمیم می‌گیرد کدام Tool باید فراخوانی شود.

پیش از استفاده، باید مطمئن شوید مدل انتخابی از Tool Calling پشتیبانی می‌کند. وضعیت قابلیت‌ها و Model ID را از صفحه مدل‌های درواره بررسی کنید.

معماری پیشنهادی برای چند MCP Server

یک Agent پیشرفته ممکن است به چند MCP Server متصل شود:

Agent Runtime
 ├── MCP Server: CRM
 ├── MCP Server: اسناد
 ├── MCP Server: گزارش‌ها
 └── MCP Server: پایگاه داده

در زمان راه‌اندازی، Agent Runtime می‌تواند برای هر Server این مراحل را اجرا کند:

ارسال server/discover
ثبت نام و نسخه Server
بررسی نسخه‌های پشتیبانی‌شده
ثبت Capabilities
دریافت Toolها در صورت پشتیبانی
Cache کردن نتیجه براساس TTL
تبدیل Schemaهای MCP به ساختار Tool Calling مدل
ارسال مجموعه ابزارهای مرتبط به مدل

لازم نیست تمام Toolهای همه Serverها در تمام درخواست‌ها به مدل داده شوند. بهتر است ابتدا Toolهای مرتبط با موضوع کاربر انتخاب شوند تا Context مدل بی‌دلیل بزرگ نشود.

Progressive Tool Discovery

وقتی تعداد MCP Serverها و Toolها زیاد شود، ارسال تمام Toolها به مدل مشکلاتی ایجاد می‌کند:

افزایش مصرف Token
دشوارترشدن انتخاب Tool
افزایش احتمال انتخاب ابزار اشتباه
کاهش سرعت پاسخ
کاهش بهره‌وری Prompt Cache

در این شرایط می‌توان از Progressive Tool Discovery استفاده کرد.

جریان پیشنهادی:

اطلاعات کلی Serverها دریافت می‌شود.
Agent فقط دسته مرتبط را انتخاب می‌کند.
Toolهای همان Server دریافت می‌شوند.
فقط Toolهای مرتبط به مدل ارسال می‌شوند.
مدل Tool نهایی را انتخاب می‌کند.

server/discover در این معماری لایه اول شناسایی است. این متد مشخص می‌کند کدام Server اصولاً قابلیت موردنیاز را دارد.

خطاهای متداول در پیاده‌سازی Discovery

تصور اینکه Discovery فهرست Toolها را برمی‌گرداند

Discovery فقط قابلیت کلی tools را اعلام می‌کند. برای دریافت Toolها باید tools/list فراخوانی شود.

اجرای initialize در نسخه جدید

در نسخه 2026-07-28، Handshake قدیمی حذف شده است. Client جدید باید اطلاعات موردنیاز را در هر درخواست ارسال کند.

ذخیره قابلیت‌ها بدون توجه به TTL

قابلیت‌ها ممکن است پس از استقرار نسخه جدید Server تغییر کنند. Cache باید براساس ttlMs مدیریت شود.

استفاده از Cache عمومی برای پاسخ خصوصی

اگر قابلیت‌های Server براساس کاربر متفاوت‌اند، پاسخ نباید با cacheScope: public برگردانده شود.

اعتماد عملیاتی به serverInfo

نام و نسخه Server Self-reported هستند. از آن‌ها برای نمایش و Debugging استفاده کنید، نه برای تصمیم‌های حساس.

وابستگی Agent به ترتیب Capabilities

Client باید فیلدها را براساس نام بخواند و نباید به ترتیب آن‌ها در JSON وابسته باشد.

ارسال همه Toolها به مدل

Discovery موفق به این معنی نیست که تمام Toolها باید وارد Context مدل شوند. Toolها را براساس درخواست کاربر محدود کنید.

چک‌لیست پیاده‌سازی server/discover

برای ساخت یک Server سازگار با نسخه جدید MCP این موارد را بررسی کنید:

متد server/discover پیاده‌سازی شده باشد.
supportedVersions دقیق و واقعی باشد.
Capabilities فعال به‌درستی اعلام شوند.
اطلاعات serverInfo نام و نسخه صحیح داشته باشند.
Instructions کوتاه و کاربردی باشند.
Extensionها در بخش مربوط به Capabilities اعلام شوند.
نتیجه دارای resultType: complete باشد.
ttlMs متناسب با نرخ تغییر قابلیت‌ها انتخاب شود.
cacheScope عمومی یا خصوصی به‌درستی تعیین شود.
Server به Session قبلی وابسته نباشد.
اطلاعات نسخه و Client از _meta هر درخواست خوانده شوند.
ناسازگاری نسخه با خطای مشخص مدیریت شود.
رفتار Server با Clientهای Legacy آزمایش شود.
Discovery از tools/list، resources/list و prompts/list جدا باقی بماند.

جمع‌بندی

قابلیت MCP Server Discovery یکی از اجزای اصلی معماری Stateless در نسخه 2026-07-28 پروتکل MCP است.

در این نسخه:

initialize و notifications/initialized حذف شده‌اند.
هدر Mcp-Session-Id دیگر بخشی از پروتکل جدید نیست.
اطلاعات Client در هر درخواست قرار می‌گیرند.
تمام Serverها باید server/discover را پیاده‌سازی کنند.
Client می‌تواند نسخه‌ها، قابلیت‌ها و هویت Server را شناسایی کند.
نتیجه Discovery براساس ttlMs و cacheScope قابل Cache است.
اتصال به چند Server و اجرای افقی زیرساخت ساده‌تر می‌شود.

در معماری یک AI Agent، server/discover مشخص می‌کند MCP Server چه قابلیت‌هایی دارد و API درواره مدل هوش مصنوعی لازم برای تحلیل، Tool Calling و تولید پاسخ را فراهم می‌کند.

این جداسازی کمک می‌کند Agent شما:

Model Agnostic باشد.
به MCP Server خاصی وابسته نشود.
قابلیت‌های Serverها را به‌صورت پویا شناسایی کند.
Toolهای مرتبط را انتخاب کند.
روی چند Instance و زیرساخت Stateless اجرا شود.
بدون تغییر معماری اصلی میان مدل‌های مختلف جابه‌جا شود.

برای استفاده از مدل‌های دارای Tool Calling، در درواره حساب بسازید و Model ID مناسب را از صفحه مدل‌ها دریافت کنید.

پرسش‌های متداول

server/discover در MCP چیست؟

متدی است که نسخه‌های پشتیبانی‌شده، قابلیت‌ها، هویت و Instructions مربوط به MCP Server را به Client اعلام می‌کند.

آیا تمام MCP Serverها باید server/discover داشته باشند؟

Serverهای سازگار با نسخه 2026-07-28 باید این متد را پیاده‌سازی کنند.

آیا Client حتماً باید server/discover را فراخوانی کند؟

خیر. Client می‌تواند مستقیماً یک RPC دیگر را اجرا کند؛ اما Discovery برای شناسایی قابلیت‌ها، انتخاب نسخه و سازگاری با Serverهای مختلف مفید است.

آیا server/discover جایگزین tools/list است؟

خیر. Discovery فقط پشتیبانی از Tools را اعلام می‌کند. برای دریافت نام، توضیحات و Schema ابزارها باید tools/list فراخوانی شود.

آیا initialize از MCP حذف شده است؟

بله، در نسخه 2026-07-28 فرایند initialize و notifications/initialized از معماری جدید حذف شده‌اند. Serverهای دوحالته می‌توانند برای سازگاری با Clientهای قدیمی همچنان آن را پشتیبانی کنند.

اطلاعات Client در نسخه جدید کجا قرار می‌گیرند؟

نسخه پروتکل، اطلاعات Client و قابلیت‌های آن در _meta هر درخواست ارسال می‌شوند.

آیا MCP جدید کاملاً بدون State است؟

پروتکل در سطح ارتباط Stateless است، اما برنامه می‌تواند State خود را در Database ذخیره و با شناسه‌های صریح مدیریت کند.

API درواره چه ارتباطی با MCP Discovery دارد؟

Discovery ابزارها و قابلیت‌های MCP Server را مشخص می‌کند. API درواره مدل هوش مصنوعی را برای انتخاب Tool، تحلیل نتیجه و تولید پاسخ در اختیار Agent قرار می‌دهد.

مقالات مرتبط

منابع اصلی

این مقاله صرفاً با هدف آموزش و اطلاع‌رسانی تهیه شده است. پیش از استفاده عملی، مستندات رسمی سرویس‌ها و صفحه سلب مسئولیت را مطالعه کنید.