MCP Elicitation چیست؟ دریافت ورودی کاربر در AI Agentها

یک AI Agent همیشه نمی‌تواند تمام اطلاعات موردنیاز خود را از Prompt اولیه به دست آورد.

فرض کنید کاربر از Agent می‌خواهد:

برای هفته آینده یک جلسه با تیم فنی تنظیم کن.

Agent برای انجام این درخواست ممکن است به اطلاعات بیشتری نیاز داشته باشد:

• روز ترجیحی کاربر
• ساعت مناسب
• مدت جلسه
• اعضای شرکت‌کننده
• تأیید نهایی پیش از ایجاد رویداد

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

MCP Elicitation برای حل همین مسئله طراحی شده است. این قابلیت به MCP Server اجازه می‌دهد هنگام اجرای یک Workflow، از طریق MCP Client اطلاعات تکمیلی یا تأیید کاربر را درخواست کند.

به‌این‌ترتیب، Agent می‌تواند اجرای عملیات را موقتاً متوقف کند، سؤال مشخصی از کاربر بپرسد و پس از دریافت پاسخ، همان عملیات را ادامه دهد.

فهرست مطالب

• MCP Elicitation چیست؟
• چرا Agentها به Elicitation نیاز دارند؟
• اجزای جریان Elicitation
• تفاوت Form Mode و URL Mode
• Form Mode چگونه کار می‌کند؟
• URL Mode چگونه کار می‌کند؟
• معماری Multi Round-Trip Requests
• تفاوت Elicitation با Tool Calling
• تفاوت Elicitation با Sampling
• تفاوت Elicitation با سؤال معمولی مدل
• طراحی Schema برای فرم‌ها
• مدیریت Accept، Decline و Cancel
• کاربردهای عملی
• امنیت Elicitation
• مدیریت State
• خطاهای رایج
• معماری پیشنهادی Production
• چک‌لیست پیاده‌سازی
• پرسش‌های متداول
• جمع‌بندی

MCP Elicitation چیست؟

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

این اطلاعات از طریق MCP Client جمع‌آوری می‌شوند. بنابراین MCP Server مستقیماً رابط کاربری نمایش نمی‌دهد و کنترل تعامل همچنان در اختیار Client باقی می‌ماند.

جریان کلی به این صورت است:

کاربر
↓
MCP Client
↓
فراخوانی Tool در MCP Server
↓
تشخیص اطلاعات ناقص
↓
درخواست Elicitation
↓
نمایش فرم یا URL به کاربر
↓
دریافت پاسخ
↓
ادامه اجرای Tool

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

• صندلی کنار پنجره
• صندلی کنار راهرو
• بدون ترجیح

پس از انتخاب کاربر، درخواست اصلی با اطلاعات جدید ادامه پیدا می‌کند.

طبق Specification رسمی MCP Elicitation، هدف این قابلیت ایجاد Workflowهای تعاملی است که در آن‌ها سرور بتواند بدون حدس‌زدن اطلاعات، ورودی لازم را از کاربر دریافت کند.

چرا Agentها به Elicitation نیاز دارند؟

بسیاری از عملیات واقعی بدون اطلاعات تکمیلی قابل انجام نیستند.

برای مثال:

• ایجاد جلسه بدون مشخص‌بودن ساعت
• خرید محصول بدون انتخاب روش ارسال
• ثبت تیکت بدون تعیین پروژه
• اجرای Deployment بدون انتخاب Environment
• ارسال ایمیل بدون تأیید گیرنده
• اتصال سرویس بدون Authorization
• ثبت پرداخت بدون هدایت کاربر به درگاه امن

در نبود Elicitation معمولاً یکی از این اتفاق‌ها رخ می‌دهد:

Tool با خطا متوقف می‌شود

{
  "error": "seat_preference is required"
}

این پاسخ برای Agent و کاربر تجربه مناسبی ایجاد نمی‌کند.

مدل اطلاعات را حدس می‌زند

مدل ممکن است بدون اجازه کاربر یک گزینه پیش‌فرض انتخاب کند. این رفتار برای عملیات حساس خطرناک است.

منطق پرسش‌وپاسخ به Prompt منتقل می‌شود

توسعه‌دهنده مجبور می‌شود تمام حالات ناقص‌بودن اطلاعات را داخل Prompt یا منطق Agent مدیریت کند. این روش با افزایش تعداد ابزارها پیچیده و شکننده می‌شود.

