توصیفات ابزار در MCP؛ تنها حفاظ واقعی برای جلوگیری از توهم عامل‌های هوش مصنوعی

تصور کنید یک عامل هوش مصنوعی اعدادی را برای کاربری بازگو می‌کند که به داده‌های خام دسترسی ندارد؛ در این لحظه، هر نکته‌ای که پیش‌تر در پاورقی‌های مستندات بود، باید به دستورالعمل‌های ماشین‌خوان تبدیل شود. اندرو موری (Andrew Maury)، بنیان‌گذار Rantum، این ضرورت را با ساخت addressintel-mcp نشان داد؛ سروری که داده‌های هوشمند املاک در منطقه شبه‌جزیره سان‌فرانسیسکو را در اختیار مدل‌ها قرار می‌دهد. AddressIntel با خواندن مجوزهای ساخت و سوابق قطعات زمین در سراسر منطقه، امتیازدهی می‌کند که روی یک زمین خاص چه چیزی می‌توان ساخت.

در حالی که مهندسی برای تبدیل یک REST API به یک سرور پروتکل زمینه مدل (MCP) — شبیه به ساخت یک مترجم که زبان دیتابیس را به زبانی قابل‌فهم برای مدل تبدیل می‌کند — بسیار ساده است و تنها به ۳۱۲ خط کد TypeScript در دو فایل نیاز دارد، اما مصرف‌کننده این داده‌ها به طور بنیادی تغییر کرده است. یک برنامه‌نویس انسان مستندات را یک‌بار می‌خواند تا یک مدل ذهنی بسازد؛ اما یک مدل هوش مصنوعی در هر بار فراخوانی، توصیف ابزار را می‌خواند تا تصمیم بگیرد اعداد بازگشتی چه معنایی دارند.

در دنیای عامل‌های هوش مصنوعی (AI Agents)، توصیف ابزار دیگر یک راهنمای ساده یا مستندات نیست، بلکه یک «قرارداد» است. چون هیچ نظارتی بر اجرای این قرارداد وجود ندارد، عامل‌ها مستعد «با اعتماد به نفس غلط گفتن» هستند؛ به‌ویژه وقتی با داده‌های مبهم مثل مقادیر null یا بازگشت‌های منفی روبه‌رو می‌شوند. این موضوع در داده‌های املاک بسیار خطرناک است؛ مثلاً وقتی نرخ بازگشت سرمایه (ROI) برای تخریب و بازسازی مقدار null دارد، این به معنای صفر نیست. همچنین امتیازی که کاندیداها را رتبه‌بندی می‌کند، به معنای بازدهی نیست. اگر عامل هر یک از این موارد را در خلاصه‌ای برای یک خریدار اشتباه گزارش کند، عملاً معامله‌ای را اختراع کرده است که وجود خارجی ندارد. این چالش‌ها نشان می‌دهد که چگونه استفاده از پروتکل MCP می‌تواند توهمات مدل‌های زبانی را در مواجهه با داده‌های تخصصی حذف کند، مشروط بر اینکه توصیفات ابزار با دقت طراحی شوند.

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

جزئیات پیاده‌سازی و ابزارها

سرور addressintel-mcp در npm منتشر شده و در رجیستری رسمی MCP تحت فضای نام احراز شده با DNS یعنی co.addressintel/permits قرار دارد. این سرور ۶ ابزار خاص را از طریق stdio ارائه می‌دهد:

• search_permits: یافتن مجوزهای صادر شده با فیلتر شهر، کلمه کلیدی و ارزش ملک.
• list_sb9_inventory: شناسایی صلاحیت‌های تقسیم زمین (lot-split) و ساخت دوبلکس، شامل دلایل مسدود بودن هر قطعه.
• list_adu_leads: ارائه قطعات زمین رتبه‌بندی شده بر اساس امکان‌سنجی برای واحدهای مسکونی جانبی (ADU).
• list_redevelopment_leads: ارائه قطعات زمین رتبه‌بندی شده بر اساس امکان‌سنجی برای بازسازی کلی.
• list_market_signals: ارائه فید فرصت‌های بازار.
• get_property_intelligence: ارائه داده‌های عمیق و تخصصی برای یک ملک خاص.

