MCP za ERP: praktični vodnik

Začnite s transakcijo, ne s tabelo.

Prvi instinkt pri izpostavljanju ERP je ustvariti orodje za vsako tabelo z ustvarjanjem, branjem, posodabljanjem in brisanjem na vsaki. To ustvari veliko, enotno listo, ki jo model slabo obravnava, ker poslovno pravilo, da račun potrebuje davčno stopnjo na vsaki vrstici, ali da blago ne more biti odposlano, preden je rezervirano, ne obstaja nikjer, kjer bi ga model lahko videl. Namesto tega izpostavite dejanja. Koristen test je, ali bi lahko oseba opisala orodje kot nekaj, kar so storili danes: izdali račun, zabeležili plačilo, premaknili posel, odložili zasledovanje. Vsako od teh nosi svoja pravila, potrjuje svoje vnose in vrača berljiv rezultat.

Ob dejanjih dodajte majhno število povzetkovnih orodij, ki odgovarjajo na vprašanja, ki jih model postavi pred dejanjem. En klic, ki vrne profil računa, zdravje, odprte postavke in nedavno zgodovino, prihrani modelu štiri klice in več tisoč tokenov konteksta, kar naslednjemu dejanju omogoča bolj informirano odločitev. Sois ta orodja imenuje orodja za preizkušanje; preverjanje identitete in povzetek računovodstva sta dva. Ohranite tudi celotno površino v mislih: Claude Code privzeto omeji izhod strežnika na klic, oba, Claude in OpenAI, pa ponujata odloženo nalaganje ali iskanje orodij za velike sezname, zato bi moral strežnik s sto ali več orodji vrniti te v determinističnem vrstnem redu (specifikacija to zahteva, da lahko stranke shranijo v predpomnilnik) in bi moral filtrirati po vlogi pred seznamom.

Poimenujte orodja, da model izbere pravo.

Specifikacija rahlo omejuje imena: od 1 do 128 znakov, črke, številke, podčrtaj, pomišljaj in pika, občutljivo na velike in male črke, edinstveno znotraj strežnika. Vse ostalo je konvencija, pri čemer deluje konvencija, da je glagol v kombinaciji s poslovnim samostalnikom v dosledni obliki, pri čemer imajo isti glagoli povsod enak pomen. Model, ki izbira med iskanjeRačunov, pridobiRačun in ustvariRačun izbira med seznamom, enim zapisom in zapisom, in to vzorec spozna enkrat za celoten strežnik.

Opise bere model pod pritiskom, da deluje, zato jih napišite kot navodila. V prvi povedi navedite, kaj orodje počne, nato pogoje. Če je orodje sorodnik prava izbira za bližnjo zahtevo, to povejte po imenu. Če je treba polje nastaviti, da bo rezultat pravilen, to povejte z VELIKIMI ČRKAMI, če je potrebno; Soisovo orodje za račune pove modelu, da mora biti davčna stopnja nastavljena na vsaki vrstici in da natančne stopnje prihajajo iz seznam vrst davkov, ker je račun brez DDV hujša napaka kot zavrnjeni klic. Vključite en primer klica. Vse, kar model potrebuje za pravilno klicanje orodja, mora biti v orodju, ker nikoli ne bo odprl vaše dokumentacije.

Definicija orodja kot primer.

To je Soisovo orodje za račune, kot ga stranka prejme od tools/list, obrezano na polja, ki so pomembna, z opombami in izhodno shemo, dodano v obliki, ki jo trenutno definira specifikacija. Prikazuje vzorec: ime glagol-samostalnik, navodila za opis, shemo, katere opisi lastnosti preprečujejo napake modela, in namige, ki jih lahko stranka uporabi za odločitev, ali potrditi.

{
  "name": "createInvoice",
  "title": "Create invoice",
  "description": "Create a new invoice of any type and return the draft with its auto-generated number. TAX: set tax_rate on each line (for example 20 for 20% VAT); call listTaxTypes for this workspace's exact rates. If the user says 'plus VAT' you MUST set tax_rate or the invoice goes out with no VAT. To email the result use sendInvoice. Example: createInvoice({ type: \"sales_invoice\", contact_id: \"uuid\", currency: \"GBP\", lines: [{ description: \"Consulting\", quantity: 10, unit_price: 150 }] })",
  "inputSchema": {
    "type": "object",
    "properties": {
      "type": { "type": "string", "description": "sales_invoice, purchase_invoice, sales_credit_note or purchase_credit_note" },
      "contact_id": { "type": "string", "description": "Contact UUID (bill-to for sales, bill-from for purchases)" },
      "currency": { "type": "string", "description": "ISO code, for example GBP. Uses the workspace default if omitted" },
      "invoice_date": { "type": "string", "description": "ISO date. Defaults to today" },
      "reference": { "type": "string" },
      "lines": {
        "type": "array",
        "description": "Line items. Every line MUST carry the numeric unit_price the user asked for",
        "items": {
          "type": "object",
          "properties": {
            "description": { "type": "string" },
            "quantity": { "type": "number", "description": "Defaults to 1" },
            "unit_price": { "type": "number", "description": "NUMBER only: no currency symbols, no thousands separators. Use the exact amount stated; never guess or round" },
            "tax_rate": { "type": "number" },
            "discount_percent": { "type": "number" }
          },
          "required": ["description", "unit_price"]
        }
      }
    },
    "required": ["type"]
  },
  "outputSchema": {
    "type": "object",
    "properties": {
      "invoice_id": { "type": "string" },
      "number": { "type": "string" },
      "status": { "type": "string" },
      "total": { "type": "number" }
    },
    "required": ["invoice_id", "number", "status"]
  },
  "annotations": {
    "readOnlyHint": false,
    "destructiveHint": false,
    "idempotentHint": false,
    "openWorldHint": false
  }
}

Opombe pravijo: to zapisuje, le dodaja (osnutek), klicanje dvakrat ustvari dva osnutka in ne vpliva na nič zunaj sistema. Stranke morajo obravnavati opombe kot nezanesljive, razen če je strežnik zaupanja vreden, zato so namigi za potrditev obnašanja, ne pa nadomestilo za lastne preglede strežnika.

Tri izbire v tej definiciji so namerne. Rezultat vrne identifikator, ki ga mora model nositi v pošlji račun in zabeležiPlačilo, kar je priporočeni način specifikacije za povezovanje klicev, zdaj ko strežniki ne hranijo stanja seje. Orodje ustvari osnutek, ne objavljenega računa, zato je zapis dodaten in ga dokonča oseba ali ločeno orodje za odobritev. Izhodna shema pomeni, da lahko integracija prebere številko in skupni znesek kot podatke, medtem ko model bere isti rezultat kot besedilo.

Omejite orodja na uporabnika.

Preko HTTP klicatelj pride z OAuth dostopno kodo, vezano na vaš strežnik, in ta koda identificira osebo. Specifikacija omogoča rezultat tools/list se razlikuje glede na poverilnice v zahtevi, zato je prva odločitev o obsegu filtrirati seznam glede na vlogo te osebe, preden ga vrnemo: uporabnik skladišča ne prejme odobritev računaSeznam se ne sme spreminjati glede na povezavo ali kot stranski učinek drugih klicev, temveč le na podlagi avtorizacije, kar ga naredi shranljivega.

Druga odločitev je, da se ponovno preveri ob izvedbi. Stranka lahko pošlje klic, ki ga želi, in model lahko manipuliramo s tekstom v rezultatu orodja, da ga poskusimo. Ugotovite uporabnika iz žetona ob vsakem klicu, preverite dovoljenje, ki ga orodje zahteva, in zavrnite z napako pri izvajanju orodja, ki jo model lahko prebere. Ohranite OAuth obsege grobe (Sois izdaja obsege za branje, pisanje in brez povezave) in pustite, da so lastne vloge ERP-ja fina meja, ker te vloge že obstajajo, se že vzdržujejo in že pomenijo nekaj za podjetje. Vsak klic pripišite osebi v dnevniku z njenimi argumenti in rezultatom, tako da je delo agenta pregledno natanko tako, kot je delo osebe.

