MCP Sampling منسوخ شد؛ راهنمای مهاجرت به LLM API مستقیم

قابلیت Sampling یکی از ویژگی‌های مهم Model Context Protocol یا MCP بود که به یک MCP Server اجازه می‌داد هنگام اجرای Tool، از مدل زبانی متصل به Client درخواست تولید پاسخ کند.

این قابلیت امکان ساخت Serverهای هوشمند را بدون نگهداری مستقیم API Key مدل فراهم می‌کرد. برای مثال، یک MCP Server می‌توانست اطلاعاتی را از Database دریافت کند و سپس از مدل Client بخواهد آن‌ها را خلاصه، دسته‌بندی یا تحلیل کند.

اما در نسخه 2026-07-28 پروتکل MCP، قابلیت Sampling رسماً در وضعیت Deprecated قرار گرفت.

براساس مستندات رسمی MCP:

• پروژه‌های جدید نباید معماری خود را بر Sampling بنا کنند.
• پیاده‌سازی‌های موجود باید برای مهاجرت برنامه‌ریزی کنند.
• مسیر پیشنهادی، اتصال مستقیم MCP Server به API ارائه‌دهنده مدل است.
• Sampling حداقل تا یک سال پس از این نسخه در فهرست قابلیت‌های منسوخ‌شده باقی می‌ماند، اما تضمینی برای نگهداری دائمی آن وجود ندارد.

این تغییر به معنی حذف فوری Sampling نیست؛ اما برای توسعه‌دهندگانی که MCP Server جدید می‌سازند یا یک سیستم Production دارند، زمان بازطراحی این بخش از معماری فرا رسیده است.

MCP Sampling چیست؟

در معماری معمول MCP سه بخش اصلی وجود دارد:

• Host: اپلیکیشن اصلی هوش مصنوعی
• Client: بخش ارتباطی متصل به MCP Server
• Server: سرویسی که Tool، Resource یا Prompt ارائه می‌کند

در حالت عادی، Client یک Tool را روی MCP Server فراخوانی می‌کند و Server نتیجه اجرای آن Tool را برمی‌گرداند.

Sampling جهت این ارتباط را تغییر می‌داد. MCP Server می‌توانست در میانه اجرای یک Tool از Client درخواست کند که یک مدل زبانی را اجرا کند.

جریان ساده Sampling به این شکل بود:

1. کاربر از AI Agent درخواست انجام یک کار را می‌کرد.
2. Agent یک Tool را روی MCP Server فراخوانی می‌کرد.
3. MCP Server اطلاعات لازم را جمع‌آوری می‌کرد.
4. Server یک درخواست sampling/createMessage برای Client می‌فرستاد.
5. Client درخواست را با مدل انتخابی خود اجرا می‌کرد.
6. نتیجه مدل به MCP Server بازگردانده می‌شد.
7. Server پردازش Tool را تکمیل می‌کرد.

مزیت این ساختار آن بود که MCP Server به API Key جداگانه نیاز نداشت. انتخاب مدل، مجوز اجرا و پرداخت هزینه در اختیار Host یا Client باقی می‌ماند.

یک نمونه کاربرد MCP Sampling

فرض کنید یک MCP Server برای تحلیل تیکت‌های پشتیبانی ساخته‌اید.

Tool موردنظر ابتدا اطلاعات تیکت را از سیستم پشتیبانی دریافت می‌کند. سپس باید موارد زیر را تولید کند:

• خلاصه مشکل کاربر
• تشخیص موضوع تیکت
• تعیین اولویت
• پیشنهاد پاسخ
• استخراج اقدام بعدی

در معماری مبتنی بر Sampling، خود MCP Server مستقیماً به API مدل متصل نمی‌شد. در عوض، محتوای تیکت را برای Client می‌فرستاد و از مدل تحت کنترل Client می‌خواست تحلیل را انجام دهد.

این معماری در محیط‌های Local و Clientهای دارای اتصال دائمی مناسب بود؛ اما با حرکت MCP به سمت Serverهای Remote، Stateless و قابل‌توسعه، محدودیت‌های آن بیشتر نمایان شد.

چرا MCP Sampling منسوخ شد؟

منسوخ‌شدن Sampling بخشی از بازطراحی بزرگ‌تر MCP در نسخه ۲۸ ژوئیه ۲۰۲۶ است.

این نسخه MCP را به سمت معماری Stateless و مناسب زیرساخت‌های Remote هدایت می‌کند. در این معماری، هر درخواست باید اطلاعات لازم برای پردازش را همراه خود داشته باشد و Server نباید به یک Session یا اتصال باز قبلی وابسته باشد.

وابستگی به ارتباط دوطرفه

Sampling بر یک Back Channel متکی بود. Server باید در میانه پردازش، درخواست جدیدی برای Client می‌فرستاد و منتظر پاسخ آن باقی می‌ماند.

این فرایند در ارتباط‌های Local یا Stateful قابل‌مدیریت بود، اما در معماری‌های توزیع‌شده مشکلاتی ایجاد می‌کرد:

• نیاز به باز نگه‌داشتن اتصال
• دشواری اجرای Server پشت Load Balancer
• وابستگی درخواست به یک Instance خاص
• پیچیدگی مدیریت Timeout
• دشواری Retry کردن عملیات
• ناسازگاری با اجرای کاملاً Stateless

وابستگی به قابلیت‌های Client

تمام MCP Clientها از Sampling پشتیبانی نمی‌کردند. حتی در Clientهای سازگار نیز ممکن بود مدل، محدودیت Context، مجوزها یا رابط تأیید کاربر متفاوت باشد.

در نتیجه، رفتار یک MCP Server به محیطی وابسته می‌شد که Server کنترل مستقیمی روی آن نداشت.

مشخص‌نبودن مدل نهایی

در Sampling معمولاً Client درباره مدل تصمیم می‌گرفت. این ویژگی برای حفظ کنترل کاربر مفید بود، اما برای سرویس‌های Production می‌توانست مشکل‌ساز شود.

یک MCP Server ممکن است برای انجام صحیح وظیفه به قابلیت‌های مشخصی نیاز داشته باشد:

• Structured Output
• Tool Calling
• پردازش Context طولانی
• پشتیبانی مناسب از زبان فارسی
• سرعت پاسخ مشخص
• هزینه قابل‌پیش‌بینی

اگر مدل توسط Client انتخاب شود، Server نمی‌تواند همیشه کیفیت و رفتار ثابتی تضمین کند.

دشواری کنترل هزینه و Observability

وقتی مدل از طریق Client اجرا می‌شود، MCP Server دید کاملی نسبت به مصرف Token، Latency، خطاهای Provider و هزینه درخواست ندارد.

در محیط Production معمولاً لازم است موارد زیر ثبت شوند:

• مدل استفاده‌شده
• تعداد Tokenهای ورودی و خروجی
• زمان پاسخ
• وضعیت درخواست
• هزینه تقریبی
• تعداد Retryها
• نسخه Prompt
• شناسه کاربر یا سازمان

اتصال مستقیم به LLM API مدیریت این اطلاعات را ساده‌تر می‌کند.

Deprecated با Removed چه تفاوتی دارد؟

Deprecated به معنی حذف فوری نیست.

Sampling در نسخه 2026-07-28 منسوخ شده، اما هنوز در Specification قرار دارد و برای اتصال‌های مبتنی بر نسخه‌های ۲۰۲۵ می‌تواند کار کند.

براساس سیاست چرخه عمر MCP، این قابلیت حداقل دوازده ماه پس از اعلام Deprecation در Specification باقی می‌ماند. اولین نسخه‌ای که ممکن است Sampling را حذف کند، نسخه‌ای است که در یا پس از ۲۸ ژوئیه ۲۰۲۷ منتشر شود.

بااین‌حال، تاریخ حذف قطعی هنوز مشخص نیست و تصمیم نهایی در زمان آماده‌سازی نسخه‌های آینده گرفته می‌شود.

بنابراین:

• لازم نیست سیستم فعلی را فوراً خاموش کنید.
• نباید یک پروژه جدید را بر Sampling بنا کنید.
• باید مسیر مهاجرت را طراحی و آزمایش کنید.
• بهتر است پشتیبانی از نسخه‌های قدیمی و جدید را موقتاً از هم جدا کنید.

جایگزین رسمی MCP Sampling چیست؟

مسیر مهاجرت رسمی، اتصال مستقیم MCP Server به LLM Provider API است.

در معماری جدید، Tool به‌جای ارسال درخواست Sampling به Client، مستقیماً API مدل را فراخوانی می‌کند.

جریان جدید به این شکل است:

1. Client یک Tool را فراخوانی می‌کند.
2. MCP Server ورودی Tool را اعتبارسنجی می‌کند.
3. Server اطلاعات موردنیاز را دریافت می‌کند.
4. Server مستقیماً درخواست را برای LLM API می‌فرستد.
5. پاسخ مدل را پردازش می‌کند.
6. نتیجه نهایی Tool را به Client برمی‌گرداند.

در این مدل، MCP Server مسئول موارد زیر است:

• نگهداری API Key
• انتخاب مدل
• تعریف Prompt
• کنترل هزینه
• ثبت Usage
• مدیریت Timeout
• اجرای Retry
• مدیریت خطاهای Provider

تفاوت معماری قدیمی و جدید

استفاده از API درواره به‌جای MCP Sampling

درواره یک API سازگار با OpenAI ارائه می‌کند. بنابراین MCP Server می‌تواند با یک ساختار واحد به مدل‌های مختلف متصل شود.

Base URL درواره:

https://api.darvareh.ir/v1

در این معماری، MCP Server به‌جای وابستگی به مدل داخلی هر Client، از API درواره برای اجرای درخواست هوش مصنوعی استفاده می‌کند.

مزیت این روش آن است که می‌توانید:

• مدل را متناسب با وظیفه انتخاب کنید.
• بدون تغییر معماری اصلی، Model ID را تغییر دهید.
• برای وظایف ساده و پیچیده مدل‌های متفاوتی داشته باشید.
• مصرف API را در Backend مدیریت کنید.
• رفتار Server را میان MCP Clientهای مختلف ثابت نگه دارید.
• Fallback و Model Routing پیاده‌سازی کنید.

شناسه مدل‌ها و قیمت آن‌ها ممکن است تغییر کند؛ بنابراین Model ID را از صفحه مدل‌های درواره دریافت کنید.

نصب کتابخانه‌های موردنیاز

برای نمونه Python می‌توان از OpenAI SDK استفاده کرد:

pip install openai mcp

API Key و Model ID را در Environment Variable نگه دارید:

export DARVAREH_API_KEY="your-api-key"
export DARVAREH_MODEL_ID="your-model-id"

API Key را مستقیماً داخل Source Code قرار ندهید.

ساخت Client برای API درواره

ابتدا یک Client سازگار با OpenAI ایجاد می‌کنیم:

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"]

استفاده از AsyncOpenAI باعث می‌شود فراخوانی مدل، Event Loop سرور را هنگام انتظار برای پاسخ مسدود نکند.

ساخت تابع مشترک برای فراخوانی مدل

بهتر است منطق اتصال به مدل را داخل Tool ننویسید. یک Service جداگانه ایجاد کنید تا مدیریت خطا، Logging و انتخاب مدل در یک بخش متمرکز باشد.

async def generate_with_llm(
    system_prompt: str,
    user_prompt: str,
) -> str:
    response = await llm_client.chat.completions.create(
        model=MODEL_ID,
        messages=[
            {
                "role": "system",
                "content": system_prompt,
            },
            {
                "role": "user",
                "content": user_prompt,
            },
        ],
        temperature=0.2,
    )

    content = response.choices[0].message.content

    if not content:
        raise RuntimeError("The model returned an empty response.")

    return content

این تابع به یک Provider خاص در Source Code وابسته نیست. تغییر مدل از طریق Environment Variable انجام می‌شود.

استفاده از LLM API داخل MCP Tool

حالا می‌توان تابع تولید پاسخ را داخل یک Tool استفاده کرد:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("Support Analyzer")


@mcp.tool()
async def analyze_support_ticket(
    subject: str,
    message: str,
) -> str:
    """Analyze a support ticket and return a concise Persian report."""

    user_prompt = f"""
موضوع تیکت:
{subject}

متن تیکت:
{message}

خروجی را به زبان فارسی و در قالب زیر ارائه کن:
- خلاصه
- دسته‌بندی
- اولویت
- اقدام پیشنهادی
"""

    return await generate_with_llm(
        system_prompt=(
            "شما مسئول تحلیل تیکت‌های پشتیبانی هستید. "
            "فقط براساس اطلاعات موجود پاسخ دهید."
        ),
        user_prompt=user_prompt,
    )


if __name__ == "__main__":
    mcp.run()

