Dati, ang pagkonekta ng N tool sa M model ay nangangailangan ng N×M adaptation layers. Pinaghihiwalay ng MCP ang tool side at model side para minsan lang ipatupad ng bawat panig ang protocol. Tinatalakay rito ang disenyong ito, ang abstraction ng browser environments at page actions, at ang mga problemang hindi pa nito nalulutas.
Kapag kailangang gumawa ng aktuwal na trabaho ang isang Agent, kadalasan ay sa browser ito nauuwi: pag-login, pag-post, pagkuha ng data, o pag-fill out ng form. Ang mahirap sa teknikal na bahagi ay hindi kung kaya nitong mag-click, kundi ang integration cost ng pagbibigay ng browser sa isang Agent.
Ang N×M na bitag ng adaptation
Ipagpalagay na may N tool at M model sa merkado. Kailangang gumawa ang tool provider ng hiwalay na integration para sa bawat model, habang kailangan din ng model side ng adaptation layer para sa bawat tool. Kapwa nila pinananatili ang sarili nilang implementation, kaya N×M ang kabuuan.
Ang problema ay multiplication ito. Ang pagdagdag ng isang tool ay hindi lang isang dagdag na trabaho; kailangang ikonekta ang tool na iyon sa bawat model. Sa kabilang banda, kapag nagpalit ng bersyon ang isang model, maaaring kailangang muling i-validate ang mga tool na nakakonekta na. Kahit mahusay ang isang capability, kung walang adapter para sa partikular na model, hindi ito magagamit doon—naiipit ang tool sa distribution layer.
Noong una, kanya-kanyang implementation lang ang posible. Para sa parehong gawain—paglista ng environments, pagsisimula ng browser, pagbabasa ng page—kailangang magsulat ulit kapag iba ang caller, at madalas ding hindi pare-pareho ang logic: may naglalagay ng waiting sa client, at may naglalagay nito sa server.
Pinaghihiwalay ng protocol ang dalawang panig
Ang MCP (Model Context Protocol) ay ginawang pampubliko sa pagtatapos ng 2024. Ang paraan nito ay gawing standard format ang tool discovery at invocation: kung ano ang inilalabas, paano inilalarawan ang parameters, at anong structure ang ibinabalik ay tinutukoy sa protocol.
Dahil dito, nagiging Agent na nakakonekta sa isang MCP Client ang architecture. Kumokonekta ang Client sa maraming MCP Server ayon sa protocol, at nasa likod ng mga Server ang aktuwal na capabilities. Bumababa ang implementation mula N×M tungo sa N+M: isang beses lang ipinatutupad ng model side ang client at isang beses lang ng tool side ang server.
Tatlo lang ang roles. Ang Host ang application na nagpapatakbo sa model at nagsisimula sa client. Ang Client ang implementation ng protocol client, karaniwang isa para sa bawat Server. Ang Server naman ay ginagawa ng tool provider at inilalabas ang capabilities bilang standardized tools.
May dalawang paraan ng communication sa kasalukuyan. Gumagamit ang local mode ng standard input at output, at nasa iisang machine ang client at server; maikli ang path at kaunti ang configuration kaya karaniwan ito sa automation. Gumagamit naman ang remote mode ng HTTP o WebSocket at bagay sa distributed deployment, ngunit kailangan ng mas maingat na pagdisenyo ng authentication at network boundaries.
Sa browser, tatlong layer ang inilalabas
Kapag ikinonekta ang browser environment sa protocol, karaniwang nahahati sa tatlong layer ang exposed capabilities.
Sa itaas ay ang environment: ilista ang environments sa account, gumawa ng bago batay sa configuration, simulan ang isang partikular na environment, ikabit dito ang network egress, at isara pagkatapos gamitin. Dati ay kalat ang mga operasyong ito sa iba’t ibang API; ngayon ay mga tool na puwedeng tuklasin at tawagin ng model. Karaniwang nagbabalik ang pagsisimula ng debugging endpoint, gaya ng port o WebSocket address, na maaaring ipasa sa mga driver tulad ng Selenium o Puppeteer.
Sa gitna ay ang page: magbukas ng address, basahin ang DOM o accessibility tree, magpalit ng tab, at kumuha ng screenshot.
Sa ibaba ay ang actions: pag-click, pag-type, pag-scroll, paghihintay sa isang kondisyon, at paghawak ng pop-up.
Ang mahalagang pagbabago ay hindi kung gaano karaming action ang mayroon. Ang environment ay nagiging resource na maaaring piliin at gamitin ng Agent, sa halip na code na kailangan mong isulat mismo. Kailangan mo lang linawin ang layunin; maaari nitong piliin kung gagawa ng bagong environment o gagamit muli ng kasalukuyan, at kung anong pagkakasunod-sunod ng calls ang gagawin. Mas malinaw ito kapag maraming environment ang sabay-sabay: nasa prompt ang scheduling sa halip na hard-coded sa script.
Mga hindi pa nalulutas sa kasalukuyan
Connection ang nilulutas ng protocol, hindi correctness. May ilang puntong madaling makaligtaan.
Nakadepende sa kalidad ng tool descriptions ang resulta ng invocation. Kung mali ang parameters o maling tool ang napili, hindi iyon maaayos ng protocol. Kapag dumami ang tools, kumakain din ng context ang descriptions, kaya kailangang balansehin ang dami at granularity. Kapag masyadong malawak ang granularity, hindi alam ng model kung ilang bagay ang kayang gawin ng isang tool; kapag masyadong pino, mauubos muna ang context.
Maaga pa rin ang permissions at auditing. Maraming Server ang local at single-machine setup, nagsisimula nang may malaking privileges, at kulang sa fine-grained authorization at call records. Sa remote mode, kailangang sagutin muna kung sino ang maaaring kumonekta at kung ano ang maaari nilang makita.
Hindi rin nawawala ang page instability. Ang element na hindi mahanap, hindi matatag na loading sequence, expired na login state, at CAPTCHA ay nangangailangan pa rin ng waiting, retries, at fallback logic. Entry point lang ang pinapantay ng protocol.
Hindi rin pantay ang maturity ng ecosystem. Hindi lubos na pare-pareho ang supported resource types, return structures, at error codes ng iba’t ibang Server. Kapag pinagsama ang ilang Server sa isang task, madalas ay kailangang ikaw pa rin ang magsulat ng orchestration logic. Patuloy ding umuunlad ang protocol, kaya dapat bantayan ang behavior differences sa pagitan ng versions.
May isa pang hangganang kailangang malinaw: pinamamahalaan ng protocol kung paano tumatawag ng tool ang model, hindi kung compliant ang mismong task. Kung awtorisado ang data collection, lehitimo ang paggamit ng account, o lumalabag sa platform rules ay magkakahiwalay na pagsusuri at walang kinalaman sa kung maayos ang connection.
Sa multi-environment scenarios, mas malaki kadalasan ang epekto sa resulta ng isolation sa pagitan ng environments at ng magkakatugmang network egress, timezone, at language settings kaysa sa paraan ng integration. Sa environment-isolation layer, nagbibigay ang PurpleMark ng interfaces para sa environment creation, startup, at network configuration na maaaring tawagin ng AI tools at i-schedule mula sa iisang client.
Para lamang ito sa paliwanag ng teknikal na prinsipyo. Gamitin ang mga kaugnay na protocol at tool alinsunod sa mga naaangkop na batas at tuntunin.