Elicitation اجازه می‌دهد نیاز به اطلاعات تکمیلی در همان لایه‌ای مدیریت شود که از آن اطلاعات آگاه است: MCP Server.

اجزای اصلی Elicitation

جریان Elicitation معمولاً چهار جزء اصلی دارد.

کاربر

شخصی که باید اطلاعات را وارد، اصلاح یا تأیید کند.

MCP Client

اپلیکیشنی که رابط تعامل با کاربر را فراهم می‌کند. Client می‌تواند یک محیط Chat، IDE، اپلیکیشن دسکتاپ یا ابزار سازمانی باشد.

Client باید درخواست Elicitation را به‌شکل قابل‌فهم نمایش دهد و امکان پذیرش، رد یا لغو آن را فراهم کند.

MCP Server

سرویسی که Tool، Resource یا Workflow موردنیاز Agent را ارائه می‌دهد. سرور تشخیص می‌دهد چه اطلاعاتی برای ادامه عملیات لازم است.

سیستم خارجی

سرویسی که عملیات نهایی روی آن انجام می‌شود؛ مانند:

• تقویم
• GitHub
• CRM
• درگاه پرداخت
• سرویس رزرو
• پایگاه داده
• زیرساخت Cloud

انواع Elicitation

Elicitation در MCP دو حالت اصلی دارد:

انتخاب حالت مناسب یک تصمیم امنیتی مهم است.

Form Mode چیست؟

در Form Mode، سرور یک JSON Schema محدودشده ارسال می‌کند. MCP Client براساس آن فرم مناسبی برای کاربر می‌سازد.

برای مثال، سرور می‌تواند برای دریافت تنظیمات جلسه چنین درخواستی ایجاد کند:

{
  "method": "elicitation/create",
  "params": {
    "mode": "form",
    "message": "برای ایجاد جلسه، تنظیمات زیر را مشخص کنید.",
    "requestedSchema": {
      "type": "object",
      "properties": {
        "meeting_date": {
          "type": "string",
          "title": "تاریخ جلسه",
          "format": "date"
        },
        "duration_minutes": {
          "type": "integer",
          "title": "مدت جلسه",
          "minimum": 15,
          "maximum": 180,
          "default": 60
        },
        "meeting_type": {
          "type": "string",
          "title": "نوع جلسه",
          "enum": [
            "online",
            "in_person"
          ]
        }
      },
      "required": [
        "meeting_date",
        "duration_minutes",
        "meeting_type"
      ]
    }
  }
}

Client می‌تواند براساس این Schema:

• انتخاب‌گر تاریخ نمایش دهد.
• برای مدت جلسه ورودی عددی بسازد.
• نوع جلسه را به‌صورت Select نمایش دهد.
• فیلدهای ضروری را مشخص کند.
• ورودی را پیش از ارسال اعتبارسنجی کند.

Form Mode برای چه اطلاعاتی مناسب است؟

• تاریخ و ساعت
• نام نمایشی
• ایمیل تماس
• تعداد افراد
• اولویت
• دسته‌بندی
• انتخاب Environment
• تأیید یک عملیات
• تنظیمات غیرحساس
• انتخاب از میان گزینه‌های مشخص

چه اطلاعاتی نباید در Form Mode دریافت شوند؟

Form Mode نباید برای دریافت این موارد استفاده شود:

• Password
• API Key
• Access Token
• اطلاعات کارت بانکی
• کدهای امنیتی
• Payment Credential
• Secretهای سازمانی
• اطلاعاتی که دسترسی مستقیم ایجاد می‌کنند

این اطلاعات از MCP Client عبور می‌کنند و ممکن است در Log، حافظه برنامه یا Context مدل قرار بگیرند.

URL Mode چیست؟

URL Mode برای تعاملاتی طراحی شده است که باید خارج از MCP Client انجام شوند.

در این حالت، سرور از Client می‌خواهد یک URL مشخص را به کاربر نمایش دهد. کاربر پس از تأیید، صفحه را در Browser باز می‌کند و عملیات حساس را مستقیماً با سرویس مربوط انجام می‌دهد.

نمونه درخواست:

{
  "method": "elicitation/create",
  "params": {
    "mode": "url",
    "message": "برای اتصال حساب GitHub، صفحه مجوز را باز کنید.",
    "url": "https://example-mcp-server.com/connect/github",
    "elicitationId": "elicit_01JABC123"
  }
}

کاربر وارد صفحه می‌شود و فرایند OAuth را انجام می‌دهد. Access Token نباید به MCP Client یا مدل برگردانده شود. MCP Server مسئول دریافت و نگهداری امن Token است.

URL Mode برای چه کاربردهایی مناسب است؟

• OAuth
• ورود به حساب کاربری
• اتصال سرویس خارجی
• پرداخت
• واردکردن API Key
• دریافت Credential
• پذیرش قرارداد
• عملیات دارای رابط اختصاصی
• احراز هویت چندمرحله‌ای

تفاوت URL Mode با MCP Authorization

این دو مفهوم نباید با یکدیگر اشتباه گرفته شوند.

MCP Authorization رابطه دسترسی میان MCP Client و MCP Server را مدیریت می‌کند.

URL Mode Elicitation زمانی استفاده می‌شود که MCP Server برای انجام یک Tool به مجوز یا اطلاعات یک سرویس ثالث نیاز دارد.

برای مثال:

MCP Client
→ مجوز دسترسی به MCP Server
→ MCP Authorization

اما:

MCP Server
→ مجوز دسترسی به Google Calendar
→ URL Mode Elicitation

URL Mode نباید جایگزین سیستم Authorization خود MCP Server شود.

Multi Round-Trip Requests چیست؟

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

در این الگو، اجرای یک درخواست طی چند رفت‌وبرگشت کامل می‌شود.

فرض کنید Client ابزار زیر را فراخوانی می‌کند:

{
  "method": "tools/call",
  "params": {
    "name": "create_deployment",
    "arguments": {
      "branch": "main"
    }
  }
}

سرور متوجه می‌شود Environment مشخص نشده است. به‌جای تولید خطا، نتیجه‌ای از نوع input_required برمی‌گرداند:

{
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "deployment_environment": {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "محیط مقصد را انتخاب کنید.",
          "requestedSchema": {
            "type": "object",
            "properties": {
              "environment": {
                "type": "string",
                "title": "Environment",
                "enum": [
                  "staging",
                  "production"
                ]
              }
            },
            "required": [
              "environment"
            ]
          }
        }
      }
    },
    "requestState": "opaque-server-state"
  }
}

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

{
  "method": "tools/call",
  "params": {
    "name": "create_deployment",
    "arguments": {
      "branch": "main"
    },
    "inputResponses": {
      "deployment_environment": {
        "action": "accept",
        "content": {
          "environment": "staging"
        }
      }
    },
    "requestState": "opaque-server-state"
  }
}

سرور اطلاعات جدید را بررسی می‌کند و Deployment را ادامه می‌دهد.

در این معماری، Client یک درخواست جدید و مستقل نمی‌سازد؛ بلکه همان عملیات را با اطلاعات تکمیلی ادامه می‌دهد.

جزئیات این جریان در راهنمای رسمی Tools و InputRequiredResult آمده است.

requestState چه کاربردی دارد؟

requestState یک مقدار Opaque است که توسط سرور تولید می‌شود و Client نباید محتوای آن را تغییر دهد.

سرور می‌تواند از این مقدار برای بازیابی وضعیت عملیات استفاده کند:

• مرحله فعلی Workflow
• شناسه رکورد موقت
• گزینه‌های محاسبه‌شده
• تاریخ انقضا
• شناسه کاربر
• شناسه عملیات
• داده لازم برای جلوگیری از تکرار عملیات

Client باید مقدار requestState را بدون تغییر همراه پاسخ بعدی برگرداند.

چه اطلاعاتی نباید در requestState قرار گیرد؟

اگر مقدار State به Client ارسال می‌شود، نباید حاوی Secret خام باشد؛ مگر آنکه با روش امن امضا یا رمزگذاری شده باشد.

گزینه بهتر معمولاً ذخیره State در Backend و ارسال یک شناسه تصادفی کوتاه است:

{
  "requestState": "state_8f7a21"
}

تفاوت Elicitation و Tool Calling

Tool Calling به مدل اجازه می‌دهد یک ابزار را انتخاب و آرگومان‌های آن را تولید کند.

