تصور کنید یک عامل حسابداری را طراحی کردهاید که تراکنشها را بهطور کامل شناسایی میکند، اما در آخرین قدم، یعنی پیوست کردن فایل PDF رسید، شکست میخورد. عامل یک فراخوانی ابزار (Tool Call) زیبا و خوشساخت تولید میکند، اما سرور آن را رد میکند زیرا پروتکل هیچ راهی برای انتقال فایل ندارد. این اتفاق نه یک باگ در پیادهسازی یک شرکت خاص، بلکه نتیجهٔ یک انتخاب بنیادین در طراحی پروتکل زمینهٔ مدل (Model Context Protocol یا MCP) است.
این پروتکل — که شبیه به یک مترجم است که سعی میکند زبان مدلهای هوش مصنوعی را به زبان ابزارهای نرمافزاری ترجمه کند — در حال حاضر هیچ راه بومی برای انتقال فایل ندارد. به همین دلیل، اگر در حال ساخت یک عامل (Agent) برای مدیریت رسیدها، لاگها یا اسکرینشاتها هستید، ابزاری که برای هماهنگی عملیات به آن تکیه کردهاید، عملاً نمیتواند دادهها را جابهجا کند.
همانطور که در تحلیلهای پیشین ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، شکاف بین قابلیتهای تئوریک و اجرای عملی در محیطهای ایزوله همیشه یک چالش است. در اینجا، توسعهدهندگان با شکافی خطرناک بین آنچه یک API میتواند انجام دهد و آنچه یک سرور MCP قادر به اجرای آن است، مواجهاند. اکثر پلتفرمهای SaaS مدرن از multipart/form-data برای آپلود استفاده میکنند، اما MCP بر پایه JSON-RPC است که ماهیتی متنی دارد. این تضاد، یک قابلیت استاندارد را به یک دیوار فنی تبدیل کرده است.
نرخ شکست در ۷ سرویس کلیدی
بر اساس گزارشی که در ۱۹ اوت ۲۰۲۶ در وبسایت dev.to منتشر شد، آزمونی هدفمند روی هفت سرویس حیاتی شامل freee، Jira، Confluence، Notion، GitHub، Gmail و Google Drive انجام شد. این سرویسها به این دلیل انتخاب شدند که «آپلود فایل» هستهٔ اصلی گردشکار آنهاست: سرویس freee برای رسیدها و فاکتورها، جیرا و کانفلوئنس برای لاگها و اسکرینشاتها، نوشن برای فایلهای PDF، گیتهب برای اسکرینشاتهای Pull Request، جیمیل برای پیوستها و گوگل درایو برای ذخیرهسازی عمومی.
نتایج تکاندهنده است: در حالی که تمام این سرویسها از طریق APIهای استاندارد HTTP اجازه آپلود میدهند، هیچکدام پشتیبانی کامل از پروتکل MCP را ارائه نمیکنند. نتایج به سه دسته تقسیم میشوند:
- رد مطلق (۳ سرویس): freee، Jira/Confluence و GitHub بهسادگی نمیتوانند آپلود را از طریق MCP مدیریت کنند.
- دور زدن پروتکل (۴ سرویس): Gmail، Google Drive، Slack و Notion بهظاهر «کار میکنند»، اما تنها به قیمت رها کردن پروتکل MCP برای انتقال واقعی دادهها.
- پشتیبانی کامل از پروتکل: ۰ سرویس.
کالبدشکافی شکستها
برای درک علت این وضعیت، باید به پیامهای خطا و پاسخهای توسعهدهندگان نگاه کنیم:
- freee: API زیرساختی این سرویس دادههای
multipart/form-dataرا میپذیرد، اما لایه انتقال JSON-RPC در MCP این اجازه را نمیدهد. در نتیجه، ابزار در API وجود دارد اما از طریق MCP در دسترس نیست. این موضوع برای سازمانهایی که طبق قوانین انطباق (Compliance) باید تصاویر رسیدها را در پروندهها ذخیره کنند، بسیار دردناک است. - Jira / Confluence: پاسخ جامعهٔ کاربری اتلاسیان صریح است: «آپلود فایل یا پیوست تصاویر از طریق Remote Agent در MCP پشتیبانی نمیشود». علاوه بر این، سرورهای جامعهٔ mcp-atlassian نیاز دارند فایل ابتدا روی سیستمفایل (Filesystem) سرور وجود داشته باشد. این موضوع در محیطهای Docker منجر به شکست میشود، همانطور که در Issue #618 مشاهده شد: «فایل یافت نشد: /home/user/jira-mcp/grafana.png».
- GitHub: در Issue #738 مربوط به github-mcp-server، کاربران اشاره کردهاند که عدم توانایی در آپلود تصاویر، ایجاد PRهای توصیفی یا بصری را غیرممکن کرده و گردشکار رایج پیوست اسکرینشات از خطاهای رابط کاربری (UI Regression) را مختل میکند.
مکانیسمهای «دور زدن»
چهار سرویس بهگونهای عمل میکنند که گویی پشتیبانی میکنند، اما در واقع بایتها را خارج از پروتکل جابهجا میکنند:
- Gmail، Google Drive و Slack: این سرورها اغلب یک مسیر فایل محلی (Local File Path) را بهعنوان ورودی ابزار میپذیرند. سرور سپس فایل را از دیسک میخواند و API را فراخوانی میکند. این «پشتیبانی از MCP» نیست؛ بلکه یک «فراخوانی متنی MCP است که باعث خواندن فایل از سیستم میشود». این روش روی لپتاپ شخصی کار میکند اما به محض انتقال سرور به محیط ابری یا ریموت، میشکند.
- Notion: این سرویس از روش پیچیدهتری از طریق
notion-create-file-uploadاستفاده میکند. ابزار یک URL موقت برای آپلود، هدرها و یک فیلد فرم برمیگرداند. سپس کلاینت، بایتها (تا ۲۰ مگابایت) را مستقیماً به Notion میفرستد. در اینجا بایتها هرگز از مسیر MCP عبور نمیکنند.
چرا پروتکل MCP «سختگیر» است؟
عدم وجود نوع FileContent در مشخصات MCP تصادفی نیست. یک نتیجهٔ ابزار در MCP میتواند شامل TextContent (متن)، ImageContent (به صورت base64)، AudioContent (صوت)، ResourceLink (لینک منبع) یا EmbeddedResource (جسم جاسازی شده) باشد، اما چیزی برای فایلهای عمومی ندارد. یکی از توسعهدهندگان Anthropic در بحثهای گیتهب (Discussion #1197) تأیید کرد که این مورد بهطور عمدی «دشوار» (Finicky) طراحی شده است.
سه دلیل اصلی برای این محدودیت وجود دارد:
۱. محدودیتهای JSON-RPC: پروتکل MCP متنمحور است. انتقال دادههای باینری بهطور عمدی خارج از محدوده (Out of scope) طراحی قرار گرفته است. افزودن آن نیازمند تغییر بنیادین در شکل پروتکل است، نه فقط یک بهروزرسانی ساده.
۲. ریسکهای امنیتی: اجازه دادن به عبور مسیرهای произвоال فایل از مرز ابزار، درهای تزریق دستورات مبتنی بر مسیر (Path-based Command Injection)، استخراج دادهها از طریق درخواستهای «لطفاً این فایل را بخوان» و انتقال بدافزارها را باز میکند. در این راستا، برای مدیریت دسترسیهای حساس و جلوگیری از رفتارهای غیرکنترلشده، استفاده از لایههای نظارتی مانند mcp-fabric-toolmesh به عنوان یک راهکار برای پر کردن شکافهای حاکمیتی در عاملها پیشنهاد شده است.
۳. هزینه پنجره متنی: کدگذاری Base64 حجم داده را حدود ۳۳٪ افزایش میدهد. یک تصویر ۱ مگابایتی به ۱.۳۳ مگابایت متن تبدیل میشود که توکن (Token) — تکههای کوچکی از متن که مدل میخورد — گرانبهای مدل را در هر نوبت که مدل آن را میبیند، مصرف میکند.
تلاشهای ناموفق و مسیر فعلی
تلاشها برای رفع این مشکل کند بوده و به تعویق افتاده است. پیشنهادی به نام SEP-1306 («استخراج حالت باینری برای آپلود فایل») در اوت ۲۰۲۵ ارائه شد. هدف این بود که قابلیت استخراج (Elicitation) با یک حالت سوم گسترش یابد تا سرورها بتوانند با استفاده از مدل رضایت موجود، از کاربران فایل درخواست کنند.
با این حال، SEP-1306 تا اوایل ۲۰۲۶ در حالت پیشنویس باقی ماند. نسخه RC جولای ۲۰۲۶ نیز انتقال باینری را بهطور کامل به تعویق انداخت و پیشنویس بعدی (SEP-2631) نیز به تعویق افتاد. اکنون تمرکز روی یک گروه کاری اختصاصی برای آپلود فایلها در SEP-2356 است. اگرچه برنامهای وجود دارد، اما امروز هیچ پاسخ پروتکلی برای توسعهدهندگان ارائه نشده است.
راهکارهای عملی و جایگزین
از آنجایی که پروتکل بایتها را جابهجا نمیکند، تنها استراتژی آماده برای محیط عملیاتی، انتقال «خارج از باند» (Out-of-band) است. مستحکمترین الگو، روش URL امضا شده (Presigned URL) است که Notion از آن استفاده میکند. در این جریان، ابزار MCP یک URL موقت برای آپلود (مانند لینک S3) برمیگرداند؛ سپس کلاینت فایل را مستقیماً از طریق HTTPS به آن URL میفرستد (PUT میکند) و MCP را کاملاً دور میزند.
گردشکار پیشنهادی:
۱. ابزار اول (prepare_upload): کلاینت MCP را فراخوانی میکند تا یک uploadUrl و fileRef برای یک نام فایل و اندازه خاص دریافت کند.
۲. انتقال خارج از باند: کلاینت با استفاده از fetch و پروتکل HTTPS، بافر فایل را به uploadUrl میفرستد.
۳. ابزار دوم (attach_receipt): کلاینت دوباره MCP را فراخوانی کرده و fileRef و transactionId را برای نهایی کردن پیوست ارسال میکند.
سایر الگوهای رایج اما شکننده شامل موارد زیر است:
- ذخیرهسازی مشترک: هر دو کلاینت و سرور به یک Bucket مشترک احراز هویت میکنند. کلاینت آپلود میکند و فراخوانی MCP فقط کلید شیء (Object Key) را حمل میکند. این روش فقط در یک منطقه اعتماد (Trust Zone) مشترک امکانپذیر است.
- Base64 ImageContent: برای اسکرینشاتهای بسیار کوچک زیر ۵۰۰ کیلوبایت مفید است. اما برای فایلهای بزرگتر بهدلیل هزینه توکنها و محدودیت اندازه درخواست، کاملاً ناکارآمد است. هرگز از این روش برای PDFها استفاده نکنید.
- پراکسی مسیر محلی: پذیرفتن یک مسیر محلی. این یک «بمب ساعتی» است که به محض انتقال سرور به یک کانتینر، بهطور بیصدا شکست میخورد.
این تغییر در رویکرد به این معناست که توسعهدهندگان باید از نگاه به MCP بهعنوان لایه انتقال داده دست بردارند و آن را صرفاً بهعنوان یک هماهنگکننده (Coordinator) ببینند. بایتها باید از کانالهایی عبور کنند که شما به آنها اعتماد دارید، نه از طریق خط لوله فراخوانی ابزارِ عامل.
گام بعدی شما
- اگر از MCP برای اتوماسیون استفاده میکنید، هرگونه انتقال فایل را از مسیر پروتکل حذف کرده و به مدل Presigned URL مهاجرت کنید.
- در محیطهای Docker، از ارسال مسیرهای محلی (Local Path) پرهیز کنید زیرا منجر به خطاهای Runtime میشود.
- برای تصاویر بسیار کوچک (زیر ۵۰۰ کیلوبایت)، از
ImageContentاستفاده کنید اما برای هرچه کوچکتر از این مقدار، راهکار HTTPS را جایگزین کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو