MCP og tengd verkfæri

Tengdu Nessie við MCP-þjóna og paraðu utanaðkomandi fulltrúa svo hann geti unnið í Nessie fyrir þína hönd.

Hvað er MCP

Model Context Protocol er lítil, opin samkomulagsregla til að lýsa verkfærum fyrir tungumálalíkan og kalla á þau. Þjónn lýsir því sem hann getur gert — lista af nefndum verkfærum, hvert með JSON-skema fyrir röksemdir sínar — og biðlari uppgötvar listann og kallar á verkfærin fyrir hönd líkansins. Hún er vísvitandi látlaus: gildið er að ein samþætting, skrifuð einu sinni, virkar með sérhverju líkani og sérhverri vöru sem talar hana.

Nessie stendur báðum megin við hana

Vert er að vera nákvæmur um það, því helmingana tvo er auðvelt að rugla saman og þeir liggja á vísvitandi ólíkum slóðum.

• Útleið. Nessie er MCP-biðlari. Þú tengir þjóna sem einhver annar rekur, og verkfærin sem þeir bjóða verða verkfæri sem fulltrúarnir þínir geta notað. Stjórnunarviðmótið er /api/mcp/*.
• Innleið. Nessie er líka MCP-þjónn. Fulltrúi sem keyrir annars staðar — Claude Code eða Codex á tölvu þróunaraðila — getur kallað inn í töflurnar og skjölin þín. Sá endapunktur er POST /mcp, utan /api viljandi, svo tvær andstæðar merkingar lendi ekki á einum og sama slóðarhlutanum.

Að tengja MCP-þjón við Nessie

Vörulistafærslur og uppsetningar

Hér eru tveir hlutir, og greinarmunurinn skiptir máli:

• Vörulistafærsla er skilgreining þjónsins — nafn hans, flutningsleið og hvernig hann auðkennir sig. Hún er skrifuð einu sinni og má deila henni.
• Uppsetning er sú færsla sett upp á einu gildissviði, með þeim auðkenningum sem ná til hans. Að setja sömu færslu upp fyrir tvö mismunandi teymi býr til tvær uppsetningar.

Flestir snerta hvorugt beint. Inngangurinn í stjórnborðinu er forritaverslunin á /admin/apps: hún flettir sama vörulista með tengiupplýsingarnar faldar, og Tengja á skráningu býr til uppsetningu. Rekstraraðilar sem vilja hrá hlutina nota /api/mcp/catalog og /api/mcp/instances.

Ef þjónn er ekki í vörulistanum enn, tekur POST /api/mcp/discover slóð og les til baka það sem þjónninn segir um sjálfan sig, og POST /api/mcp/library/import sækir færslu úr opna þjónasafninu. Tenging sem er búin til í fyrsta skipti má líka búa til beint úr slóð með POST /api/apps/custom.

Flutningsleiðir

Nessie tengist fjarþjónum yfir HTTP. Tvær leiðir virka: streamable HTTP (núverandi MCP-flutningur) og eldri HTTP+SSE-flutningurinn. Veldu http nema þjónninn bjóði aðeins sse.

Flutningsleiðin stdio er hafnað fyrir tengla sem þú skrifar sjálfur. stdio þýðir að MCP-þjónninn er staðbundið ferli sem gestgjafinn ræsir, og að keyra handahófskenndar forrit innan Nessie-þjónsins er ekki eitthvað sem rekstraraðili getur marktækt yfirfarið. Þjónar sem eru aðeins birtir sem pakki til að keyra staðbundið eru felldir úr innflutningi úr safninu af sömu ástæðu. Gildið ws er til í samskiptareglunni en er ekki útfært — tenging sem notar það mistekst þegar Nessie reynir að opna hana.

Hvernig Nessie auðkennir sig gagnvart þjóninum

Vörulistafærsla lýsir einni af fimm aðferðum: none, api_key, bearer, basic eða oauth2.

api_key er innspýting á haus, og færslan segir hvaða haus og hvaða forskeyti — þannig eru Authorization: Bearer …, X-API-Key: … og X-Auth-Token: Token … allar sama aðferðin stillt á mismunandi hátt. Lykillinn sjálfur er settur inn einu sinni með POST /api/mcp/instances/:instanceId/secret og er aldrei hægt að lesa aftur; ekkert svar frá uppsetningarleiðunum inniheldur tilvísun í auðkenni.

oauth2 kemur í tveimur gerðum. Þjónn með föst endapunkta hefur þá í vörulistafærslunni. Þjónn sem birtir staðlaðar lýsigögn þarf ekkert stillt: Nessie les skjölin fyrir verndaða auðlind og auðkenningarþjónustuna og útbýr sér biðlara með kvikri skráningu biðlara, eða með biðlaraauðkennis-lýsigagnaskjalinu sem hann birtir á eigin vel þekktu slóð. Hvort sem er felst í handabandinu POST /api/mcp/instances/:instanceId/oauth/start og síðan endurbeiningu veitandans til baka á GET /api/mcp/oauth/callback. Stöðutáknið er notað einu sinni, geymt í gagnagrunninum og gildir í tíu mínútur, og PKCE er alltaf notað.

Ein regla kemur fólki á óvart: jafnvel eigandi stofnunar getur ekki fest persónulegt eða OAuth-tóken á annan mann. Sameiginleg auðkenning er aðeins möguleg fyrir API-lykilfærslu sem hefur verið staðfest sem slík; allt annað er hafnað. Auðkenning sem tilheyrir manneskju er áfram auðkenning sem tilheyrir þeirri manneskju.

Hvar auðkenningarnar eru geymdar

Leyndarmál tengla og OAuth-tóken-pakkar eru geymd í þínum eigin Postgres-gagnagrunni, í AES-256-GCM umslögum bundnum við tilgang undir sjálfstætt útgefinni dulritunarlyklakippu uppsetningarinnar, og eru aðeins vistuð undir ógagnsæjum secret_*-tilvísunum. Þau eru viljandi ekki í ytri leyndarmálahvelfingunni sem geymir önnur Nessie-leyndarmál. Framleiðsluuppsetning sem hefur ekki stillt dulritaða geymsluna neitar að ræsast, í stað þess að ljúka OAuth-handabandi sem hún myndi síðan tapa.

Hvert tenging nær

Uppsetning er sett á eitt af sex gildissviðum: system, organization, project, team, channel eða user. Gildissviðið er harð þak á hvaða keyrslur geta notað hana, og veitingar geta aðeins þrengt það enn frekar, aldrei víkkað — svo tengill sem þú settir upp með þínum eigin aðgangi getur ekki orðið að aðgangi allrar stofnunarinnar í laumi.

Hver má setja upp hvar fylgir sama formi: eigendur og stjórnendur stofnunarinnar stýra uppsetningum á öllum gildissviðum; allir aðrir setja upp tengla á eigin user-gildissviði og geta séð sameiginlegar uppsetningar sem þeir eiga rétt á að ná til.

Að gefa fulltrúa verkfæri

Að tengja þjón afhendir verkfærin hans engum. Þegar uppsetning er gerð prófar Nessie hana og varpar hverju verkfæri sem hún auglýsir inn í verkfærisskrána, sem stjórnborðið sýnir á /admin/advanced/tools — innbyggð verkfæri, MCP-verkfæri, pakkaverkfæri og executor-verkfæri í einum lista, hvert með uppruna sínum og stöðu.

Varpað verkfæri hefur eina af þremur stöðum: active, pending_review eða disabled. Verkfæri úr sameiginlegri uppsetningu koma sem pending_review og þarf að samþykkja á þeirri síðu áður en fulltrúi sér þau, en verkfæri úr þinni eigin user-uppsetningu eru virk strax, því eina manneskjan sem verður fyrir áhrifum ert þú. Yfirferð er endurtekin, ekki einskiptis athöfn: ef síðari prófun kemst að því að lýsing verkfæris eða skema hefur breyst, fer það aftur í pending_review og er ekki boðið fram fyrr en einhver hefur litið á breytinguna.

Hvaða fulltrúar mega síðan kalla á virkt verkfæri er ákveðið á tvo vegu:

• Tenging sem er búin til í gegnum forritaverslunina krefst skýrrar heimildar. Fulltrúi fær verkfærið aðeins þegar heimild nefnir það, og heimildin er borin saman við núverandi fingrafar verkfærisins, svo breytt verkfæri þarf nýja ákvörðun.
• Annars er verkfærið sjálfgefið virkt fyrir fulltrúa sem ná til gildissviðs þess, og einstökum fulltrúum er slökkt á því á smáatriðaspjaldi verkfærisins.

Heimild nefnir nákvæmlega einn aðila — hlutverk eða fulltrúa, aldrei bæði — og bann vinnur leyfi. Fyrir user-gildissviðs tengingu kemur spurningin ekki upp: sérhver fulltrúi sem sú manneskja talar við getur notað hana, og skýr slökkvun er eina sem heldur henni frá.

Eitt sem auðvelt er að leita að á röngum stað: /settings/accounts í stjórnborðinu eru tengdir reikningar — Slack, póstbox, gervigreindaráskriftir og OAuth-tengingar við Linear, Jira, GitHub og Trello sem liggja að baki ytri töflum. MCP-tenglar eru á /admin/apps, og verkfærin sem þeir búa til eru á /admin/advanced/tools.

Samþykkishlið á verkfærakköllum

Sum verkfærakköll stöðvast og bíða eftir manneskju. Þegar það gerist mistekst keyrslan ekki: kallið er fryst — heiti verkfærisins, hass af röksemdum þess og nóg ástand til að halda áfram — og samþykkisbeiðni birtist á /api/approvals til að einhver svari. Sá sem tekur ákvörðunina sér afmarkaða samantekt af því sem er beðið um; nákvæmu röksemdirnar og keyrslan sem kallið kemur frá eru áfram á þjóninum. Að halda áfram er óhætt að endurtaka, svo tvítekið samþykki getur ekki keyrt kallið tvisvar.

Það eru tvö ólík hlið, og þau eru stillt á mismunandi hátt.

• Byggingarhlið eru eiginleiki ákveðinna innbyggðra verkfæra og eru ekki stillanleg. Að senda póst úr póstboxi fulltrúa eða úr tengdu boxi, senda Gmail-drög, aftengja póstreikning, búa til, breyta eða hætta við dagatalsviðburð, og vafraaðgerð sem myndi skrifa á vef sem vafrinn er ekki innskráður á, eru öll hliðuð á þennan hátt. Þau hafa 24 klukkustundir til svars, í stað venjulegra 30 mínútna.
• Stefnuhlið koma úr stefnureglum á tool/invoke-parinu. Regla sem leyfir kall getur borið requiresApproval, og án staðfests samþykkis skilar matið APPROVAL_REQUIRED í stað þess að keyra. Reglur eru metnar fyrst með banni og raðað eftir gildissviði.

Hvaða skjár stjórnborðsins býr til requiresApproval-stefnureglu fyrir verkfæri — gagnalíkanið og framfylgdin eru bæði til staðar, en við gátum ekki staðfest hvaða skjár skrifar slíka reglu.

Að tengja utanaðkomandi fulltrúa við Nessie

Hin áttin. Nessie keyrir eigin MCP-þjón á POST /mcp, yfir streamable HTTP, og hann er án ríkis: sérhvert kall ber sína eigin auðkenningu og leysir sinn eigin geranda, svo það er engin tengiseta til að festa biðlara við eina afritun. ChatGPT, Claude, Claude Code, Codex eða fulltrúi á fartölvu einhvers getur unnið með töflurnar þínar, skjöl og viðskiptavini innan hvaða verkfæris sú manneskja notar nú þegar. Skref fyrir skref fyrir hvert forrit er í Tengdu ChatGPT, Claude og önnur gervigreindarforrit.

Hvað pöruð auðkenning er í raun

Þetta er hlutinn sem þarf að skilja rétt, því augljósa hugsunarlíkanið — API-lykill með heimildum festum við — er rangt.

Pöruð auðkenning er aldrei auðkenni. Hún nefnir manneskju, og sérhvert verkfærakall keyrir sem sú manneskja, gegn sömu þjónustufallum og HTTP-leiðirnar kalla á. Fulltrúi getur því ekki náð í neitt sem sú manneskja sem lánaði hann gæti ekki náð í með því að smella. Gildissvið þrengja aðeins þá ná; ekkert gildissvið víkkar hana.

Lífsmark er lesið við sérhvert einstakt kall, aldrei treyst úr tókeninu: afturköllun, gildistími, tókenútgáfa notandans, aðild að stofnuninni og núverandi hlutverk. Lækkun í tign, óvirkjun eða „skráðu mig út alls staðar“ lendir við næsta kall fulltrúans frekar en við gildistíma auðkenningarinnar.

Tókenið er ógagnsætt, merkt nag1_, geymt aðeins sem SHA-256-hass, og lifir í 90 daga. Því er hafnað með sérstakri 403-villu á hvaða leið sem er önnur en MCP-endapunkturinn — að bera það annars staðar er ekki að hluta til árangur sem á að reyna aftur, og það er það sem kemur í veg fyrir að „ég lánaði fulltrúa töflurnar mínar“ þýði „ég lánaði honum reikninginn minn“.

Tvær leiðir til að tengjast

Forrit sem getur opnað vafra — ChatGPT, Claude, Claude Code, Codex — notar MCP-auðkenningarsniðið: OAuth 2.1 með PKCE (S256), kvikri skráningu biðlara á POST /mcp/oauth/register, endurnýjunartókenum og auðlindavísum. Forritið sendir manneskjuna á /settings/security, hún velur hvað það má gera og hvaða teymi af hennar eigin teymum það nær til, og vafrinn snýr aftur til forritsins með kóða. Aðgangstóken þess gildir í klukkustund og er endurnýjað; tengingin lifir í 90 daga.

Skipanalínufulltrúi stjórnar engum vafra og getur ekki hýst endurkallsslóð, svo hann parar í staðinn með tækjaheimildaveitingunni (RFC 8628).

1. Fulltrúinn kallar á POST /mcp/auth/device með clientName og scopes sem hann vill. Hann fær til baka device_code, stutt user_code, verification_uri og verification_uri_complete með kóðann þegar í fyrirspurninni, auk biðtímans interval og expires_in. Hann prentar slóðina.
2. Manneskja opnar þá slóð þegar hún er innskráð, á /settings/security. Hún sér hvaða fulltrúi er að biðja, hvers reikningi hann myndi þjóna, til hvenær, og nákvæmlega hvað hann gæti gert — og velur Leyfa eða Ekki leyfa.
3. Fulltrúinn spyr POST /mcp/auth/token með deviceCode reglulega, virðir authorization_pending, slow_down, expired_token og access_denied. Við árangur fær hann { access_token, token_type, scope, expires_at }.

Hvort sem er krefst þetta skrefs manneskju, því auðkenningin erfir réttindi manneskju, svo manneskja þarf að velja að lána þau. Ekkert hér útbýr aðgang úr engu. Hægt er að slökkva á tengingum fyrir heila stofnun á /admin/security?tab=programs, og það svar er athugað þegar einhver leyfir tengingu, ekki þegar fulltrúi byrjar eina.

Uppgötvun

Óauðkennt POST /mcp svarar 401 með WWW-Authenticate-haus sem bendir á /.well-known/oauth-protected-resource (RFC 9728), sem nefnir þennan uppruna sem auðkenningarþjóninn; lýsigögn hans á /.well-known/oauth-authorization-server (RFC 8414) nefna skráningar-, heimildar-, tóken- og afturköllunarendapunktana. Sú keðja er allt sem biðlari þarf þegar hann hefur vistfangið. Til að finna vistfangið út frá léni les fulltrúi /.well-known/ai-catalog.json, sem nefnir Server Card á /mcp/server-card (MCP Server Cards, SEP-2127). Endapunktar tækjaheimildarinnar eru skráðir í lýsigögnum verndaðrar auðlindar undir x-nessie-device-authorization.

Uppsetning getur líka svarað á öðru, styttra vistfangi: https://nessie.works/mcp í Nessie Cloud er framsent á API-ið, og biðlari sem kom þannig inn fær það vistfang til baka sem auðlind, á meðan innskráning er áfram á API-inu. Endurbeining myndi ekki duga, því biðlari hafnar lýsigögnum sem nefna annað vistfang en það sem hann fékk. Rekstraraðilinn skráir þessa uppruna í NESSIE_MCP_ALIAS_ORIGINS.

Gildissvið og verkfæri

Gildissviðin eru gróf af ásettu ráði — gildissvið sem enginn getur útskýrt er gildissvið sem enginn stillir rétt. Tenging sem nær til fleiri en eins teymis listar þau með nessie_team_list, og hvert annað verkfæri nefnir þá teamId.

Kall án gildissviðsins sem það þarfnast kemur til baka sem niðurstaða verkfæris sem nefnir gildissviðið sem þarf að biðja um, ekki sem flutningsvilla, svo líkanið geti sagt eitthvað gagnlegt í stað þess að reyna aftur inn í vegg.

Það er engin sérstök verkfærafjölskylda fyrir ytri rakningarkerfi. Tafla er tafla hvort sem verkefnin eiga uppruna sinn í Nessie eða eru speglaðar úr Linear, Jira, GitHub eða Trello, svo eitt verkfærasett nær yfir bæði, og hvert verkefni segir hvort er. Það sem er ólíkt er skrifun: tafla sem speglast úr uppsprettu sem er aðeins lesin hafnar skrifun með orðum, og segir fulltrúanum að hitt kerfið eigi miðann og að það hjálpi ekki að reyna aftur.

Birting skjals er samþykki, aldrei heimild

Fulltrúar semja drög; manneskja birtir. Þessu er framfylgt fyrir innbyggða fulltrúa Nessie með því að hafna fulltrúageranda alveg — en pöruð auðkenning leysist sem manneskja, svo sú höfnun getur ekki gripið hana. Hliðið verður að vera annars staðar.

Svo nessie_doc_publish birtir ekki. Það opnar knowledge.page.publish-samþykki — sama og innbyggður Nessie-fulltrúi opnar — og skilar { status: "awaiting_approval", approvalId }. Fyrirspurn skilar sömu beiðni í stað þess að opna aðra. Ákvörðunin er tekin á sama hátt og allar aðrar birtingarákvarðanir í Nessie eru teknar: af manneskju, um það skjal, á því augnabliki sem það verður til.

Það er vísvitandi engin birtingarheimild. Hún var til — hak við pörun sem sagði að þessi fulltrúi mætti birta — og henni var hætt. Hakið svaraði í níutíu daga spurningu sem varan spyr alls staðar annars staðar um hvert skjal, og það var svarað áður en skjalið var til, svo sú sem setti hakið gat ekki vitað hvað hún var að samþykkja. nessie_doc_publish þarf documents_write, því að biðja er ekki ókeypis — það les síðuna og setur ákvörðun fyrir framan einhvern — en það gildissvið veitir ekkert varðandi birtingu.

Tvö auðkenni eru skráð á beiðnina, og greinarmunurinn ber þunga. Beiðandinn er auðkenningin, aldrei manneskjan sem hún kemur fram fyrir. Nauðsynlegi samþykkjandinn er sú manneskja, og aðeins hún má svara. Ef beiðnin nefndi manneskjuna sem beiðanda, myndi reglan sem kemur í veg fyrir að einhver samþykki eigin beiðni útiloka þá einu manneskju sem hefur rétt til að ákveða.

Að sjá og afturkalla það sem er parað

Pöruðu fulltrúar manneskju eru skráðir á /settings/security, með heiti og afturköllunarstjórn fyrir hvern. Eigandi eða stjórnandi stofnunar sér sérhverja auðkenningu stofnunarinnar á /admin/security?tab=programs — hvað hver heitir, hvað hún má gera, hvort hún er virk og hvers reikning hún fær lánaðan — og getur afturkallað hvaða sem er. Persónulegi listinn er aðeins fyrir eigandann: listi yfir virkar auðkenningar er listi yfir fótfestur, ekki almennur lestur.

Skrifanir sem gerðar eru með auðkenningu eru raktar til manneskjunnar sem lánaði hana og bera auðkenni auðkenningarinnar í lýsigögnum endurskoðunarskrárinnar, svo skráin geti greint breytingu manneskju frá breytingu sem fulltrúinn gerði fyrir hana.

Það sem er ekki til enn

Við erum skýr um þetta, því bilið milli getu samskiptareglu og getu tiltekins þjóns er þar sem skjöl skarast venjulega:

• Spjall, rásir, keyrslur og stjórnun fulltrúa eru ekki birt yfir MCP.
• Forrit undirbýr fréttabréf og manneskja sendir það: ekkert sendir, skipuleggur eða eyðir herferð, og tölvupósturinn sjálfur er skrifaður í hönnunartólinu.
• Að tengja saman og sameina tengiliði, breytingar á CRM-skema, innflutningar og uppsetning rása eru áfram hjá manneskju í vafranum.
• Tengirofinn er stofnunarstilling. Stillingar á teymisstigi og persónulegar undantekningar eru ekki eitthvað sem teymi eða manneskja getur stillt eins og er.