1. Žeton je prispelPotrdite podpis in da je občinstvo ta strežnik, kot zahteva RFC 8707; zavrnite vse drugo s 401.
2. Rešite oseboPovežite žeton z uporabnikom v delovnem prostoru in naložite njihovo vlogo ter nameščene aplikacije.
3. Filtrirajte seznamVrni samo orodja, ki jih ta vloga lahko uporablja, v stabilnem vrstnem redu, iz orodja/seznama.
4. Preverite klicNa orodja/klic ponovno preverite dovoljenje in zavrnite z isError, če manjka; nič se ne izvede.
5. Izvedite in zabeležiteIzvedite transakcijo, jo izmerite, če je vaš agent opravil razmišljanje, in zabeležite klic v revizijski dnevnik pod to osebo.

Obravnavanje zapisov.

Model, ki prejme nejasen rezultat, bo ponovno poklical, model, ki prejme napako, pa bo poskusil s popravljenim vhodom. Oblikujte tako. Zapisi, ki ustvarjajo, naj vrnejo ročico in, kjer je to mogoče, sprejmejo ključno vrednost idempotence ali naravni ključ, da se zazna ponovitev. Zapisi, ki spreminjajo stanje, naj bodo jasni glede prehoda, ki ga izvajajo, in zavrnejo nemogoče s razumljivim razlogom: evidentiranje plačila proti razveljavljenemu računu je isError rezultat, ki to pove, ne tiho neizvedeno in ne sledi napakam. Nikoli ne pustite delnega zapisa; če večstopenjski pripomoček ne more dokončati, se vrnite in poročajte.

• Raje osnutke in odobritve. Ustvarjanje naj bo aditivno (osnutek) in dajte dokončanju svoje orodje s svojim dovoljenjem, tako da je uničujoč korak tisti, ki ga potrdi stranka in ga nadzira vloga.
• Označite uničujoča orodja. Nastavi destructiveHint o preklicih in brisanjih in to navedite v opisu; Claude in ChatGPT uporabljata takšne signale, ko se odločata, ali naj vprašata pred klicem.
• Vprašajte namesto da ugibate. Ko klic potrebuje odločitev, ki je orodje ne more sprejeti, vrnite rezultat, ki zahteva vnos, z zahtevo po pojasnilu; stranka postavi vprašanje osebi in ponovno izvede klic z odgovorom.
• Omejite območje vpliva. Omejite hitrost na povezavo, omejite porabo na integracijo, kjer vaš agent izvaja razmišljanje, in preverite vsak vnos na strežniški strani ne glede na shemo, ker je shema nasvet modelu, ne pa izvrševanje.

Testiranje površine z resničnim klientom.

Inšpektor MCP bo izvajal tools/list in tools/call in prehodil OAuth postopek. Pravi test je model. Povežite Claude kot prilagojen povezovalnik ali ChatGPT v načinu razvijalca, prijavite se kot uporabnik z ozko vlogo in zahtevajte en rutinski izid, ki potrebuje tri ali štiri orodja. Opazujte, katera orodja izbere in zakaj; napačna izbira je skoraj vedno težava z opisom. Nato se prijavite kot uporabnik brez ene od dovoljenj in potrdite, da se izvajanje ustavi pri pravem klicu z razlogom, ki ga model ponovi nazaj.

Tako je zgrajen in preverjen strežnik delovnega prostora Sois: transakcije kot orodja, navodila, seznam filtriran po vlogah, druga preverjanja pri vsakem klicu, osnutki pred odobritvami in dnevnik, ki ga lahko oseba prebere. Razvijalci, ki gradijo aplikacije za trg, objavljajo orodja v istem seznamu pod istimi pravili, tako da je aplikacija operativna za katerega koli agenta, takoj ko je nameščena. Ta vzorec ni specifičen za en izdelek; vsak ERP, ki ga sprejme, postane nekaj, kar lahko agent izvaja.

Vprašanja, ki jih ljudje postavljajo

Ta članek se pregleda, ko se izdelki, ki jih opisuje, spremenijo. Naslednji načrtovani pregled: 4. december 2026.