Elicitation به MCP Server اجازه می‌دهد اطلاعاتی را که برای اجرای همان ابزار ناقص است، از کاربر درخواست کند.

این دو قابلیت مکمل یکدیگرند:

مدل Tool را انتخاب می‌کند
↓
سرور Tool را اجرا می‌کند
↓
اطلاعات ناقص تشخیص داده می‌شود
↓
Elicitation از کاربر
↓
Tool ادامه پیدا می‌کند

تفاوت Elicitation با Sampling

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

اما Elicitation برای دریافت ورودی از انسان طراحی شده است.

براساس Specification مورخ ۲۸ ژوئیه ۲۰۲۶، Sampling و Roots در مسیر Deprecation قرار گرفته‌اند، اما Elicitation همچنان یکی از اجزای اصلی Workflowهای تعاملی MCP است.

تفاوت Elicitation با سؤال معمولی مدل

ممکن است مدل به‌صورت عادی از کاربر سؤال بپرسد:

جلسه را چه روزی برگزار کنم؟

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

• پاسخ ساختار مشخصی ندارد.
• Validation به‌صورت خودکار انجام نمی‌شود.
• ارتباط پاسخ با Tool باید توسط Agent مدیریت شود.
• کاربر ممکن است پاسخ مبهمی بدهد.
• برای OAuth و اطلاعات حساس مناسب نیست.
• Resume کردن عملیات پیچیده‌تر است.

Elicitation سؤال را به بخشی رسمی از Protocol تبدیل می‌کند:

• ورودی Schema دارد.
• Client می‌تواند فرم مناسب بسازد.
• پاسخ با درخواست اصلی مرتبط می‌ماند.
• کاربر می‌تواند درخواست را رد یا لغو کند.
• Workflow می‌تواند State خود را حفظ کند.

طراحی Schema مناسب برای Form Mode

Schemaهای Elicitation عمداً محدود نگه داشته شده‌اند تا Clientها بتوانند رابط ساده و قابل‌پیش‌بینی ایجاد کنند.

انواع متداول عبارت‌اند از:

• string
• number
• integer
• boolean
• enum

رشته

{
  "type": "string",
  "title": "نام پروژه",
  "description": "نام پروژه‌ای که عملیات روی آن اجرا می‌شود.",
  "minLength": 3,
  "maxLength": 100
}

ایمیل

{
  "type": "string",
  "title": "ایمیل تماس",
  "format": "email"
}

عدد

{
  "type": "integer",
  "title": "تعداد نسخه‌ها",
  "minimum": 1,
  "maximum": 20,
  "default": 1
}

مقدار Boolean

{
  "type": "boolean",
  "title": "تأیید انتشار عمومی",
  "default": false
}

انتخاب از فهرست

{
  "type": "string",
  "title": "اولویت",
  "enum": [
    "low",
    "medium",
    "high"
  ],
  "default": "medium"
}

قواعد طراحی Schema

• فقط اطلاعات ضروری را درخواست کنید.
• عنوان فیلدها را قابل‌فهم بنویسید.
• دلیل دریافت اطلاعات را توضیح دهید.
• از مقادیر پیش‌فرض خطرناک استفاده نکنید.
• گزینه‌های Enum را محدود و شفاف نگه دارید.
• برای اعداد بازه مشخص کنید.
• اطلاعات حساس را وارد Form Mode نکنید.
• از Schemaهای پیچیده و تو‌در‌تو اجتناب کنید.
• Validation سمت سرور را نیز انجام دهید.

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

Accept، Decline و Cancel

کاربر باید روی درخواست Elicitation کنترل داشته باشد.

سه نتیجه اصلی می‌توانند وجود داشته باشند:

Accept

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

{
  "action": "accept",
  "content": {
    "environment": "staging"
  }
}

Decline

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

{
  "action": "decline"
}

برای مثال، کاربر ممکن است نخواهد شماره تماس خود را ارائه دهد.

Cancel

کاربر کل تعامل یا Workflow را لغو می‌کند.

{
  "action": "cancel"
}

تفاوت معنایی این دو مهم است:

• decline یعنی کاربر نمی‌خواهد این اطلاعات یا مجوز را ارائه کند.
• cancel یعنی کاربر قصد ادامه عملیات را ندارد.

MCP Server باید برای هر دو حالت رفتار مشخصی داشته باشد و نباید کاربر را وارد Loop بی‌پایان درخواست اطلاعات کند.