برای جلوگیری از اینکه ابزار در محیط‌های مختلف «شکل متفاوتی» به خود بگیرد، موری یک رابط ToolDef پیاده کرد. این کار باعث می‌شود اسکیمای اعتبارسنجی (با استفاده از Zod) و اسکیمای JSON اعلام‌شده در یک شیء در کنار هم قرار بگیرند. این ساختار تضمین می‌کند که inputSchema اعلام شده به کلاینت، همیشه با args مورد استفاده برای اعتبارسنجی فراخوانی‌های ورودی مطابقت داشته باشد. این رابط به شکل زیر تعریف شده است:

interface ToolDef<T extends z.ZodTypeAny> { name: string; description: string; inputSchema: { /* advertised to the client */ }; args: T; run: (args: z.infer<T>) => Promise<unknown>; }

خطر مقادیر Null و اعداد منفی

بر اساس بررسی‌های موری، بدون دستورالعمل‌های صریح در توصیف ابزار، عامل‌ها داده‌ها را مکرراً اشتباه تفسیر می‌کنند. در نمونه‌ای از ۵ ردیف داده از API زنده در ۱۴ اکتبر ۲۰۲۶، چهار ملک مقدار proformaROI را null برگرداندند، زیرا قانون no_envelope_rule (به معنای نبود متراژ مجاز سازمان‌یافته برای بازسازی) حاکم بود. نتایج نمونه به این شکل بود:

• سن ماتئو: proformaROI مقدار null، دلیل: no_envelope_rule
• سن خوزه: proformaROI مقدار null، دلیل: no_envelope_rule
• ساراتوگا: proformaROI مقدار ۷-
• لوس آلتوس هیلز: proformaROI مقدار null، دلیل: no_envelope_rule
• سن خوزه: proformaROI مقدار null، دلیل: no_envelope_rule

عاملی که null را صفر بخواند، چهار معامله بدون سود (flat) را گزارش می‌کند. از سوی دیگر، عاملی که نداند اعداد منفی در این بازار عادی هستند، ممکن است بازدهی ۷- درصد را حذف کند یا علامت آن را تغییر دهد. برای جلوگیری از این اتفاق، در توصیف ابزار list_market_signals صراحتاً به مدل دستور داده شده: «این مفروضات را در کنار عدد ذکر کن. null یعنی غیرقابل مدل‌سازی، که در unmodellableReason نام ورودی مفقود ذکر شده است: آن را به عنوان ناشناخته در نظر بگیر، هرگز صفر نگو. اعداد منفی در اینجا عادی هستند؛ اکثر معاملات این بازار سودده نیستند.»

علاوه بر این، ابزار get_property_intelligence یک حفاظ در جهت مخالف دارد. امتیازات این ابزار کاندیداها را رتبه‌بندی می‌کنند، اما هیچ‌کدام از آن‌ها «بازدهی» نیستند. این ابزار صراحتاً به مدل می‌گوید که این نقطه انتهایی (endpoint) هیچ رقم ROI ارائه نمی‌دهد و عامل را برای یافتن بازدهی به ابزار دیگر ارجاع می‌دهد. این رویکرد در راستای جلوگیری از شکست‌های خاموش در APIها از طریق اعتبارسنجی دقیق پاسخ‌هاست تا مدل دچار سردرگمی نشود.

درک عمیق مقادیر Null

