Претоварване на отговорностите на MCP
Една често срещана критика е, че на MCP се възлагат твърде много отговорности. Авторът твърди, че MCP трябва да служи предимно като шлюз за LLM за достъп и взаимодействие с външни ресурси. Разглеждането му просто като ‘врата’ или ‘мост’ помага да се изяснят неговата цел и ограничения.
Приписването на проблеми като случайно излагане на данни, уязвимости при инжектиране на подкани и недостатъци в контрола на разходите директно на MCP е погрешно възлагане на вината. Това са проблеми, които разработчиците трябва да решат в рамките на границите, които контролират. Разработчиците трябва да прилагат ограничения на скоростта и да следят използването, независимо от използвания протокол. Приравняването на това към обвиняване на пътя за превишена скорост е уместно – инфраструктурата не е отговорна за индивидуалното поведение.
В крайна сметка, много от повдигнатите опасения са по-широки въпроси, свързани с делегирането на задачи на AI агенти. Разработчиците трябва да поемат отговорност за управлението на тези предизвикателства в рамките на своите специфични приложения, вместо да очакват самият API да се справи с всичко.
Двойният ръб на LLM и инжектирането на подкани
Неотдавнашните дискусии около MCP често приличат на предупреждения за присъщите опасности от острите ножове – те могат да режат, ако се борави с тях неправилно. Инжектирането на подкани, сериозен проблем, е следствие от самата природа на LLM. Опитите за елиминиране на риска от инжектиране на подкани биха влошили самите възможности, които правят LLM ценни.
Представата за разделение между ‘контрол и данни’, често срещана в традиционните системи, не съществува естествено в LLM. LLM придобиват своята сила и общност именно защото им липсва това строго разделение. Тази присъща характеристика ги прави уязвими на атаки чрез инжектиране на подкани.
Въпреки че отдалечените MCP като услуга може да представляват рискове, вината не е в самия протокол, а в поверяването на чувствителни задачи на ненадеждни трети страни. Тази аналогия се простира до идеята за залепване на нож към нестабилен Roomba – проблемът не е в самия нож, а в решението да го прикрепите към непредсказуемо устройство.
Съветите да ‘бъдете внимателни’ или предложенията за защитна екипировка, макар и технически точни, пропускат основния проблем: необмисленото решение да се комбинира остър инструмент с неконтролирана система.
Предизвикателства при мащабиране
Освен опасенията за сигурността, MCP е изправен пред основни ограничения за мащабиране. Авторът подчертава отрицателната корелация между надеждността на LLM и количеството предоставена инструктивна информация. Това оспорва общоприетото мнение, че добавянето на повече данни и интеграции автоматично ще реши проблемите. С увеличаването на броя на инструментите и интеграциите, ефективността на агента може да се влоши, като същевременно се увеличи цената на всяка заявка.
Авторът подчертава, че MCP не се мащабира отвъд определен праг. Опитът да се добави неограничен брой инструменти към контекста на даден агент неизбежно ще повлияе отрицателно на неговите възможности. Това ограничение е присъщо на концепцията за MCP и изисква повече внимание от проблемите с удостоверяването.
Потребителите могат в крайна сметка да изпитат спад в производителността, тъй като активират повече MCP сървъри, което води до смущения между тях. Това е в рязък контраст с типичните системи за управление на пакети, където ненамесата е основно свойство.
Основният проблем с MCP е, че действителното му поведение се отклонява от очакванията на потребителите. От решаващо значение е да се признае, че MCP не е решение, което може да се включи и използва и което безпроблемно интегрира неограничен брой инструменти без последствия.
Адресиране на ограниченията с потребителски интерфейс и управление на инструменти
Едно предложено решение за ограниченията на MCP е да се подобри потребителският интерфейс. Ако даден инструмент бъде изпълнен неволно, потребителският интерфейс трябва да осигури лесен начин да го деактивирате или да промените описанието му, за да изясните предвидената му употреба.
Авторът също така отбелязва, че растежът на контекста често води до подобрена производителност и възможности за използване в реалния свят, което противоречи на представата за строго отрицателна корелация. Въпреки това, те признават, че в определени случаи на употреба или с лошо проектирани контексти, може да възникне влошаване на производителността.
За да се справи с огромния избор от инструменти, се предлага подход ‘разделяй и владей’. Това включва добавяне на инструмент, специално проектиран за избор на най-подходящите инструменти за дадена задача. Този ‘инструмент за избор на инструменти’ може да бъде друго LLM повикване, натоварено със задачата да върне подмножество от наличните инструменти на ‘родителския’ агент. Този многослоен подход добавя допълнителни нива на индиректност за управление на сложността.
Въпреки това, простото наличие на инструменти в контекста може значително да промени изхода на модела. Въпреки че контекстуално релевантните инструменти (постигнати чрез техники като Retrieval-Augmented Generation или RAG) са полезни, скриването на всички инструменти зад заявка ‘get_tools’ може да бъде вредно.
MCP като транспортен и авторизационен слой
MCP функционира предимно като транспортен и кабелен формат с цикъл на заявка/отговор, като се фокусира върху оторизацията на ниво инструмент. Есето твърди, че най-големият проблем с MCP е невъзможността му да позволи на AI агентите функционално да композират инструменти.
Авторът постулира, че MCP може да е ненужен на първо място, тъй като LLM вече притежават възможността да взаимодействат с API, документирани с помощта на OpenAPI спецификации. Липсващият елемент е оторизацията – способността да се контролира до кои API може да има достъп AI. Вместо MCP, авторът предлага да се позволи на AI да извършва HTTP заявки, като същевременно се прилага оторизация към конкретни крайни точки. Този подход е в съответствие с настоящата тенденция за обвиване на съществуващи API с тънки MCP инструменти.
Особено досаден аспект на MCP е липсата му на поддръжка за поточно предаване на резултати от извикване на инструменти. Единичната двойка заявка/отговор принуждава клиентите многократно да извикват инструменти за номериране, възпрепятствайки дълготрайни процеси. Внедряването на възможност за поточно предаване, може би с помощта на gRPC, може значително да подобри ефективността на MCP.
Леснотата на излагане на чувствителни данни
Значителна загриженост относно MCP е потенциалът за лесно излагане на чувствителни данни. Освен това MCP не прави непременно AI агентите по-надеждни; той просто им предоставя достъп до повече инструменти, което парадоксално може да намали надеждността в определени ситуации.
Авторът признава, че не очаква MCP да реши или да бъде отговорен за всички тези проблеми. По-скоро MCP създава по-голяма повърхност за тези проблеми, изисквайки от разработчиците на приложения и потребителите да бъдат бдителни.
Аналогии и градско планиране
Авторът използва аналогията на градското планиране, за да илюстрира проблема. Сравняването на MCP с шестлентов градски път с ограничение на скоростта от 40 км/ч подчертава разминаването между дизайна и предвидената употреба. Простото налагане на глоби или добавянето на повърхностни ‘поправки’ не решава основния проблем с лошия дизайн.
Ефективното градско планиране включва проектиране на пътища, които естествено насърчават спазването на ограниченията на скоростта. По същия начин, MCP трябва да бъде проектиран така, че по същество да смекчава потенциалните рискове, вместо да разчита единствено на външни контроли.
LLM предприемат нежелани действия
Статията се премества към по-широка критика на протоколите, които позволяват на LLM да изпълняват действия върху услуги. Авторът идентифицира основен проблем: LLM могат да предприемат действия, които потребителите не възнамеряват да предприемат. Те разграничават действията, които LLM могат да предприемат независимо, и тези, които изискват потребителски подкани.
Въпреки че крайната цел може да бъде LLM да управляват цели бизнеси, технологията все още не е готова за такава автономност. Понастоящем потребителите може дори да не искат AI да изпраща имейли без предварителен преглед.
Авторът отхвърля решението да подкани потребителя за потвърждение, позовавайки се на риска потребителите да попаднат в модел на автоматично потвърждение (‘YOLO-mode’), когато повечето инструменти изглеждат безвредни. Това се оприличава на психологическия феномен, при който хората харчат повече с карти, отколкото с пари в брой – проблем, вкоренен в човешкото поведение, а не в технологията.
Основният въпрос: Защо просто да не използвате API?
Повтарящ се въпрос в дискусиите за MCP е защо просто да не използвате API директно.
MCP позволява на LLM клиенти, които потребителите не контролират директно (например, Claude, ChatGPT, Cursor, VSCode) да взаимодействат с API. Без MCP, разработчиците ще трябва да изградят персонализирани клиенти, използващи LLM API, което е много по-скъпо начинание, отколкото използването на съществуващи клиенти с абонамент и обучението им как да използват конкретни инструменти.
Един разработчик споделя своя опит в изграждането на MCP сървър за свързване към техния FM хардуерен синтезатор чрез USB, което позволява звуков дизайн, управляван от AI.
Интеграция и стандартизация на LLM клиенти
Основният проблем е, че не всички LLM клиенти поддържат директно взаимодействие с API, като персонализираните GPT действия на ChatGPT са забележително изключение. Anthropic, Google и OpenAI са се съгласили да приемат MCP като споделен протокол, за да рационализират процеса за клиенти, захранвани от LLM, като Claude, ChatGPT и Cursor.
MCP опростява процеса за тези, които изграждат LLM клиенти. Ако искате LLM да взаимодейства с API, не можете просто да предоставите API ключ и да очаквате да работи – трябва да създадете агент.
MCP може да се разглежда като начин за документиране на API и описване как да ги извиквате, заедно със стандартизирани инструменти за излагане на тази документация и улесняване на повикванията. Той осигурява достатъчно абстракция, за да обвие API без ненужно усложняване, но тази простота може също така да доведе до това потребителите да ‘си вкарат автогол’.
Ефективността и повторната използваемост на MCP
Без MCP, разработчиците трябва многократно да обясняват на LLM как да използва инструмент всеки път, когато се извиква. Това носи риска LLM да не успее да използва инструмента правилно поради забравена информация или нестандартно поведение на API.
Това постоянно обяснение и дублиране хаби токени в контекста, увеличавайки разходите и времето. MCP рационализира този процес чрез групиране на цялата необходима информация, което прави използването на инструменти по-ефективно и улеснява споделянето на инструменти.
Като казвате на LLM доставчик ‘ето инструмент, който можете да използвате’ заедно с документацията на API, потребителите могат да използват повторно този инструмент в множество чатове без многократни напомняния. Това също така позволява на настолните LLM клиенти да се свързват с програми, работещи локално, като решават проблема със специфичните за ОС процеси на изпълнение.
MCP и достъп до локални ресурси
MCP улеснява достъпа до локални ресурси като файлове, променливи на средата и мрежов достъп за LLM. Той е проектиран да работи локално, предоставяйки на LLM контролиран достъп до тези ресурси.
Стандартната ‘форма’ за извикване на LLM инструмент отразява отблизо ‘формата’ за извикване на MCP инструмент, което го прави ясен стандарт за свързване на инструменти към агенти.
MCP действа като мост между схемата за извикване на функции, изложена на AI модела, и основните API. Той преобразува извикванията на функции в инструменти, позволявайки безпроблемна комуникация.
Ако сте доставчик на инструменти, MCP предлага стандартизиран протокол за AI агентски интерфейси да се свързват към вашия инструмент. Това отговаря на въпроса защо стандартният протокол не може просто да бъде HTTP и OpenAPI.
MCP е мета-API, което включва крайни точки и техните оперативни детайли в спецификацията, което позволява на LLM да взаимодействат с тях по-ефективно.
MCP в конкретни сценарии
MCP може да реши проблеми, когато потребителите задават въпроси или не са сигурни кои API да използват. Той може също така да обработва заявки въз основа на предишни съобщения.
Един потребител споделя своя опит да иска да извлече ‘X’ на потребител и да го изпрати до крайна точка. Те откриха, че MCP е прекалено много за такава проста задача, което показва, че не винаги е необходимо за основни взаимодействия с API.
MCP се оприличава на уеб рамка на FastAPI за изграждане на софтуер, който може да комуникира по мрежата, специално проектиран за агентни изживявания. Той може да се разглежда като ‘Rails-for-Skynet’, осигуряващ стандартизирана рамка за разработване на AI агенти.
Опасения относно контрола на доставчика
Има опасения, че MCP се налага, за да се увеличи контролът на доставчика върху системата. LLM доставчиците в крайна сметка може да ограничат достъпа до API, подобно на това как Google затрудни използването на IMAP/SMTP с Gmail.
Използването на OpenAPI позволява на агентите да извличат API спецификации от /openapi.json.
MCP дава възможност за бързи взаимодействия, позволявайки на потребителите да изпълняват задачи за секунди, вместо да прекарват време в подготовка на входни данни, изпращане до API, анализиране на изхода и повтаряне на процеса за всяко съобщение.
Пясъчна среда и рискове за сигурността
Един от най-големите проблеми е как изходът на един MCP сървърен инструмент може да повлияе на други инструменти в същата нишка на съобщения. Това налага пясъчна среда между инструментите, за да се предотвратят непредвидени последствия. Invariant labs адресира това с описания на инструменти, докато други са използвали MCP прикачени ресурси. Липсата на пясъчна среда изостря рисковете от инжектиране на подкани.
Това се оприличава на SQL инжектиране – система, сглобена набързо, където уязвимостите могат да бъдат експлоатирани във всяка точка с минимална възможност за наблюдение.
Интерфейсът за подкани също е податлив на форма на SQL инжектиране, тъй като моделът не може да различи надеждните части на подканата от въведените от потребителя данни. Решаването на това изисква основни промени в кодирането, декодирането и обучението на модели.
Това позволява както инжектиране на подкани, така и инжектиране на инструменти, което потенциално води до изпълнение на ненадежден код.
Контейнеризация и контролиран достъп
Един разработчик създаде MCP сървър, който стартира Docker контейнер с монтиран код на проект. Този подход позволява на LLM да има достъп до целия набор от инструменти на Unix и специфични за проекта инструменти в пясъчна среда.
Този агентски работен процес, задвижван чрез базиран на чат интерфейс, се е оказал по-ефективен от традиционните методи.
Ключът е да се предостави на MCP агентите достъп до това, от което се нуждаят, и нищо повече. Контейнеризацията и прозрачният потребителски интерфейс на инструментите са от решаващо значение за смекчаване на рисковете за сигурността.
Виртуални машини и достъп до интернет
Предоставянето на агентите на компютър с минимална инсталация на Linux (като VM или контейнер) може да даде по-добри резултати, което им позволява да извличат информация от интернет. Въпреки това, това повдига опасения за сигурността по отношение на злонамерени инструкции и извличане на данни.
Ограничаването на достъпа до надеждни уебсайтове може да смекчи някои рискове, но дори надеждни източници могат да хостват злонамерено съдържание. Трябва внимателно да се обмисли компромисът между вероятността от срещане на злонамерени инструкции и ползите за производителността.
Разликите между служителите и AI агентите са значителни. Служителите са юридически лица, подчинени на закони и договори, осигуряващи отчетност. AI агентите нямат тази правна рамка, което затруднява доверието.
Ранните етапи на развитие на MCP
MCP беше обявен едва през ноември 2024 г. и RFC активно се развива.
Някои смятат цялата концепция за AI личен асистент, включително MCP, за фундаментално погрешна.
Първоначалният тласък за AI асистенти в края на 90-те и началото на 2000-те години се провали, защото агрегаторите на съдържание с вертикална интеграция и сила за масово закупуване се оказаха по-ефективни. Това доведе до възхода на платформи като Expedia и eBay.
Системите с много агенти изискват програмистите да влияят на състоянието на агентите, което е трудна задача за програмиране.
Границите на безплатната стойност
Желанието за ‘класиране на резултатите според наличността на паркинг’ подчертава проблема с достъпа до данни зад платени API или поддържани от реклами интерфейси. Малко вероятно е компаниите да предоставят безплатен достъп до целия си набор от данни чрез API.
Въпреки че не всички компании ще интегрират своите данни в AI агенти, потенциалът за комбиниране на различни инструменти за захранване на работни процеси остава значителен.
Компаниите, които дават приоритет на поддържането на ров от данни, вероятно ще се съпротивляват на новите технологии, които заплашват този ров.
Ако booking.com имаше API, те вероятно ще върнат същите резултати като техния уебсайт, вероятно с JSON или XML форматиране.
Преминаване на посредника
Няма много смисъл посредник като booking.com да позволява на потребителите напълно да заобиколят техните услуги.
Въпреки това, отделните хотели може да намерят за полезно да заобиколят booking.com, посредник, който често не харесват.
Deep Research AI може да сканира за хотели въз основа на конкретни критерии и да взаимодейства с Hotel Discovery MCP сървъри, работещи от отделни хотели, заобикаляйки необходимостта да се навигира в интерфейса и рекламите на booking.com.
Практически случаи на употреба
MCP може да улесни задачи като извличане на логове от Elasticsearch или заявки към бази данни по по-структуриран начин.
Статичният характер на конфигурацията на MCP сървъра, където новите сървъри изискват редактиране на .json файл и рестартиране на приложението, може да бъде ограничаващ.
Фино настроени модели
MCP може да се разглежда като малък, фино настроен модел, който разбира множество MCP инструменти и избира правилните за всеки разговор.
Динамичното коригиране на инструментите въз основа на контекста може да е необходимо за определени сценарии.
Отворени разговори и бизнес проблеми
MCP е подходящ за общи, отворени системи за разговори без предварително зададен поток. Въпреки това, това не е решение за всеки бизнес проблем. Той не е предназначен да замени рамки като LangChain.
Алтернативата на MCP, отворен стандарт, управляван от общността, е разпокъсан, патентован и заключен от доставчика протокол. Дефектен, но развиващ се стандарт е за предпочитане пред липсата на стандарт.
Най-добрият начин да разглеждаме MCP е като преминаване от индивидуални разработчици, изграждащи обвивки на клиенти около API, към доставчици на API или поддържани от общността обвивки, които ги изграждат. Това осигурява голям набор от инструменти, подобен на NPM или PyPi. Въпреки това, оркестрацията, сигурността и дефиницията на употреба все още се изискват.
Следващото поколение Langchain ще се възползва от този по-голям набор от инструменти, но все още са необходими иновации.
Специфични за потребителя инструменти
В някои случаи инструментите може да са специфични за потребителски данни, като например инструменти за нарязване и манипулиране на качени CSV файлове.
Един често пренебрегван проблем е, че MCP може да пренасе контекста на модела с твърде много опции. Приоритизирането и излагането на метаданни са от решаващо значение, за да се избегне прахосването на токени и непостоянното поведение на модела.
Стандарти и развиваща се технология
Новите стандарти се появяват с течение на времето и е минало толкова много време, откакто стандартите наистина имат значение, че хората са забравили как се развиват.
Изтеглянето на малки сървърни програми от случайни разработчици за добавяне на ‘инструменти’ към LLM клиенти може да бъде рисковано.
Повдигнатите въпроси са легитимни проблеми, които екосистемата на MCP трябва да реши. Някои решения ще бъдат в рамките на спецификацията на MCP, докато други ще бъдат външни.
Claude Code и използване в реалния свят
Има противоположни мнения относно успеха на MCP. Някои са чували истории за компании, интегриращи се с MCP, докато други са чували от потребители, които са го намерили за разочароващ.
Това подчертава недостатъка на хайпа и ранното приемане.
Някои разработчици смятат, че HTTP API са по-добри от MCP за повечето случаи на употреба. Те твърдят, че използването на ‘инструменти’ се свежда до API крайни точки за възможности и функционалност.
API не са самоописващи се по подразбиране, което представлява пропусната възможност за поддръжниците на REST и HATEOAS да покажат своите подходи.
MCP като алтернатива на LangChain?
MCP е описан като имащ ‘миризма на LangChain’ – не решава спешен проблем, е прекалено абстрактен и има трудности да обясни предимствата си.
Може би трябва да каже ‘КРАЙ НА РЕДА’ и да прогони бъдещите хакери в игралната мрежа!
Ключов въпрос е дали ‘общият’ Чатбот парадигма ще се запази. Специализираните приложения със собствени инструменти може да не се нуждаят от MCP.
И обратно, тъй като LLM стават по-способни, външните инструменти може да станат по-малко необходими. Защо бихте искали MCP да управлява Photoshop, когато LLM просто може да редактира изображението директно?
Мечтата за научнофантастичен робот асистент може да не се материализира и специализираните инструменти за манипулиране на езика може да са по-полезни.
Потребителската база и осведомеността за сигурността
Потребителската база на MCP включва по-малко технически лица, което прави проблемите със сигурността особено актуални. Повишаването на осведомеността за най-добрите практики за сигурност е от решаващо значение.
Базирането на Xops на OpenRPC, което изисква дефиниране на схемата на резултатите, помага да се планира как изходите се свързват с входовете, подобрявайки надеждността за сложни работни процеси.
Технологията вероятно ще се развие и установи с течение на времето.
Редундация и облачна инфраструктура
Някои поставят под въпрос ползите от използването на MCP пред стандарта OpenAPI, като го разглеждат като излишен.
Какво ще използва LLM, за да извика система OpenAPI? Как ще се свърже към обвивката? Как хостът на LLM ще организира това?
MCP осигурява структуриран начин за LLM да извършват повиквания на инструменти.
MCP сървърите вече са HTTP сървъри.
Най-голямото предимство на MCP е за LLM доставчици като OpenAI, а не за разработчици на приложения.
LLM са мозъци без инструменти и извикването на инструменти ги овластява. Въпреки това, с нормални API, LLM доставчиците нямат достъп до тези инструменти. MCP им предоставя достъп, позиционирайки ги като портал към AI.
CLI vs. API
Защо да не използвате CLI директно, като се има предвид, че LLM са обучени на естествен език и CLI са често срещано човекочитаемо и писмено решение?
MCP се появи твърде бързо и се нуждае от време, за да узрее. Липсва проверка от конвенционален орган за стандарти и се задвижва от хайп.
Има липса на приложения в реалния свят.
Ключови приложения на MCP
MCP се използва в Claude Desktop и нишови AI чат приложения, инструменти за автоматизация на кода и рамки за автоматизация на агенти/LLM.
Това е друга прибързана технология, която вероятно ще бъде изхвърлена, когато пристигне следващият акроним, подлежащ на хайп.
Има два вида протоколи за извикване на инструменти за езикови модели: тези, от които хората се оплакват, и тези, които никой не използва.
Anthropic разработи този ‘стандарт’ във вакуум, което доведе до проблеми със сигурността.
JSON-RPC 2.0
MCP е изграден върху JSON-RPC 2.0, лек протокол, който позволява комуникация между клиент и сървър с помощта на JSON.
Той се усеща като централизирана спецификация, предназначена за конкретна екосистема, твърдяща универсалност, без да я печели.
MCP е достатъчно мощен, за да прави полезни неща, което повдига опасения за сигурността.
Това не е зрял стандарт и не е проектиран да бъде сигурен.
Въпреки че съществуват препоръки, те не се прилагат или изпълняват.
Langchain и извикване на инструменти
Langchain е една от многото рамки, които прилагат модела ‘извикване на инструменти’.
MCP е спецификация за това как външната информация навлиза в контекстния прозорец на езиковия модел, включително извикване на инструменти, шаблонен вход, анулиране, проследяване на напредъка и състояние на сървърите на инструменти.
Той помага да се стандартизират детайлите, така че всяка комбинация от асистент/интеграция да е съвместима.
Въпреки че MCP има легитимни проблеми, критиците трябва да усъвършенстват аргументите си.
Удостоверяването е от решаващо значение и не трябваше да бъде пропуснато от първоначалната версия.
Има твърде много сложности.