در این نسخه، MCP Server برای تولید تحلیل به Sampling وابسته نیست. هر Client سازگار با MCP می‌تواند Tool را فراخوانی کند و Server نیز مدل موردنظر را مستقیماً از طریق API درواره اجرا می‌کند.

معماری پیشنهادی برای پروژه Production

برای پروژه واقعی بهتر است فراخوانی مدل را در یک لایه مستقل قرار دهید:

MCP Tool
   ↓
Application Service
   ↓
Prompt Builder
   ↓
LLM Gateway
   ↓
API درواره

این تفکیک چند مزیت دارد:

• Tool فقط مسئول دریافت و اعتبارسنجی ورودی است.
• Prompt در یک بخش مستقل مدیریت می‌شود.
• انتخاب مدل به منطق Tool وابسته نیست.
• تست‌کردن بخش‌های مختلف ساده‌تر می‌شود.
• تغییر Provider یا Model ID به بازنویسی Tool نیاز ندارد.
• می‌توان محدودیت بودجه را قبل از فراخوانی مدل بررسی کرد.

مدیریت Timeout

فراخوانی مدل نباید بدون محدودیت زمانی اجرا شود. در غیر این صورت، یک درخواست کند می‌تواند اجرای Tool را برای مدت طولانی معطل کند.

import asyncio


async def generate_with_timeout(
    system_prompt: str,
    user_prompt: str,
) -> str:
    return await asyncio.wait_for(
        generate_with_llm(
            system_prompt=system_prompt,
            user_prompt=user_prompt,
        ),
        timeout=45,
    )

مقدار Timeout باید براساس نوع مدل، اندازه ورودی و کاربرد Tool تنظیم شود.

مدل‌های Reasoning یا درخواست‌هایی با خروجی طولانی معمولاً به زمان بیشتری نیاز دارند.

مدیریت خطاها

تمام خطاهای Provider نباید مستقیماً به کاربر نمایش داده شوند.

import asyncio
from openai import APIConnectionError, APITimeoutError, RateLimitError


async def safe_generate(
    system_prompt: str,
    user_prompt: str,
) -> str:
    try:
        return await generate_with_timeout(
            system_prompt=system_prompt,
            user_prompt=user_prompt,
        )

    except asyncio.TimeoutError:
        return "پردازش درخواست بیش از زمان مجاز طول کشید."

    except APITimeoutError:
        return "پاسخ مدل در زمان تعیین‌شده دریافت نشد."

    except RateLimitError:
        return "ظرفیت موقت سرویس تکمیل است. کمی بعد دوباره تلاش کنید."

    except APIConnectionError:
        return "ارتباط با سرویس مدل برقرار نشد."

    except Exception:
        return "هنگام پردازش درخواست خطایی رخ داد."

در محیط Production، جزئیات فنی خطا را در Log ثبت کنید؛ اما پیام ساده و کنترل‌شده‌ای به Client برگردانید.

انتخاب مدل برای MCP Tool

پس از حذف Sampling، انتخاب مدل بر عهده MCP Server قرار می‌گیرد. این انتخاب نباید صرفاً براساس جدیدترین یا بزرگ‌ترین مدل انجام شود.

برای هر Tool این معیارها را بررسی کنید:

• پیچیدگی وظیفه
• کیفیت زبان فارسی
• پشتیبانی از Structured Output
• نیاز به Tool Calling
• اندازه Context
• سرعت پاسخ
• قیمت ورودی و خروجی
• پایداری مدل
• محدودیت Rate Limit

برای مثال:

• خلاصه‌سازی کوتاه می‌تواند با یک مدل سریع و اقتصادی انجام شود.
• تحلیل قرارداد ممکن است به Context بزرگ‌تر نیاز داشته باشد.
• تولید JSON معتبر به مدلی با Structured Output مناسب نیاز دارد.
• برنامه‌ریزی چندمرحله‌ای ممکن است به یک مدل Reasoning نیاز داشته باشد.

استفاده از یک مدل قدرتمند برای تمام Toolها معمولاً بهترین معماری نیست.

آیا MRTR جایگزین Sampling است؟

در نسخه جدید MCP، الگوی Multi Round-Trip Requests یا MRTR برای مدیریت تعامل‌های چندمرحله‌ای معرفی شده است.

MRTR اجازه می‌دهد Server اعلام کند برای تکمیل درخواست به ورودی دیگری نیاز دارد. Client ورودی لازم را آماده می‌کند و درخواست اصلی را همراه پاسخ‌ها دوباره می‌فرستد.

این الگو نیاز به اتصال دوطرفه دائمی را کاهش می‌دهد و با معماری Stateless سازگارتر است.

بااین‌حال، نباید MRTR را جایگزین اصلی اجرای مدل در Server در نظر گرفت. مسیر رسمی مهاجرت از Sampling همچنان اتصال مستقیم به LLM Provider API است.

MRTR بیشتر زمانی کاربرد دارد که Server به مواردی مانند این‌ها نیاز داشته باشد:

• تأیید کاربر
• دریافت اطلاعات تکمیلی
• تکمیل یک Form
• اجرای تعامل چندمرحله‌ای
• دریافت ورودی موردنیاز برای ادامه Tool

اگر هدف اصلی MCP Server تولید پاسخ با مدل زبانی است، اتصال مستقیم به API معمولاً معماری روشن‌تری خواهد داشت.

تکلیف پروژه‌هایی که هنوز از Sampling استفاده می‌کنند چیست؟

اگر یک MCP Server فعال دارید، ابتدا محل‌های استفاده از این موارد را پیدا کنید:

sampling/createMessage
requestSampling
create_message
Sample
SamplingMessage

سپس برای هر مورد مشخص کنید:

• چه Promptی برای Client ارسال می‌شود؟
• چه نوع خروجی انتظار می‌رود؟
• آیا Server به مدل خاصی نیاز دارد؟
• چه کسی اکنون هزینه مدل را پرداخت می‌کند؟
• آیا انتخاب مدل توسط کاربر ضروری است؟
• آیا خروجی باید ساختاریافته باشد؟
• Timeout و Retry چگونه مدیریت می‌شوند؟

بعد از این بررسی، می‌توانید هر فراخوانی Sampling را به یک LLM Gateway داخلی منتقل کنید.

چک‌لیست مهاجرت از MCP Sampling

برای مهاجرت مرحله‌ای می‌توانید از این چک‌لیست استفاده کنید:

• تمام فراخوانی‌های Sampling را در پروژه پیدا کنید.
• Promptهای فعلی را مستندسازی کنید.
• مدل مناسب هر Tool را تعیین کنید.
• LLM API را در یک Service مستقل قرار دهید.
• API Key را به Secret Manager یا Environment Variable منتقل کنید.
• Timeout مشخص تعریف کنید.
• خطاهای Provider را مدیریت کنید.
• Usage و Latency را ثبت کنید.
• برای خروجی مدل Validation اضافه کنید.
• محدودیت مصرف هر کاربر یا سازمان را اعمال کنید.
• نسخه جدید را کنار مسیر قدیمی آزمایش کنید.
• رفتار Server را با چند MCP Client بررسی کنید.
• پس از اطمینان، وابستگی به Sampling را حذف کنید.

آیا اتصال مستقیم به API همیشه بهتر است؟

اتصال مستقیم کنترل بیشتری به Server می‌دهد، اما مسئولیت بیشتری نیز ایجاد می‌کند.

در Sampling، هزینه و مجوز مدل معمولاً در اختیار Client بود. در معماری مستقیم، اپراتور MCP Server باید موارد زیر را مدیریت کند:

• صورتحساب
• محدودیت مصرف
• نگهداری API Key
• انتخاب مدل
• مانیتورینگ
• حریم خصوصی داده‌ها
• نگهداری Log
• مدیریت خطا
• ظرفیت سرویس

بنابراین مهاجرت نباید فقط با جایگزین‌کردن یک خط کد انجام شود. مدل Billing و مسئولیت پردازش داده نیز باید بازبینی شود.

چه زمانی Sampling قدیمی را موقتاً نگه داریم؟

نگهداری موقت Sampling ممکن است در این شرایط منطقی باشد:

• محصول هنوز فقط با Clientهای مبتنی بر نسخه ۲۰۲۵ کار می‌کند.
• کاربران باید مدل و هزینه را در Client خود کنترل کنند.
• انتقال Billing به Server هنوز آماده نیست.
• MCP Server فقط در محیط Local اجرا می‌شود.
• برای مهاجرت تدریجی به سازگاری با نسخه‌های قدیمی نیاز دارید.

بااین‌حال، این مسیر باید موقت و دارای برنامه خروج باشد. پروژه جدید بهتر است مستقیماً با معماری نسخه ۲۰۲۶ طراحی شود.

جمع‌بندی

Sampling به MCP Server اجازه می‌داد بدون داشتن API Key مستقل، از مدل زبانی تحت کنترل Client درخواست تولید پاسخ کند. این قابلیت برای Agentهای Local و ارتباط‌های Stateful مفید بود، اما با معماری جدید MCP که بر Stateless بودن و اجرای Remote تمرکز دارد، سازگاری کمتری پیدا کرد.

در نسخه 2026-07-28، Sampling رسماً Deprecated شد. حذف آن فوری نیست، اما پروژه‌های جدید نباید به آن وابسته باشند.

مسیر پیشنهادی برای مهاجرت عبارت است از:

• اتصال مستقیم MCP Server به LLM API
• جداسازی منطق مدل از MCP Tool
• مدیریت Model ID و API Key در Backend
• اضافه‌کردن Timeout و مدیریت خطا
• ثبت Usage و Latency
• انتخاب مدل متناسب با هر وظیفه
• استفاده از MRTR برای ورودی‌های چندمرحله‌ای، نه به‌عنوان جایگزین عمومی LLM API

با استفاده از API سازگار با OpenAI درواره، می‌توانید این لایه را با یک Base URL واحد پیاده‌سازی کرده و مدل مناسب هر MCP Tool را براساس کیفیت، سرعت و هزینه انتخاب کنید.

برای شروع، ابتدا در درواره حساب بسازید، API Key دریافت کنید و Model ID فعال را از صفحه مدل‌ها بردارید.

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

آیا MCP Sampling کاملاً حذف شده است؟

خیر. Sampling در نسخه ۲۸ ژوئیه ۲۰۲۶ Deprecated شده، اما هنوز فوراً حذف نشده است. این قابلیت برای نسخه‌های قدیمی‌تر پروتکل می‌تواند به کار خود ادامه دهد.

پروژه جدید می‌تواند از Sampling استفاده کند؟

از نظر فنی ممکن است در اتصال‌های قدیمی کار کند، اما مستندات رسمی MCP توصیه می‌کنند پروژه‌های جدید از Sampling استفاده نکنند.

جایگزین رسمی Sampling چیست؟

جایگزین پیشنهادی، اتصال مستقیم MCP Server به API ارائه‌دهنده مدل زبانی است.

آیا MRTR همان جایگزین Sampling است؟

MRTR روش جدید مدیریت درخواست‌های چندمرحله‌ای و دریافت ورودی تکمیلی است. برای اجرای معمول مدل در MCP Server، اتصال مستقیم به LLM API مسیر مهاجرت پیشنهادی محسوب می‌شود.

آیا API درواره در MCP Server قابل‌استفاده است؟

بله. API درواره با ساختار OpenAI سازگار است و می‌توان آن را در MCP Serverهای Python، TypeScript و سایر Backendها استفاده کرد.

API Key درواره را کجا نگه داریم؟

API Key باید در Environment Variable یا Secret Manager نگهداری شود و نباید داخل Source Code، Repository یا تنظیمات عمومی MCP قرار بگیرد.

چه زمانی باید مهاجرت را شروع کنیم؟

بهتر است بررسی و طراحی مهاجرت را از همین حالا آغاز کنید. Sampling زودتر از نخستین نسخه منتشرشده در یا پس از ۲۸ ژوئیه ۲۰۲۷ واجد شرایط حذف نخواهد بود، اما تاریخ حذف نهایی هنوز قطعی نیست.

مقالات مرتبط

• MCP Elicitation چیست؟ دریافت ورودی کاربر در AI Agent
• آموزش MCP در OpenCode؛ اتصال Agent به ابزارها
• PydanticAI چیست؟ آموزش ساخت AI Agent با پایتون و API درواره
• Instructor چیست؟ آموزش Structured Output با Python و API درواره
• API سازگار با OpenAI چیست؟

منابع اصلی

• مستندات رسمی MCP Sampling
• فهرست قابلیت‌های Deprecated در MCP
• معرفی نسخه ۲۰۲۶-۰۷-۲۸ پروتکل MCP
• مستندات رسمی Multi Round-Trip Requests
• راهنمای مهاجرت Python SDK از نسخه ۱ به ۲

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