کاربردهای عملی MCP Elicitation

تأیید عملیات حساس

پیش از حذف یک منبع:

آیا از حذف دائمی پروژه production مطمئن هستید؟

برای عملیات بسیار حساس، تأیید Elicitation باید در کنار کنترل Backend استفاده شود، نه به‌عنوان تنها مکانیزم امنیتی.

تکمیل اطلاعات رزرو

Agent می‌تواند در میانه رزرو، اطلاعات ناقص مانند تاریخ، تعداد افراد یا نوع اتاق را دریافت کند.

انتخاب Environment

ابزار Deployment می‌تواند از کاربر بخواهد بین Development، Staging و Production انتخاب کند.

اتصال حساب خارجی

MCP Server می‌تواند از URL Mode برای اتصال Google، GitHub، Slack یا سرویس دیگری استفاده کند.

تأیید گیرنده پیام

پیش از ارسال ایمیل یا پیام، Client می‌تواند نام، آدرس و متن نهایی را برای تأیید نمایش دهد.

دریافت پارامتر گزارش

یک ابزار گزارش‌گیری می‌تواند بازه زمانی، فرمت فایل و سطح جزئیات را از کاربر دریافت کند.

پرداخت

برای پرداخت، URL Mode کاربر را به محیط امن درگاه هدایت می‌کند. اطلاعات کارت نباید از MCP Client یا مدل عبور کنند.

امنیت MCP Elicitation

Elicitation یک مرز امنیتی مهم میان سرور، Client، مدل و کاربر ایجاد می‌کند.

منبع درخواست را نمایش دهید

Client باید مشخص کند کدام MCP Server اطلاعات را درخواست کرده است.

نمایش صرف متن زیر کافی نیست:

لطفاً اطلاعات خود را وارد کنید.

نمایش بهتر:

MCP Server تقویم سازمانی برای ایجاد جلسه،
تاریخ و مدت جلسه را درخواست کرده است.

دامنه URL را آشکار کنید

در URL Mode، Client باید دامنه مقصد را پیش از بازکردن صفحه نمایش دهد:

این صفحه در accounts.example.com باز خواهد شد.

این کار احتمال Phishing را کاهش می‌دهد.

URL را خودکار باز نکنید

کاربر باید پیش از Navigation رضایت بدهد. بازکردن خودکار URL کنترل کاربر را کاهش می‌دهد.

Token Passthrough انجام ندهید

MCP Server نباید Access Token کاربر را از Client دریافت و بدون کنترل به سرویس دیگری منتقل کند.

در OAuth سرویس ثالث:

• سرور نقش OAuth Client را دارد.
• کاربر مستقیماً به سرویس ثالث مجوز می‌دهد.
• Callback به MCP Server بازمی‌گردد.
• Token نزد MCP Server ذخیره می‌شود.
• Token وارد Context مدل نمی‌شود.

پاسخ را سمت سرور اعتبارسنجی کنید

حتی اگر Client ورودی را با JSON Schema بررسی کرده باشد، سرور باید دوباره Validation انجام دهد.

درخواست‌ها را Rate Limit کنید

یک MCP Server مخرب یا معیوب ممکن است پیوسته فرم یا URL نمایش دهد. Client باید محدودیت و کنترل مناسب داشته باشد.

عملیات را Idempotent طراحی کنید

تکرار درخواست پس از Elicitation نباید باعث اجرای دوباره بخش قبلی عملیات شود.

برای مثال، اگر رکورد سفارش پیش از دریافت تأیید ایجاد شده است، Retry نباید سفارش دوم بسازد.

می‌توان از Idempotency Key استفاده کرد:

Idempotency-Key: op_7b4a91

State را منقضی کنید

هر requestState باید زمان انقضا داشته باشد. ادامه‌دادن یک عملیات قدیمی می‌تواند باعث استفاده از داده یا مجوز منقضی شود.

Elicitation و Human-in-the-Loop

Elicitation یکی از ابزارهای مهم برای ساخت Human-in-the-Loop Workflow است، اما هر Elicitation الزاماً یک کنترل امنیتی کامل محسوب نمی‌شود.

برای عملیات کم‌خطر:

• انتخاب فرمت
• انتخاب تاریخ
• تعیین اولویت

