🔠🔠🔠 What is the Model Context Protocol (MCP)?


➖ MCP is an open standard developed by Anthropic that standardizes how AI applications, particularly large language models (LLMs), connect to external data sources and tools. It simplifies integrations by providing a universal protocol, like a USB-C for AI, enabling secure, scalable, and context-aware interactions without custom APIs for each tool or data source.


🟡AI assistants have entered their intern era. They'll ace any single task you throw at them—analyzing PDFs, generating SQL, cracking dad jokes about Kubernetes—but ask them to coordinate across Slack, Gmail, and Jira? Now you're debugging a Rube Goldberg machine of API keys.


🟡 Anthropic's Model Context Protocol (MCP) aims to standardize this mess. For users, it means connecting AI models to your Figma file and Linear tickets without needing a CS degree. For developers, it means fewer "why is the model just returning goat emojis" moments.


➖➖➖➖➖➖
📚 Article: [here]
➖➖➖➖➖➖
#AI #LLM #MCP


🖥 Follow @devDastan for more content.

شرکت OpenAI میخواد که ویرایشگر کد Windsurf رو به قیمت ۳ میلیارد دلار خریداری کنه. این ویرایشگر که قبلا Codeium نام‌ داشت و کارش رو با عرضه اکستنشن‌ روی وی‌اس‌کد شروع کرده بود، امسال ویرایشگر مبتنی بر هوش مصنوعی خودش رو عرضه کرد و نامش رو هم تغییر داد. این خرید گرون‌ترین خرید OpenAI تا امروز خواهد بود و احتمالا سیر خرید ادیتورها رو به زودی توسط شرکت‌های دیگه هم ببینیم.

🔗 bloomberg
🤓 hadi @geekalerts

قسمت دوم (پایانی)

بعد از تلاش برای باز تولید مشکل هیچ پیغام خطا یا کرش واضحی وجود نداشته. stack trace مشخصی هم روی صفحه دیده نمی‌شده. فقط سکوت محض تا لحظه پیدا شدن یه خطای runtime error که از لایه‌های عمیق اون SDK آپدیت‌شده‌ی Apple Pay سرچشمه می‌گرفت.داشته سعی می‌کرده از یه method خاص استفاده کنه که توی محیط بعضی از مرورگرهای قدیمی‌تر اصلاً پشتیبانی نمی‌شده. نکتش اینجاس که Apple Pay فقط روی سافاری کار می‌کنه پس این خطا فقط روی نسخه های قدیمی سافاری خودشو نشون میداده. SDK موقع بالا اومدن و مقداردهی اولیه از یه تابع استفاده می کرده که باعث کرش می‌شده. نه فقط برای خود Apple Pay، بلکه برای همه چی! از همون باگ‌های موذی که موقع توسعه از زیر دست در میره و دیده نمی‌شه.

فقط درست کردن باگ مهم نیست؛ بحث سرِ قبول مسئولیت کاره

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

- این خرابی و قطعی، واقعاً چه معنی و تجربه‌ای برای کاربر داشت؟

- این قطعی چقدر برای کل کسب‌وکار هزینه برداشت؟

- آیا می‌شد این مشکل رو زودتر تشخیصش داد؟

- ممکنه دوباره همچین اتفاقی بیفته؟

ما اینجا نیستیم که فقط مثل ربات به آلارم‌ها واکنش نشون بدیم و کدها رو سرسری وصله‌پینه کنیم و ما کدنویس‌هایی نیستیم که بشه مثل ChatGPT بهمون پرامپت داد و انتظار داشت مشکل غیب بشه. اینجاییم که عمیق فکر کنیم، مسئولیت کامل نتایج کارهامون رو به عهده بگیریم و فعالانه جلوی آسیب‌های آینده رو بگیریم.

پس برای مستند کردن چه چیز هایی رو میتونیم بنویسیم؟

- چی رو تغییر داده بودیم

- اصلاً چرا تغییرش داده بودیم

- چی و کجا خراب شد

- چطور شد که این مشکل از زیر دست تیم QA در رفت و دیده نشد

- چه چیزهایی توی monitoring ما از قلم افتاده بود که زودتر نفهمیدیم

این کار رو نه به خاطر اینکه کسی خواسته انجام بدیم، بلکه به این دلیل انجام بدیم که شاید خودِ آینده (یا یکی از هم‌تیمی‌های آینده‌) به مشکل مشابهی بر بخوره و اون‌ها بتونن خیلی سریع‌تر به جواب و راه حل برسن.

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

جمع‌بندی و حرف آخر

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

ولی خب، آدم یاد می‌گیره.

یاد می‌گیری که «قبول کردن کامل مسئولیت» واقعاً یعنی چی.

یاد می‌گیری که چطور یه قدم بری عقب‌تر و دید وسیع‌تری پیدا کنی (zoom out کنی)؛ دیگه فقط به این فکر نکنی که «چی خراب شد؟»، بلکه بری سراغ اینکه «این خرابی روی چه کسایی تأثیر گذاشت؟».

یاد می‌گیری که یه مهندس خوب بودن، به معنی نوشتن کدِ بی‌عیب‌ونقص و عالی نیست؛ بلکه به اینه که چطور بحران رو مدیریت می‌کنی، وقتی که اوضاع اصلاً خوب و عالی نیست.

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

- سریع نپرین سراغ دیباگ کردن: اگه مشکل جدیه و روی کاربرها تأثیر مستقیم گذاشته، اولین قدم اینه که کد رو برگردونین به نسخه‌ی قبلی. بعدش با خیال راحت‌تر برین دنبال دلیل مشکل بگردین.

- زود و شفاف اطلاع‌رسانی کنین: حتی یه پیام کوتاه مثل «دوستان دارم بررسی می‌کنم» توی کانال‌های ارتباطی خیلی تأثیر مثبتی داره و به آروم شدن فضا کمک می‌کنه.

- سعی کنین مشکل رو توی محیط‌های کنترل‌شده و ایزوله باز تولید کنین: یعنی دقیقاً با همون شرایطی که مشکل پیش اومده (مثلاً همون مرورگر، همون نسخه و ...).

- لاگ‌ها، درخواست‌های شبکه، و نحوه‌ی مدیریت خطاها رو با دقت چک کنین: هیچوقت فرض نکنین که اگه مشکلی باشه، حتماً سیستم با سر و صدای زیاد کرش می‌کنه و سریع متوجه می‌شین! گاهی مشکلات خیلی بی‌سر و صدا اتفاق می‌افتن.

- آستانه‌ی هشدارهای سیستم پایش و مانیتورینگ رو دوباره یه نگاهی بندازین: آیا واقعاً جوری تنظیم شدن که خرابی‌های کوچیک، نامحسوس یا تدریجی رو هم زود تشخیص بدن؟

- اتفاقی که افتاده رو با زبون ساده و واضح مستند کنین: این کار رو فقط برای بقیه اعضای تیم انجام ندین، بلکه برای خودتون در آینده هم انجام بدین. حافظه یاری نمی‌کنه!

- به تأثیر مشکل روی کسب‌وکار (business impact) فکر کنین: حدوداً چند تا کاربر تحت تأثیر قرار گرفتن؟ و این مشکل برای چه مدت زمانی ادامه داشت؟

- اگه در حین بررسی، به الگوها یا نکته‌های کلیدی رسیدین، حتماً یادداشتشون کنین: این نکته‌ها برای بحران بعدی فوق‌العاده ارزشمندن.

—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily