MCP ERP jaoks: praktiline juhend

Alustage tehingust, mitte tabelist.

Esimene instinkt ERP-d avades on genereerida iga tabeli jaoks tööriist, kus on loomine, lugemine, uuendamine ja kustutamine. See toodab suure, ühtse loendi, mida mudel haldab halvasti, kuna ärireegel, et arvel peab olema iga rea peal maksumäär, või et kaupa ei saa saata enne, kui see on reserveeritud, ei asu kusagil, kus mudel seda näha saaks. Näita selle asemel tegevusi. Kasulik test on, kas inimene saaks tööriista kirjeldada kui midagi, mida nad täna tegid: arve tõstmine, makse registreerimine, tehingu liigutamine, jälitamise edasi lükkamine. Igaühel neist on oma reeglid, valideerib oma sisendid ja tagastab loetava tulemuse.

Tegevuste kõrval lisa väike arv kokkuvõtte tööriistu, mis vastavad küsimustele, mida mudel küsib enne tegutsemist. Üks kõne, mis tagastab konto profiili, tervise, avatud punktid ja hiljutise ajaloo, säästab mudelilt neli kõnet ja mitu tuhat konteksti tokenit ning muudab järgmise tegevuse paremini informeerituks. Sois nimetab neid eksamineerimise tööriistadeks; uurigeKontakti ja saada raamatupidamise kokkuvõte on kaks. Hoia kogu pinda silmas: Claude Code piirab serveri väljundit iga kõne puhul vaikimisi, ning nii Claude kui ka OpenAI pakuvad suurtel nimekirjadel edasilükatud laadimist või tööriistade otsingut, seega peaks server, millel on mitu sada tööriista, tagastama need kindlas järjekorras (spetsifikatsioon nõuab seda, et kliendid saaksid vahemälu kasutada) ja peaks enne loetlemist filtreerima rolli järgi.

Nime tööriistad, et mudel valiks õige.

Spetsifikatsioon piirab nimesid kergelt: kuni 128 tähemärki, tähed, numbrid, alakriips, sidekriips ja punkt, suurustundlik, serveris ainulaadne. Kõik muu on konventsioon, ja toimiv konventsioon on tegusõna, millele järgneb äri nimetus ühtses vormis, kus samad tegusõnad tähendavad igal pool sama. otsige arveid, saada arve ja looArve valib nimekirja, ühe kirje ja kirjutamise vahel ning õpib seda mustrit kord ühe serveri jaoks.

Kirjeldusi loeb mudel, mis on sunnitud tegutsema, seega kirjutage need juhistena. Esimese lause sees öelge, mida tööriist teeb, seejärel tingimused. Kui õige valik lähedase päringu jaoks on õdede tööriist, öelge seda nimega. Kui väli peab olema seadistatud, et tulemus oleks õige, öelge seda SUURTE TÄHTEDEGA, kui peate; Sois'i arve tööriist ütleb mudelile, et maksumäär peab olema seadistatud igal real ja et täpsed määrad tulevad. listTaxTypes, sest arve ilma käibemaksuta on hullem ebaõnnestumine kui keeldunud kõne. Lisage üks näide kõnest. Kõik, mida mudel vajab tööriista õigeks kutsumiseks, peaks olema tööriistas, sest see ei ava kunagi teie dokumentatsiooni.

Näide tööriista määratlemisest.

See on Sois'i arve tööriist, nagu klient seda saab tööriistade loend, trimmed to the fields that matter, with annotations and an output schema added in the form the current specification defines. It shows the pattern: a verb-noun name, an instructional description, a schema whose property descriptions do the model's error-prevention, and hints a client can use to decide whether to confirm.

{
  "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
  }
}

Märkmed ütlevad: see kirjutab, see lisab ainult (mustandi), kahekordne kutsumine loob kaks mustandit ja see ei puutu süsteemist väljapoole. Klientidel tuleb märkmeid käsitleda kui usaldamatuid, kui server ei ole usaldusväärne, seega on need vihjed kinnituskäitumiseks, mitte serveri enda kontrollide asendamiseks.

Kolm valikut selles määratlemises on teadlikud. Tulemuseks on identifikaator, mille mudel peab kaasa tooma. sendInvoice ja registreeri makse, mis on spetsifikatsiooni soovitatud viis kõnede seostamiseks, kuna serverid ei hoia seansi olekut. Tööriist loob mustandi, mitte postitatud arve, seega on kirjutamine lisav ja inimene või eraldi heakskiitmisvahend lõpetab selle. Ja väljundi skeem tähendab, et integratsioon saab numbrit ja summat lugeda andmetena, samas kui mudel loeb sama tulemust tekstina.

Tööriistade piiritlemine kasutajale.

HTTP üle jõuab kutsuja OAuth juurdepääsutokeniga, mis on seotud teie serveriga, ja see token tuvastab isiku. Spetsifikatsioon lubab tulemuse tööriistade loend erineda päringu autentimisandmetest, seega on esimene ulatuse otsus filtreerida nimekiri selle isiku rolli järgi enne selle tagastamist: lao kasutaja ei saa kiida arveLoend ei tohi varieeruda ühenduse järgi ega teiste kõnede kõrvalmõjuna, vaid ainult autoriseerimise põhjal, mis muudab selle vahemälutatavaks.

Teine otsus on kontrollida uuesti täitmisel. Klient saab saata mis tahes kutsumise, mida ta soovib, ja mudelit saab tööriista tulemuses teksti abil manipuleerida, et proovida ühte. Tuvasta kasutaja tokenist igal kutsumisel, kontrolli tööriista nõutud õigusi ja keela tööriista täitmise vea tõttu, mida mudel saab lugeda. Hoia OAuth ulatused jämedad (Sois väljastab lugemis-, kirjutamis- ja offline ulatused) ja lase ERP enda rollidel olla peenekoeline piir, kuna need rollid juba eksisteerivad, neid juba hallatakse ja need tähendavad juba midagi äri jaoks. Atribuudi iga kutsumine logis isikule koos selle argumentide ja tulemusega, et agendi töö oleks ülevaatlik täpselt nagu isiku oma.

1. Token saabubKinnita allkiri ja et sihtrühm on see server, nagu nõuab RFC 8707; lükka tagasi kõik muu 401-ga.
2. Tuvasta isikMäära token kasutajale töökeskkonnas ja laadi nende roll ja installitud rakendused.
3. Filtreeri nimekiriTagasta ainult need tööriistad, mida roll võib kasutada, stabiilses järjekorras, tööriistade/nimekiri.
4. Kontrolli kõnetTööriistade/kõne puhul kontrolli luba uuesti ja keela isError'iga, kui see puudub; mitte midagi ei toimu.
5. Käivita ja logiTeosta tehing, mõõda seda, kui sinu enda agent tegi põhjenduse, ja kirjuta kõne auditi logisse selle isiku alla.

Kirjutamise käsitlemine.

Mudel, mis saab ebaselge tulemuse, kutsub uuesti, ja mudel, mis saab vea, proovib parandatud sisendit. Kujunda selle jaoks. Loomise kirjutised peaksid tagastama käepideme ja, kui võimalik, aktsepteerima idempotentsusvõtit või looduslikku võtit, et kordust tuvastada. Oleku muutvad kirjutised peaksid olema selged nende sooritatud ülemineku osas ja keelduma võimatutest koos arusaadava põhjusega: makse registreerimine tühistatud arve vastu on onViga tulemus, mis seda ütleb, mitte vaikne no-op ja mitte virna jälg. Ära jäta osalist kirjutamist; kui mitme sammu tööriist ei saa lõpetada, tagasta ja teata.

• Eelista mustandeid ja kinnitusi. Tee loomine lisav (mustand) ja anna lõpetamisele oma tööriist koos oma lubadega, nii et hävitav samm on see, mida klient kinnitab ja roll kontrollib.
• Märgi hävitavad tööriistad. Seadista destructiveHint tühistamiste ja kustutamiste kohta ning öelge seda kirjelduse osas; Claude ja ChatGPT kasutavad selliseid signaale, kui otsustavad küsida enne helistamist.
• Küsi, mitte ära arva. Kui kõne vajab otsust, mida tööriist ei saa teha, tagastage sisendit nõudev tulemus koos küsimise taotlusega; klient esitab küsimuse isikule ja proovib kõnet uuesti vastusega.
• Piira plahvatusraadiust. Piira kiirus iga ühenduse kohta, kehtesta kulutuste piir igas integratsioonis, kus sinu agent teeb järeldusi, ja valideeri iga sisend serveripoolsel küljel sõltumata skeemist, kuna skeem on mudeli jaoks soovitus, mitte jõustamine.

Pinna testimine reaalse kliendiga.

MCP inspektor teostab tööriistade loend ja tööriista kutsumine ja järgib OAuth voogu. Tõeline test on mudel. Ühenda Claude kohandatud ühendajana või ChatGPT arendaja režiimis, logi sisse kasutajana, kellel on kitsas roll, ja küsi ühe rutiinse tulemuse kohta, mis vajab kolme või nelja tööriista. Vaata, milliseid tööriistu see valib ja miks; vale valik on peaaegu alati kirjelduse probleem. Seejärel logi sisse kasutajana, kellel puudub üks lubadustest, ja kinnita, et käitamine peatub õiges kõnes koos põhjusega, mille mudel tagasi kordab.

Nii on ehitatud ja kontrollitud Sois tööruumi server: tehingud kui tööriistad, juhendavad kirjeldused, rolli filtreeritud nimekiri, iga kõne teine kontroll, mustandid enne heakskiitu ja logi, mida inimene saab lugeda. Arendajad, kes loovad rakendusi turule, avaldavad tööriistu samasse nimekirja samade reeglite alusel, nii et rakendus on kasutatav igasuguse agendi poolt kohe, kui see on installitud. Muster ei ole spetsiifiline ühele tootele; iga ERP, mis selle omaks võtab, muutub selliseks, mida agent saab käitada.

Küsimused, mida inimesed esitavad

Seda artiklit vaadatakse üle, kui kirjeldatud tooted muutuvad. Järgmine planeeritud ülevaatus: 4. detsember 2026.