یک فرم ساده کافی است.

برای عملیات پرخطر:

• حذف داده
• پرداخت
• انتشار Production
• ارسال پیام رسمی
• تغییر سطح دسترسی

کنترل‌های بیشتری لازم است:

• احراز هویت مجدد
• بررسی مجوز Backend
• نمایش خلاصه عملیات
• تأیید صریح
• ثبت Audit Log
• Idempotency
• محدودیت زمانی
• امکان لغو
• جلوگیری از تغییر پارامتر پس از تأیید

مدیریت State در Workflowهای چندمرحله‌ای

Elicitation ممکن است در چند مرحله انجام شود:

انتخاب پروژه
↓
انتخاب Environment
↓
نمایش تغییرات
↓
تأیید نهایی
↓
Deployment

State باید خارج از مدل مدیریت شود. مدل نباید منبع اصلی حقیقت Workflow باشد.

نمونه State سمت سرور:

{
  "operation_id": "deploy_2048",
  "user_id": "user_72",
  "project": "darvareh-api",
  "branch": "main",
  "environment": null,
  "confirmation": false,
  "status": "waiting_for_environment",
  "expires_at": "2026-08-16T14:30:00Z"
}

پس از دریافت Environment:

{
  "operation_id": "deploy_2048",
  "user_id": "user_72",
  "project": "darvareh-api",
  "branch": "main",
  "environment": "staging",
  "confirmation": false,
  "status": "waiting_for_confirmation",
  "expires_at": "2026-08-16T14:30:00Z"
}

این طراحی امکان Resume، Audit و بازیابی پس از خطا را فراهم می‌کند.

مدیریت خطا

Elicitation ممکن است در چند سطح شکست بخورد.

Client از Elicitation پشتیبانی نمی‌کند

قابلیت‌های Client باید پیش از ارسال درخواست بررسی شوند.

کاربر پاسخ نمی‌دهد

برای درخواست زمان انقضا تعریف کنید و Workflow را برای همیشه باز نگه ندارید.

کاربر درخواست را رد می‌کند

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

پاسخ با Schema سازگار نیست

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

State منقضی شده است

عملیات را از مرحله امن دوباره آغاز کنید. State قدیمی را بدون بررسی ادامه ندهید.

OAuth تکمیل نمی‌شود

URL Mode باید وضعیت Pending، Success، Expired و Failed را مدیریت کند.

عملیات پس از دریافت پاسخ شکست می‌خورد

به کاربر پیام دقیق اما غیرحساس بدهید و جزئیات فنی را در Log داخلی ثبت کنید.

اشتباهات رایج

دریافت API Key با Form Mode

Secret نباید از MCP Client و Context مدل عبور کند. برای این کار URL Mode مناسب است.

اعتماد به Validation سمت Client

تمام داده‌ها باید دوباره در MCP Server اعتبارسنجی شوند.

استفاده از Elicitation برای هر سؤال کوچک

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

نبود گزینه لغو

کاربر باید بتواند تعامل را رد یا لغو کند.

ذخیره Secret در requestState

State قابل‌حمل نباید شامل Token یا اطلاعات محرمانه خام باشد.

اجرای بخشی از عملیات پیش از تأیید

تا زمانی که تأیید لازم دریافت نشده، تغییر غیرقابل‌بازگشت ایجاد نکنید.

تکرار عملیات در Retry

Workflow باید Idempotent باشد.

اعتماد به متن تولیدشده توسط مدل

خلاصه‌ای که برای تأیید نمایش داده می‌شود باید از پارامترهای واقعی Backend ساخته شود، نه صرفاً از متن مدل.

نبود Audit Log

برای عملیات حساس ثبت کنید:

• چه سروری اطلاعات را درخواست کرد؟
• چه زمانی درخواست نمایش داده شد؟
• کاربر چه Actionی انتخاب کرد؟
• چه عملیاتی اجرا شد؟
• نتیجه چه بود؟

اطلاعات حساس نباید داخل Log ذخیره شوند.

معماری پیشنهادی Production

کاربر
↓
رابط MCP Client
↓
Permission و نمایش منبع درخواست
↓
MCP Protocol Layer
↓
MCP Server
↓
State Store و Validation
↓
Business Rules
↓
سرویس خارجی

برای URL Mode:

