MCP un savienotie rīki

Savienojiet Nessie ar MCP serveriem un savienojiet pārī ārēju aģentu, lai tas varētu strādāt Nessie jūsu vārdā.

Kas ir MCP

Model Context Protocol ir neliela, atvērta konvencija, kas apraksta rīkus valodas modelim un ļauj tos izsaukt. Serveris paziņo, ko tas var — nosauktu rīku sarakstu, katram ar JSON shēmu tā argumentiem —, un klients šo sarakstu atklāj un izsauc rīkus modeļa vārdā. Tas ir apzināti vienkāršs: vērtība ir tajā, ka viena reiz uzrakstīta integrācija darbojas ar katru modeli un katru produktu, kas to runā.

Nessie atrodas abās pusēs

Par to jābūt precīziem, jo abas puses viegli sajaukt, un tās atrodas apzināti dažādos ceļos.

• Izejošais. Nessie ir MCP klients. Jūs pieslēdzat serverus, ko darbina kāds cits, un rīki, ko tie atklāj, kļūst par rīkiem, ko jūsu aģenti var izmantot. Pārvaldības virsma ir /api/mcp/*.
• Ienākošais. Nessie ir arī MCP serveris. Aģents, kas darbojas citur — Claude Code vai Codex izstrādātāja datorā —, var piekļūt jūsu dēļiem un dokumentiem. Šis galapunkts ir POST /mcp, apzināti ārpus /api, lai abas pretējās nozīmes nebūtu viena ceļa segmenta attālumā.

MCP servera pieslēgšana Nessie

Kataloga ieraksti un instances

Ir divi objekti, un atšķirība ir svarīga:

• Kataloga ieraksts ir servera definīcija — tā nosaukums, transports un autentifikācijas veids. To raksta vienreiz, un to var kopīgot.
• Instance ir šis ieraksts, uzstādīts vienā darbības apjomā, ar pieejas datiem, kas tam sasniedz. Vienu un to pašu ierakstu uzstādot divām dažādām komandām, rodas divas instances.

Lielākā daļa cilvēku ne ar vienu, ne ar otru tieši nestrādā. Ieeja administratorā ir lietotņu veikals /admin/apps: tas pārlūko to pašu katalogu ar paslēptām savienojuma detaļām, un Savienot uz ieraksta izveido instanci. Operatori, kas vēlas tiešos objektus, izmanto /api/mcp/catalog un /api/mcp/instances.

Ja serveris katalogā vēl nav, POST /api/mcp/discover pieņem URL un atgriež to, ko serveris par sevi paziņo, un POST /api/mcp/library/import ievelk ierakstu no publiskās serveru bibliotēkas. Pirmās pieslēgšanas savienojumu var izveidot tieši no URL ar POST /api/apps/custom.

Transporti

Nessie savienojas ar attālinātiem serveriem caur HTTP. Darbojas divi transporti: straumējamais HTTP (pašreizējais MCP transports) un vecākais HTTP+SSE transports. Izvēlieties http, ja serveris piedāvā tikai sse.

stdio transports ir noraidīts jūsu rakstītajiem savienotājiem. stdio nozīmē, ka MCP serveris ir lokāls process, ko palaiž saimnieks, un patvaļīgu programmu palaišana Nessie serverī nav kaut kas, ko operators varētu jēgpilni pārskatīt. Serveri, kas publicēti tikai kā pakotne lokālai palaišanai, tāda paša iemesla dēļ tiek izmesti no bibliotēkas importiem. Vērtība ws lauka protokolā eksistē, bet nav ieviesta — savienojums, kas to izmanto, neizdodas, kad Nessie mēģina to atvērt.

Kā Nessie autentificējas serverī

Kataloga ierakstā ir norādīts viens no pieciem veidiem: none, api_key, bearer, basic vai oauth2.

api_key ir galvenes ievietošana, un ierakstā ir norādīts, kura galvene un kāds prefikss — tātad Authorization: Bearer …, X-API-Key: … un X-Auth-Token: Token … ir viens un tas pats veids, tikai konfigurēts atšķirīgi. Pati atslēga tiek ievadīta vienreiz ar POST /api/mcp/instances/:instanceId/secret un nekad vairs nav nolasāma; neviena instances maršruta atbilde nenes pieejas datu atsauci.

oauth2 ir divas formas. Serverim ar fiksētiem galapunktiem tie ir kataloga ierakstā. Serveris, kas publicē standarta metadatus, nekas nav jākonfigurē: Nessie nolasa aizsargātā resursa un autorizācijas servera dokumentus un pati izveido klientu caur dinamisku klienta reģistrāciju vai caur klienta ID metadatu dokumentu, ko tā publicē savā well-known ceļā. Abos gadījumos rokasspiediens ir POST /api/mcp/instances/:instanceId/oauth/start, kam seko nodrošinātāja pāradresācija atpakaļ uz GET /api/mcp/oauth/callback. Stāvokļa marķieris ir vienreizējs, glabājas datubāzē un ir derīgs desmit minūtes, un PKCE vienmēr tiek izmantots.

Viens noteikums pārsteidz cilvēkus: pat organizācijas īpašnieks nevar piesaistīt personisku vai OAuth marķieri citai personai. Kopīgus pieejas datus var izmantot tikai API atslēgas ierakstam, kas ir apstiprināts kā tāds; visu citu noraida. Pieejas dati, kas pieder personai, paliek pieejas dati, kas pieder šai personai.

Kur glabājas pieejas dati

Savienotāju noslēpumi un OAuth marķieru kopas tiek glabāti jūsu pašu Postgres datubāzē, aploksnēs ar AES-256-GCM, kas saistītas ar konkrētu nolūku, zem izvietojuma neatkarīgi versionēta šifrēšanas atslēgu gredzena, un adresētas tikai ar necaurspīdīgām secret_* atsaucēm. Tie apzināti nav ārējā noslēpumu glabātuvē, kurā atrodas citi Nessie noslēpumi. Ražošanas izvietojums, kas nav konfigurējis šifrēto glabātuvi, atsakās startēt, nevis pabeigt OAuth rokasspiedienu, ko tad pazaudētu.

Kur sniedzas savienojums

Instance ir uzstādīta vienā no sešiem darbības apjomiem: system, organization, project, team, channel vai user. Šis apjoms ir stingrs griesti tam, kuri izpildījumi to var izmantot, un piešķīrumi to var tikai sašaurināt, nekad paplašināt — tātad savienotājs, ko uzstādījāt ar savu kontu, nevar klusi kļūt par visai organizācijai domātu.

Kas drīkst uzstādīt kur, seko tai pašai formai: organizācijas īpašnieki un administratori pārvalda uzstādījumus jebkurā apjomā; visi citi uzstāda savienotājus savā user apjomā un var redzēt kopīgos uzstādījumus, kuriem ir tiesības piekļūt.

Aģenta rīka piešķiršana

Servera pieslēgšana nevienam neatdod tā rīkus. Kad instance tiek uzstādīta, Nessie to pārbauda un projicē katru rīku, ko tā reklamē, rīku reģistrā — to, ko administrators rāda adresē /admin/advanced/tools — iebūvētie rīki, MCP rīki, paku rīki un executor rīki vienā sarakstā, katrs ar savu avotu un statusu.

Projicētajam rīkam ir viens no trim statusiem: active, pending_review vai disabled. Rīki no kopīgā apjoma uzstādījuma nonāk kā pending_review, un tie ir jāapstiprina šajā lapā, pirms aģents tos redz; rīki no jūsu paša user apjoma uzstādījuma ir uzreiz aktīvi, jo vienīgā persona, kas tiek pakļauta, esat jūs. Pārskatīšana ir atkārtota, nevis vienreizēja ceremonija: ja vēlāka pārbaude atklāj, ka rīka apraksts vai shēma ir novirzījusies, tas atgriežas pending_review un vairs netiek piedāvāts, kamēr kāds izmaiņas nepārbauda.

To, kuri aģenti pēc tam drīkst izsaukt aktīvu rīku, nosaka divos veidos:

• Savienojums, kas izveidots caur lietotņu veikalu, prasa skaidru piešķīrumu. Aģents saņem rīku tikai tad, kad piešķīrums to nosauc, un piešķīrums tiek pārbaudīts pret rīka pašreizējo pirkstu nospiedumu, tāpēc mainīts rīks prasa jaunu lēmumu.
• Citādi rīks pēc noklusējuma ir ieslēgts aģentiem, kas sasniedzami tā apjomā, un atsevišķi aģenti tiek izslēgti rīka detaļu panelī.

Piešķīrums nosauc tieši vienu principālu — lomu vai aģentu, nekad abus —, un aizliegums uzvar atļauju. Savienojumam user apjomā jautājums nerodas: jebkurš aģents, ar ko šī persona runā, to var izmantot, un vienīgā lieta, kas to aiztur, ir skaidrs izslēgšanas slēdzis.

Viena lieta, ko viegli meklēt nepareizā vietā: /settings/accounts administratorā ir pieslēgtie konti — Slack, pastkastes, modeļu abonementi un OAuth saites uz Linear, Jira, GitHub un Trello, kas balsta ārējos dēļus. MCP savienotāji atrodas /admin/apps, un to radītie rīki — /admin/advanced/tools.

Apstiprinājuma vārti rīku izsaukumiem

Daži rīku izsaukumi apstājas un gaida cilvēku. Kad tas notiek, izpildījums neizdodas: izsaukums tiek iesaldēts — rīka nosaukums, tā argumentu jaucējvērtība un pietiekami daudz stāvokļa, lai to atsāktu — un apstiprinājuma pieprasījums parādās /api/approvals, kur kāds to atbild. Atsākšana ir idempotenta, tāpēc dublēts apstiprinājums nevar izpildīt izsaukumu divreiz. Lēmējs redz ierobežotu kopsavilkumu par to, ko prasa; precīzie argumenti un izcelsmes izpildījums paliek servera pusē.

Ir divi atšķirīgi vārti, un tie ir konfigurēti atšķirīgi.

• Strukturālie vārti ir dažu iebūvētu rīku īpašība, un tie nav konfigurējami. Pasta sūtīšana no aģenta paša pastkastes vai no pieslēgtas pastkastes, Gmail melnraksta nosūtīšana, pasta konta atvienošana, kalendāra notikuma izveide, mainīšana vai atcelšana un pārlūka darbība, kas rakstītu vietnē, kurā pārlūks nav pieteicies, — visi ir vārtoti šādi. Tiem ir 24 stundu logs atbildei, nevis parastās 30 minūtes.
• Politikas vārti nāk no politikas noteikumiem pārī tool/invoke. Noteikums, kas atļauj izsaukumu, var nest requiresApproval, un bez pārbaudīta apstiprinājuma novērtējums atgriež APPROVAL_REQUIRED, nevis izpildās. Noteikumi tiek novērtēti vispirms ar liegumiem un kārtoti pēc apjoma.

Kurš administratora ekrāns raksta requiresApproval politikas noteikumu rīkam — datu modelis un izpilde abi ir vietā, bet mēs nevarējām apstiprināt ekrānu, kas šādu noteikumu raksta.

Ārēja aģenta pieslēgšana Nessie

Otrs virziens. Nessie darbina savu MCP serveri adresē POST /mcp, pa straumējamo HTTP, un tas ir bezstāvokļa: katrs izsaukums nes savus pieejas datus un pats atrisina savu aktoru, tāpēc nav sesijas, kuru piesaistīt klientu vienai replikai. ChatGPT, Claude, Claude Code, Codex vai aģents kāda klēpjdatorā var strādāt ar jūsu dēļiem, dokumentiem un klientiem no jebkura rīka, ko šī persona jau lieto. Soli pa solim katrai lietotnei ir Savienojiet ChatGPT, Claude un citas MI lietotnes.

Kas īsti ir sapārotie dati

Šī ir daļa, kas jāsaprot pareizi, jo acīmredzamais mentālais modelis — API atslēga ar piešķirtām tiesībām — ir nepareizs.

Sapārotie dati nekad nav identitāte. Tie nosauc cilvēku, un katrs rīka izsaukums darbojas kā šis cilvēks, pret tiem pašiem servisa funkcijām, ko izsauc HTTP maršruti. Aģents tāpēc nevar sasniegt neko, ko persona, kas to aizdeva, nevarētu sasniegt, noklikšķinot. Apjomi vienmēr tikai sašaurina šo sniedzamību; nav neviena apjoma, kas to paplašina.

Dzīvotspēja tiek pārlasīta katrā atsevišķā izsaukumā, nekad neuzticoties marķierim: atsaukums, derīguma termiņš, lietotāja marķiera versija, viņu organizācijas dalība un pašreizējā loma. Pazemināšana, deaktivizācija vai „izrakstīties visur” nonāk aģenta nākamajā izsaukumā, nevis tikai pie datu derīguma termiņa beigām.

Marķieris ir necaurspīdīgs, ar prefiksu nag1_, glabāts tikai kā SHA-256 jaucējvērtība, un dzīvo 90 dienas. Uz jebkura maršruta, izņemot MCP galapunktu, tas tiek noraidīts ar konkrētu 403 — to izmantot citur nav daļējs panākums, ko mēģināt vēlreiz, un tieši tas neļauj nozīmēt „es aizdevu aģentam savus dēļus” kā „es aizdevu tam savu kontu”.

Divi veidi, kā pieslēgties

Lietotne, kas var atvērt pārlūku — ChatGPT, Claude, Claude Code, Codex — izmanto MCP autorizācijas profilu: OAuth 2.1 ar PKCE (S256), dinamisku klienta reģistrāciju adresē POST /mcp/oauth/register, atjaunošanas marķierus un resursu indikatorus. Lietotne nosūta personu uz /settings/security, persona izvēlas, ko lietotne drīkst darīt un kurās no savām komandām tā sniedzas, un pārlūks ar kodu atgriežas lietotnē. Tās piekļuves marķieris ir derīgs stundu un tiek atjaunots; savienojums dzīvo 90 dienas.

Komandrindas aģents nekontrolē pārlūku un nevar saimniekot atzvanīšanas URL, tāpēc tā vietā tas sapārojas ar ierīces autorizācijas piešķiršanu (RFC 8628).

1. Aģents izsauc POST /mcp/auth/device ar clientName un vēlamajiem scopes. Tas saņem device_code, īsu user_code, verification_uri un verification_uri_complete ar kodu jau vaicājumā, kā arī aptaujas interval un expires_in. Tas izdrukā URI.
2. Persona atver šo URI, pieteikusies adresē /settings/security. Tā redz, kurš aģents jautā, kura konta vārdā tas darbotos, līdz kuram laikam un tieši ko tas varētu darīt — un izvēlas Atļaut vai Neatļaut.
3. Aģents aptauja POST /mcp/auth/token ar deviceCode, ievērojot authorization_pending, slow_down, expired_token un access_denied. Veiksmes gadījumā tas saņem { access_token, token_type, scope, expires_at }.

Abos gadījumos ir cilvēka solis, jo dati manto personas tiesības, tāpēc personai jāizvēlas tos aizdot. Šeit nekas netiek radīts no nekā. Savienošanu var arī izslēgt visai organizācijai adresē /admin/security?tab=programs, un šī atbilde tiek pārbaudīta, kad kāds atļauj savienojumu, nevis kad aģents to sāk.

Atklāšana

Neautentificēts POST /mcp atbild ar 401 un galveni WWW-Authenticate, kas norāda uz /.well-known/oauth-protected-resource (RFC 9728), kurā šī izcelsme nosaukta kā autorizācijas serveris; tā metadati adresē /.well-known/oauth-authorization-server (RFC 8414) nosauc reģistrācijas, autorizācijas, marķieru un atsaukšanas galapunktus. Šī ķēde ir viss, kas klientam vajadzīgs, kad tam ir adrese. Lai no domēna atrastu adresi, aģents lasa /.well-known/ai-catalog.json, kas nosauc Server Card adresē /mcp/server-card (MCP Server Cards, SEP-2127). Ierīces piešķiršanas galapunkti ir uzskaitīti aizsargātā resursa dokumentā zem x-nessie-device-authorization.

Izvietojums var atbildēt arī otrā, īsākā adresē: Nessie Cloud https://nessie.works/mcp tiek pārsūtīts uz API, un klients, kas ieradās šādi, saņem atpakaļ šo adresi kā resursu, bet pieteikšanās paliek API. Pāradresācija nebūtu derīga, jo klients noraida metadatus, kas nosauc citu adresi, nevis to, kuru tas saņēma. Operators šīs izcelsmes uzskaita NESSIE_MCP_ALIAS_ORIGINS.

Apjomi un rīki

Apjomi ir apzināti vispārīgi — apjoms, ko neviens nespēj izskaidrot, neviens nekonfigurē pareizi. Savienojums, kas sniedzas vairāk nekā vienā komandā, tās uzskaita ar nessie_team_list, un katrs cits rīks tad nosauc savu teamId.

Izsaukums bez nepieciešamā apjoma atgriežas kā rīka rezultāts, kas nosauc apjomu, kas jāprasa, nevis kā transporta kļūda, tāpēc modelis var ziņot par ko noderīgu, nevis atkārtot pret sienu.

Ārējiem izsekotājiem nav atsevišķas rīku saimes. Dēlis ir dēlis neatkarīgi no tā, vai tā uzdevumi radušies Nessie vai atspoguļoti no Linear, Jira, GitHub vai Trello, tāpēc viena rīku kopa aptver abus, un katrs uzdevums saka, no kurienes tas ir. Atšķiras rakstīšana: dēlis, kas atspoguļots no tikai lasāma avota, noraida rakstīšanu vārdos, paziņojot aģentam, ka uzdevumu pieder citai sistēmai un atkārtošana nepalīdzēs.

Dokumenta publicēšana ir apstiprinājums, nekad apjoms

Aģenti melnraksta; publicē persona. Šo noteikumu Nessie pašu aģentiem ievieš, atsakoties no aģenta aktora pilnīgi — bet sapārotie dati tiek atrisināti kā persona, tāpēc šis atteikums to nevar noķert. Vārtiem jāatrodas citur.

Tāpēc nessie_doc_publish nepublicē. Tas atver knowledge.page.publish apstiprinājumu — to pašu, ko atver Nessie aģents — un atgriež { status: "awaiting_approval", approvalId }. Aptaujājot atgriežas tas pats pieprasījums, nevis tiek atvērts otrs. Lēmumu pieņem tā, kā tiek pieņemti visi citi Nessie publicēšanas lēmumi: persona, par šo dokumentu, tajā brīdī, kad tas pastāv.

Apzināti nav publicēšanas apjoma. Tāds bija — atzīme sapārošanas brīdī, kas nosaka, ka šis aģents drīkst publicēt — un tas tika atcelts. Tas vienreiz un uz deviņdesmit dienām izlēma jautājumu, ko produkts visur citur uzdod par katru dokumentu, un izlēma to vēl pirms dokumenta pastāvēšanas, tāpēc persona, kas to atzīmēja, nevarēja zināt, ko tā piekrīt publicēt. nessie_doc_publish prasa documents_write, jo pieprasīt nav bez maksas — tas nolasa lappusi un nostāda lēmumu kādam priekšā —, bet šis apjoms nekam nepiešķir tiesības publicēt.

Pieprasījumā tiek ierakstītas divas identitātes, un atšķirība ir noteicoša. Pieprasītājs ir dati, nekad cilvēks, kura vārdā tie darbojas. Nepieciešamais apstiprinātājs ir šis cilvēks, un tikai viņš drīkst atbildēt. Ja pieprasījumā kā pieprasītājs būtu nosaukta persona, noteikums, kas aizliedz kādam apstiprināt savu pašu pieprasījumu, diskvalificētu vienīgo personu, kam ir tiesības lemt.

Redzēt un atsaukt, kas ir sapārots

Personas paša sapārotie aģenti ir uzskaitīti adresē /settings/security, ar nosaukumu un atsaukšanas vadību katram. Īpašnieks vai organizācijas administrators redz katru datu kopu organizācijā adresē /admin/security?tab=programs — kā katrs sauc, ko tas drīkst, vai tas ir aktīvs un kura konta vārdā tas darbojas — un var atsaukt jebkuru. Personīgais saraksts paliek tikai pašam lietotājam: aktīvo datu saraksts ir saraksts ar iespējamām ieejas vietām, nevis vispārīga informācija.

Rakstījumi, kas veikti ar datiem, tiek piedēvēti aizdevējam cilvēkam un nes datu id audita metadatos, tāpēc žurnāls var atšķirt personas paša izmaiņu no tās, ko aģents veica viņas vietā.

Kas vēl nav pieejams

Skaidri, jo starpība starp protokola iespējām un konkrēta servera iespējām ir tur, kur dokumentācija parasti melo:

• Tērzēšana, kanāli, izpildījumi un aģentu pārvaldība MCP netiek atklāti.
• Programma sagatavo jaunumu vēstuli, un persona to nosūta: nekas nenosūta, neieplāno vai nedzēš kampaņu, un pats e-pasts tiek rakstīts veidotājā.
• Kontaktu saistīšana un apvienošana, CRM shēmas izmaiņas, importi un kanālu iestatīšana paliek pie personas pārlūkā.
• Savienošanas slēdzis ir organizācijas līmeņa iestatījums. Komandas līmeņa un personiskos pārrakstījumus komanda vai persona pašlaik nevar iestatīt.