قانون no_envelope_rule مربوط به هر قطعه زمین است، نه کل شهر. این قانون زمانی فعال می‌شود که هیچ متراژ مجاز سازمان‌یافته‌ای برای بازسازی یک خانه تک‌واحدی روی آن قطعه خاص وجود نداشته باشد. یک snapshot تولیدی از ۳ سپتامبر ۲۰۲۶ نشان داد که مقیاس این موضوع چقدر است: ۵۰۱ مورد از ۱۰۳۹ لیست فعال مدل‌سازی شده در این دسته قرار گرفتند.

• ۴۲۳ مورد کاندومینیوم، تاون‌هاوس و واحدهای چندخانوادگی بودند که هرگز «پوش متراژ» (envelope) نداشتند.
• ۵۶ مورد قطعات زمین در مناطق غیرشهری (unincorporated county) بودند.
• ۲ مورد خانه‌های تک‌واحدی بودند که نوبت بررسی متراژ آن‌ها هنوز نرسیده بود.
• ۲۰ مورد دارای پوش متراژ سازمان‌یافته‌ای بودند که بیش از چهار برابر خانه موجود بود (قانون‌ را به دلیل غیرمنطقی بودن عمداً نادیده گرفتند).

در این موارد، سیستم proforma به‌جای جایگزین کردن یک عدد پیش‌فرض، از ارائه عدد خودداری می‌کند. این تنها انتخاب قابل دفاع است، زیرا یک متراژ جایگزین، عددی تولید می‌کند که از عدد واقعی غیرقابل تشخیص است. این سخت‌گیری پس از آن اضافه شد که یک ملک در ساراتوگا به اشتباه با بازدهی ۳۹.۸٪ در لیست کوتاه داخلی قرار گرفت، چون با یک قانون ساده «متراژ موجود ضرب در ۱.۵» اندازه شده بود. در حالی که ماشین‌حساب روی صفحه هنوز یک مقدار پیش‌فرض برای تغییر توسط انسان ارائه می‌دهد، عددی که توسط API ارسال می‌شود هرگز آن را نقل نمی‌کند.

شکنندگی ثابت‌های متنی

از آنجا که توصیفات ابزار به صورت متن (Prose) نوشته می‌شوند، مثل هر متن دیگری قدیمی می‌شوند. موری دو شکست بحرانی را شناسایی کرد که در آن توصیف متنی با منطق زنده API فاصله گرفته بود:

۱. انحراف هزینه ساخت: توصیف ابزار list_market_signals به مدل می‌گفت فرض کند هزینه ساخت «۴۰۰ دلار در هر فوت مربع» است. اما در ۲۱ آگوست ۲۰۲۶، API این مقدار را به ۵۵۰ دلار به‌روز کرده بود. این تغییر سه روز پس از آخرین commit سرور رخ داد. رقم ۵۵۰ دلار نقطه میانی یک بازه تأیید شده بین ۴۰۰ تا ۷۰۰ دلار برای سازندگان است؛ ۴۰۰ دلار کف قیمت بود که تمام معاملات را زیباتر از آنچه بودند نشان می‌داد.

۲. تأثیر بر ROI: این تغییر کوچک نبود. در بررسی ۴۰۷ لیست فعال، تغییر هزینه سخت از ۴۰۰ به ۵۵۰ و سپس ۷۰۰ دلار، میانه ROI را از ۳.۹- درصد به ۱۴.۳- و سپس ۲۲.۹- درصد تغییر داد. تعداد قطعاتی که بازدهی خالص ۲۰ درصد را رد می‌کردند از ۶۰ مورد به ۲۸ و سپس ۱۵ مورد کاهش یافت.

چون به مدل گفته شده بود مفروضات را از «توصیف» نقل کند، مدل فعالانه عدد قدیمی را به کاربر نهایی گزارش می‌کرد، حتی اگر مقدار درست در بدنه پاسخ API وجود داشت. هیچ چیزی مدل را مجبور نمی‌کند فیلدی را که به او گفته نشده بخواند، بر جمله‌ای ترجیح دهد که به او گفته شده تکرار کند. یک عدد قدیمی در مستندات REST توسعه‌دهنده‌ای را گمراه می‌کند که احتمالاً متوجه آن می‌شود؛ اما یک عدد قدیمی در توصیف ابزار، به عنوان یک حقیقت برای کاربر خوانده می‌شود.