MCP Client
↓
نمایش دامنه و دریافت رضایت
↓
Browser
↓
Authorization یا Payment Provider
↓
Callback به MCP Server
↓
ذخیره امن Credential
↓
ادامه Workflow

مدل زبانی نباید به Secretهای به‌دست‌آمده دسترسی مستقیم داشته باشد.

ارتباط Elicitation با API مدل‌های هوش مصنوعی

Elicitation بخشی از MCP و لایه Agent است، نه Endpoint تولید متن.

در یک معماری واقعی، مدل زبانی ممکن است از طریق یک API سازگار با OpenAI فراخوانی شود:

کاربر
↓
AI Agent
↓
API مدل
↓
تصمیم به فراخوانی Tool
↓
MCP Client
↓
MCP Server
↓
Elicitation

API مدل مسئول Reasoning، تولید پاسخ یا Tool Calling است. MCP Runtime تعامل میان Client و Server را مدیریت می‌کند.

برای Model Routing نیز می‌توان وظایف مختلف را به مدل‌های متناسب سپرد:

• مدل اقتصادی برای طبقه‌بندی درخواست
• مدل سریع برای استخراج پارامتر
• مدل پیشرفته برای برنامه‌ریزی Workflow
• مدل Coding برای تحلیل کد

درواره از طریق یک API سازگار با OpenAI امکان اتصال به مدل‌های مختلف را فراهم می‌کند:

https://api.darvareh.ir/v1

بااین‌حال، مدیریت Elicitation، State، Permission و رابط کاربر باید در Agent، MCP Client و Backend پیاده‌سازی شود.

چک‌لیست Production

• Client پشتیبانی خود از Elicitation را اعلام می‌کند.
• Form Mode و URL Mode از یکدیگر تفکیک شده‌اند.
• اطلاعات حساس فقط از مسیر امن URL Mode دریافت می‌شوند.
• نام MCP Server به کاربر نمایش داده می‌شود.
• دامنه مقصد URL پیش از بازشدن نمایش داده می‌شود.
• Navigation بدون رضایت کاربر انجام نمی‌شود.
• فرم دلیل درخواست اطلاعات را توضیح می‌دهد.
• کاربر امکان Accept، Decline و Cancel دارد.
• Schema فقط شامل فیلدهای ضروری است.
• ورودی در Client و Server اعتبارسنجی می‌شود.
• State خارج از مدل نگهداری می‌شود.
• State دارای زمان انقضا است.
• عملیات حساس Idempotent هستند.
• Retry باعث اجرای تکراری نمی‌شود.
• Permission در Backend دوباره بررسی می‌شود.
• Secret در Prompt، Log یا requestState ذخیره نمی‌شود.
• OAuth Token نزد MCP Server نگهداری می‌شود.
• Token Passthrough انجام نمی‌شود.
• تعداد Elicitationها Rate Limit می‌شود.
• عملیات حساس Audit Log دارند.
• پاسخ منقضی یا متعلق به کاربر دیگر پذیرفته نمی‌شود.
• سازگاری نسخه MCP بررسی شده است.
• رفتار Clientهای فاقد Elicitation مشخص شده است.

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

MCP Elicitation چیست؟

قابلیتی در Model Context Protocol است که به MCP Server اجازه می‌دهد هنگام اجرای Tool یا Workflow، اطلاعات تکمیلی یا تأیید کاربر را از طریق MCP Client دریافت کند.

تفاوت Form Mode و URL Mode چیست؟

Form Mode اطلاعات ساختاریافته و غیرحساس را داخل MCP Client جمع‌آوری می‌کند. URL Mode کاربر را برای عملیات حساس مانند OAuth، ورود یا پرداخت به یک صفحه خارجی هدایت می‌کند.

آیا می‌توان API Key را با Form Mode دریافت کرد؟

خیر. API Key، Password، Access Token و Payment Credential نباید از Form Mode عبور کنند. برای چنین اطلاعاتی باید از یک جریان امن خارج از Client مانند URL Mode استفاده شود.

آیا Elicitation همان Tool Calling است؟

خیر. Tool Calling ابزار را انتخاب و فراخوانی می‌کند. Elicitation زمانی استفاده می‌شود که MCP Server برای ادامه اجرای ابزار به اطلاعات یا تأیید کاربر نیاز داشته باشد.

آیا Elicitation همان سؤال‌پرسیدن مدل است؟

خیر. سؤال معمولی مدل پاسخی متنی دریافت می‌کند، اما Elicitation یک تعامل رسمی Protocol با Schema، Action، State و ارتباط مشخص با درخواست اصلی است.

آیا کاربر می‌تواند درخواست Elicitation را رد کند؟

بله. Client باید امکان Accept، Decline و Cancel را فراهم کند. MCP Server نیز باید برای هر نتیجه رفتار مشخصی داشته باشد.

requestState چیست؟

مقداری Opaque است که سرور برای حفظ ارتباط میان مراحل یک درخواست چندمرحله‌ای تولید می‌کند. Client باید آن را بدون تغییر در Retry بعدی برگرداند.

آیا اطلاعات واردشده مستقیماً به مدل داده می‌شوند؟

الزاماً خیر. Client و Server باید فقط اطلاعات ضروری را وارد Context مدل کنند. Secretها و Credentialها نباید در اختیار مدل قرار بگیرند.

آیا Elicitation برای تأیید عملیات خطرناک کافی است؟

به‌تنهایی خیر. عملیات پرخطر همچنان به احراز هویت، Authorization سمت Backend، Audit Log، Idempotency و کنترل‌های مستقل نیاز دارند.

آیا همه MCP Clientها از Elicitation پشتیبانی می‌کنند؟

خیر. پشتیبانی به Client و نسخه Protocol بستگی دارد. Server باید Capabilityهای Client را بررسی کند و مسیر جایگزین داشته باشد.

Elicitation چه کاربردی در AI Agent دارد؟

Elicitation امکان ساخت Agentهایی را فراهم می‌کند که هنگام ناقص‌بودن اطلاعات، از کاربر سؤال ساختاریافته می‌پرسند و پس از دریافت پاسخ، Workflow را بدون حدس‌زدن ادامه می‌دهند.

جمع‌بندی

MCP Elicitation یکی از اجزای مهم برای تبدیل AI Agentهای ساده به سیستم‌های تعاملی و قابل‌اعتماد است.

در Workflowهای واقعی، تمام اطلاعات از ابتدا در اختیار Agent قرار ندارند. بعضی انتخاب‌ها باید توسط کاربر انجام شوند و برخی عملیات نیز به مجوز، تأیید یا ارتباط امن با یک سرویس خارجی نیاز دارند.

Elicitation این تعامل را به بخشی رسمی از Model Context Protocol تبدیل می‌کند.

اصول کلیدی آن عبارت‌اند از:

• استفاده از Form Mode برای داده‌های ساختاریافته و غیرحساس
• استفاده از URL Mode برای OAuth، پرداخت و Credential
• حفظ کنترل تعامل در MCP Client
• مدیریت State خارج از مدل
• اعتبارسنجی مجدد پاسخ در Server
• پشتیبانی از Accept، Decline و Cancel
• جلوگیری از Token Passthrough
• طراحی Idempotent برای درخواست‌های چندمرحله‌ای
• ثبت Audit Log برای عملیات حساس
• بررسی Capability و نسخه Protocol

در یک معماری مناسب، مدل تصمیم می‌گیرد چه ابزاری لازم است، MCP Server نیاز به اطلاعات تکمیلی را تشخیص می‌دهد، Client پاسخ کاربر را به‌شکل امن دریافت می‌کند و Backend تصمیم نهایی را براساس Permissionها و قواعد کسب‌وکار اجرا می‌کند.

برای استفاده از مدل‌های مختلف در AI Agentها می‌توانید از API درواره استفاده کنید. فهرست قابلیت‌ها، شناسه‌ها و قیمت جاری مدل‌ها در صفحه مدل‌های درواره در دسترس است.

منابع

• Specification رسمی MCP Elicitation
• Specification ابزارهای MCP و InputRequiredResult
• راهنمای مفاهیم MCP Client
• Specification نسخه ۲۰۲۶ MCP
• تغییرات نسخه ۲۰۲۶ MCP
• راهنمای Tasks Extension در MCP

مقالات مرتبط

• MCP چیست؟ راهنمای جامع Model Context Protocol
• Tool Calling چیست؟
• Function Calling چیست؟
• Context Engineering چیست؟
• معماری چندمدلی هوش مصنوعی
• PydanticAI چیست؟
• Structured Outputs چیست؟

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