شکاف پنجره تاریخچه

شکست دیگری در لایه رایگان رخ داد. در ۳ سپتامبر ۲۰۲۶، تاریخچه لایه رایگان به ۳۰ روز محدود شد و کلیدهایی که قبل از ۴ سپتامبر ساخته شده بودند استثنا شدند. در حالی که پاسخ API شامل فیلد historyWindow بود، توصیف ابزار هرگز به آن اشاره نکرد. آرگومان صفحه‌بندی (paging) سرور صرفاً می‌گفت: «محدود به سقف لایه کلید API شما».

برای کاربری که می‌پرسید آیا در یک آدرس خاص مجوز ساخت صادر شده است، یک عامل لایه رایگان بر اساس ۳۰ روز گذشته پاسخ می‌داد. بدون دستورالعمل برای خواندن فیلد window، عامل نمی‌توانست تشخیص دهد که پاسخ «خیر» یک پاسخ واقعی است یا ناشی از محدودیت زمانی. این پنجره زمانی روی تاریخچه مجوزها در ابزار permits و ردیف‌های فروخته شده در list_market_signals اعمال می‌شود، در حالی که فید فعال (active feed) کامل باقی می‌ماند.

مورد سوم و جزئی از انحراف این بود که فایل src/index.ts خود را نسخه ۱.۱.۰ معرفی می‌کرد، در حالی که مانیفست پکیج و رجیستری روی نسخه ۱.۱.۲ بودند. این موضوع کسی را گمراه نمی‌کند چون یک رشته متنی است، نه دستوری که مدل بر اساس آن عمل کند.

تصمیمات لایه انتقال

فراتر از توصیفات، دو تصمیم در لایه انتقال برای ابزارهای عامل‌محور حیاتی است:

• جایگزین‌های احراز هویت: به‌جای بازگرداندن خطای ۴۰۱ برای کلیدهای API گم‌شده، سرور به یک رشته «demo» بازمی‌گردد. API این را به عنوان لایه عمومی می‌شناسد که به ۱۰ درخواست در دقیقه و ۵ ردیف در هر فراخوانی محدود است. این کار باعث می‌شود ابزار بلافاصله پس از نصب کار کند؛ در حالی که یک انسان وقتی به دیوار بخورد کلید می‌گیرد، یک عامل صرفاً گزارش می‌دهد که ابزار خراب است.
• شکل‌دهی خطاها: سرور به‌جای کدهای وضعیت خشک، رشته‌های خطای خوانا را از پوشش شکست API استخراج می‌کند. این به عامل می‌گوید که آیا باید پرس‌وجو را محدود کند، عقب‌نشینی کند یا از کاربر کلید بخواهد. یک کد وضعیت هیچ چیزی به مدل نمی‌گوید که بتواند بر اساس آن عمل کند. برای مثال، یک جستجوی ناموفق به‌جای null، عبارت { found: false, message: "No property found with ID: ..." } را برمی‌گرداند، زیرا نبود ملک در محدوده پوشش، یک پاسخ عادی است، نه یک شکست سیستمی.

علاوه بر این، API_BASE به‌جای URL خام App Hosting، به دامنه منتشر شده پیش‌فرض است. چون دومی با تغییر بک‌اِند جابجا می‌شود، سخت‌کد کردن آن در یک کلاینت نصب شده ریسک بزرگی است.

بخت‌آزمایی در توزیع

انتشار یک سرور MCP شامل ترکیبی از مانیفست‌های ماشین‌خوان و دایرکتوری‌های انسانی است. تجربه موری در ۷ سطح مختلف نشان داد که سیستم‌های خودکار تنها راه قابل‌اتکا برای کشف ابزارها هستند:

• موفقیت‌ها:
  • رجیستری رسمی MCP: لیست شد (v1.1.2) از طریق فضای نام احراز شده با DNS و مانیفستی که با اسکیما اعتبارسنجی می‌شود.
  • Glama: لیست و ایندکس شد؛ نیازمند CI، یک ریلیز تگ‌دار و فایل glama.json برای امتیاز نگهداری بود.
  • awesome-mcp-servers: در ۷ سپتامبر ۲۰۲۶ از طریق PR که با کنوانسیون‌های دسته‌بندی مخزن اصلاح شده بود، ادغام شد.
  • npm: نسخه ۱.۱.۲ از طریق CI با یک توکن scoped منتشر شد؛ shebang در فایل bin اجرای npx را فعال می‌کند.
• گلوگاه‌ها:
  • mcp.so: درخواست ارسال ۶۸ روز باز ماند؛ لایه پولی dofollow رد شد.
  • Smithery: توسط یک باگ در مسیر باندل که هر باندل اعلام‌کننده ابزارها را رد می‌کند، مسدود شد؛ ایشو از ژوئن باز است.
  • PulseMCP: ارسال‌ها برای بازسازی سیستم جذب داده متوقف شده است.

این نشان می‌دهد که توسعه‌دهندگان باید اولویت را بر مانیفست و پکیج بگذارند تا لیست‌های دایرکتوری که بیشتر شبیه به یک قرعه‌کشی هستند. از نظر پذیرش، npm در ۳۰ روز منتهی به ۱۳ اکتبر ۲۰۲۶، تعداد ۱۹۱ دانلود داشت (عمدتاً میرورها و کراولرها)، در حالی که PulseMCP بیش از ۲۱,۷۰۰ سرور را لیست کرده است. AddressIntel هرگز تجاری نشده و مشتری ندارد؛ بلکه به عنوان یک قابلیت منتشر شده و قابل نصب وجود دارد.

تغییر در طراحی API

این پروژه فاش کرد که بخش سختِ ارائه داده به عامل‌ها، پروتکل نیست، بلکه همراستاسازی معنایی (semantic alignment) است. آداپتور در یک بعدازظهر ساخته شد؛ اما تلاش واقعی صرف این شد که تصمیم بگیرند مدل اجازه دارد از هر فیلد چه نتیجه‌ای بگیرد و قرارداد را در برابر API زنده حسابرسی کنند. همین بررسی بود که انحراف هزینه ۴۰۰ دلاری و پنجره تاریخچه مفقود را پیدا کرد، مواردی که در کد، README یا تاریخچه commitها قابل مشاهده نبودند.

برای جلوگیری از مشکل «متن‌های قدیمی»، پایدارترین راه این است که بخش‌های متغیر توصیفات ابزار به‌صورت پویا و از همان ثابت‌هایی که API ارائه می‌دهد تولید شوند، نه با دست. وقتی یک عامل به عنوان رابط عمل می‌کند، هر نکته‌ای که پیش‌تر در پاورقی بود باید به یک دستورالعمل ماشین‌خوان تبدیل شود.

اگر ابزار MCP می‌سازید، توصیفات خود را امروز حسابرسی کنید: آیا به مدل می‌گویید با یک مقدار null چگونه برخورد کند، یا اجازه می‌دهید حدس بزند؟

گام بعدی شما

• اگر ابزار MCP می‌سازید، توصیفات متنی خود را بازبینی کنید: آیا به مدل گفته‌اید با مقادیر null چه کند یا اجازه داده‌اید حدس بزند؟
• بخش‌های متغیر توصیفات (مانند قیمت‌ها یا محدودیت‌ها) را از حالت استاتیک خارج کرده و به‌صورت پویا از API بخوانید.
• برای هر فیلد مبهم، یک دستورالعمل صریح «تفسیر داده» در توصیف ابزار اضافه کنید.

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