MCP ERP: praktisks ceļvedis

Sāciet no darījuma, nevis no tabulas

Pirmais instinkts, atklājot ERP, ir ģenerēt rīku katrai tabulai ar izveidi, lasīšanu, atjaunināšanu un dzēšanu katrā. Tas rada lielu, vienveidīgu sarakstu, ko modelis apstrādā slikti, jo biznesa noteikums, ka rēķinam katrā rindā ir nepieciešama nodokļu likme, vai ka krājumi nevar tikt nosūtīti, pirms tie nav rezervēti, nekur nav redzams modelim. Atklājiet darbības. Noderīgs tests ir, vai cilvēks varētu aprakstīt rīku kā kaut ko, ko viņš izdarīja šodien: izsniegt rēķinu, reģistrēt maksājumu, pārvietot darījumu, atlikt vajāšanu. Katram no tiem ir savi noteikumi, tie validē savus ievades datus un atgriež lasāmu rezultātu.

Blakus darbībām pievienojiet nelielu skaitu kopsavilkuma rīku, kas atbild uz jautājumiem, ko modelis uzdod pirms rīkošanās. Viens izsaukums, kas atgriež konta profilu, veselību, atvērtos vienumus un neseno vēsturi, ietaupa modelim četrus izsaukumus un vairākus tūkstošus konteksta tokenu, un tas padara nākamo darbību labāk informētu. Sois šos rīkus sauc par eksaminācijas rīkiem; pārbaudīt kontaktinformāciju un iegūt grāmatvedības kopsavilkumu ir divi. Saglabājiet kopējo virsmu redzeslokā: Claude Code pēc noklusējuma ierobežo servera izeju katrā izsaukumā, un gan Claude, gan OpenAI piedāvā atliktu ielādi vai rīku meklēšanu lielām sarakstiem, tāpēc serverim ar vairākiem simtiem rīku jāatgriež tie noteiktā secībā (specifikācija to prasa, lai klienti varētu kešot) un jāfiltrē pēc lomas pirms uzskaitīšanas.

Nosauciet rīkus, lai modelis izvēlētos pareizo

Specifikācija viegli ierobežo nosaukumus: viens līdz 128 rakstzīmēm, burti, cipari, apakšsvītra, mīnuss un punkts, jūtīgs pret lielajiem un mazajiem burtiem, unikāls serverī. Viss pārējais ir konvencija, un konvencija, kas darbojas, ir darbības vārds, kam seko biznesa lietvārds konsekventā formā, ar tiem pašiem darbības vārdiem, kas visur nozīmē to pašu. Modelis, izvēloties starp: meklētRēķinus, iegūt rēķinu un izveidot rēķinu izvēlas starp sarakstu, vienu ierakstu un rakstīšanu, un tas šo modeli apgūst vienreiz visam serverim.

Aprakstus lasa modelis, kas ir spiests rīkoties, tāpēc rakstiet tos kā norādījumus. Pirmajā teikumā norādiet, ko rīks dara, pēc tam nosacījumus. Ja blakus esošais rīks ir pareizā izvēle tuvam pieprasījumam, norādiet to pēc nosaukuma. Ja laukam jābūt iestatītam, lai rezultāts būtu pareizs, norādiet to LIELAJOS BURTOS, ja nepieciešams; Sois rēķinu rīks norāda modelim, ka nodokļu likme jānosaka katrā rindā un ka precīzās likmes nāk no nodokļu veidu saraksts, jo rēķins bez PVN ir sliktāks neveiksme nekā atteikta zvana. Iekļaujiet vienu piemēra zvanu. Viss, kas modelim nepieciešams, lai pareizi izsauktu rīku, jābūt rīkā, jo tas nekad neatvērs jūsu dokumentāciju.

Piemēra rīka definīcija

Šis ir Sois rēķinu rīks, kā klients to saņem no tools/listīsi izgriezts uz svarīgākajiem laukiem, ar piezīmēm un izejas shēmu, kas pievienota tādā formā, kā to nosaka pašreizējā specifikācija. Tas parāda modeli: darbības-vārds-vārds nosaukums, instrukciju apraksts, shēma, kuras īpašību apraksti nodrošina modeļa kļūdu novēršanu, un norādes, ko klients var izmantot, lai izlemtu, vai apstiprināt.

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

Piezīmes saka: šis raksta, tas tikai pievieno (melnrakstu), zvanot tam divreiz, tiek izveidoti divi melnraksti, un tas neskar neko ārpus sistēmas. Klientiem jāuztver piezīmes kā neuzticamas, ja vien serveris nav uzticams, tāpēc tās ir norādes apstiprināšanas uzvedībai, nevis aizvietotājs servera paša pārbaudēm.

Trīs izvēles šajā definīcijā ir apzinātas. Rezultāts atgriež identifikatoru, ko modelim jānes iekšā nosūtīt rēķinu un ierakstītMaksājumu, which is the specification's recommended way to relate calls now that servers hold no session state. The tool creates a draft, not a posted invoice, so the write is additive and a person or a separate approval tool finalises it. And the output schema means an integration can read the number and total as data while the model reads the same result as text.

Rīku pielāgošana lietotājam

Pār HTTP zvanītājs ierodas ar OAuth piekļuves tokenu, kas ir saistīts ar jūsu serveri, un šis token identificē personu. Specifikācija ļauj rezultātam tools/list atkarībā no pieprasījuma akreditācijas, tāpēc pirmais apjoma lēmums ir filtrēt sarakstu pēc šīs personas lomas pirms tā atgriešanas: noliktavas lietotājs nesaņem apstiprināt rēķinu.Sarakstam nedrīkst mainīties atkarībā no savienojuma vai citu izsaukumu blakus efekta, tikai pēc autorizācijas, kas padara to kešējamu.

Otrais lēmums ir vēlreiz pārbaudīt izpildes laikā. Klients var nosūtīt jebkuru zvanu, ko vēlas, un modeli var manipulēt ar tekstu rīka rezultātā, lai izmēģinātu vienu. Atrisiniet lietotāju no tokena katrā zvanā, pārbaudiet rīka prasīto atļauju un noraidiet ar rīka izpildes kļūdu, ko modelis var lasīt. Saglabājiet OAuth apjomu rupju (Sois izsniedz lasīšanas, rakstīšanas un offline apjomus) un ļaujiet ERP pašiem lomu būt smalki definētai robežai, jo šīs lomas jau pastāv, jau tiek uzturētas un jau nozīmē kaut ko biznesam. Pievienojiet katru zvanu personai žurnālā ar tās argumentiem un rezultātu, lai aģenta darbs būtu pārskatāms tieši tāpat kā personas darbs.

1. Tokena ierašanāsPārbaudiet parakstu un to, ka auditorija ir šis serveris, kā to prasa RFC 8707; noraidiet jebko citu ar 401.
2. Atrisiniet personuPiesaistiet token pie lietotāja darba vietā un ielādējiet viņa lomu un instalētās lietotnes.
3. Filtrēt sarakstuAtgrieziet tikai tos rīkus, kurus loma var izmantot, stabilā secībā no tools/list.
4. Pārbaudiet zvanuRīkos/call vēlreiz pārbaudiet atļauju un noraidiet ar isError, ja tā trūkst; nekas netiek izpildīts.
5. Izpildīt un reģistrētIzpildiet darījumu, mērīt to, ja jūsu aģents veica secinājumus, un ierakstiet zvanu audita žurnālā zem šīs personas.

Rakstu apstrāde

Modelis, kas saņem neskaidru rezultātu, izsauks vēlreiz, un tas, kas saņem kļūdu, mēģinās ar labotu ievadi. Izstrādājiet to. Ieraksti, kas rada, jāatgriež rokturis un, kur iespējams, jāpieņem idempotences atslēga vai dabiskā atslēga, lai atkārtojums tiktu atklāts. Ieraksti, kas maina stāvokli, jābūt skaidriem par pāreju, ko tie veic, un jāatsakās no neiespējamiem ar saprotamu iemeslu: maksājuma ierakstīšana pret atcelto rēķinu ir isError rezultāts, kas to saka, nevis kluss nē un nevis steka izsekošana. Nekad neatstājiet daļēju ierakstu; ja vairāku soļu rīks nevar pabeigt, atgrieziet un ziņojiet.

• Dodiet priekšroku melnrakstiem un apstiprinājumiem. Padariet izveidi papildinošu (melnraksts) un piešķiriet pabeigšanai savu rīku ar savām atļaujām, lai destruktīvais solis būtu tas, ko klients apstiprina, un loma kontrolē.
• Atzīmējiet destruktīvos rīkus. Iestatīt destructiveHint par anulēšanu un dzēšanu un norādiet to aprakstā; Claude un ChatGPT abi izmanto šādus signālus, kad izlemj jautāt pirms zvana veikšanas.
• Jautājiet, nevis miniet. Ja zvanam nepieciešama lēmuma pieņemšana, ko rīks nevar izdarīt, atgrieziet rezultātu, kas prasa ievadi, ar jautājumu; klients uzdod jautājumu personai un atkārto zvanu ar atbildi.
• Ierobežojiet sprādziena rādiusu. Ierobežojiet ātrumu katrai savienojumam, ierobežojiet izdevumus katrai integrācijai, kur jūsu aģents veic loģiku, un validējiet katru ievadi servera pusē neatkarīgi no shēmas, jo shēma ir padoms modelim, nevis izpilde.

Virsmu testēšana ar reālu klientu

MCP inspektors veiks tools/list un tools/call un iziet OAuth plūsmu. Patiesais tests ir modelis. Savienojiet Claude kā pielāgotu savienotāju vai ChatGPT izstrādātāja režīmā, piesakieties kā lietotājs ar šauru lomu un lūdziet vienu ikdienas rezultātu, kas prasa trīs vai četrus rīkus. Novērojiet, kurus rīkus tas izvēlas un kāpēc; nepareiza izvēle gandrīz vienmēr ir apraksta problēma. Pēc tam piesakieties kā lietotājs bez vienas no atļaujām un apstipriniet, ka izpilde apstājas pie pareizā zvana ar iemeslu, ko modelis atkārto.

Tā tiek veidots un pārbaudīts Sois darba vietas serveris: darījumi kā rīki, instrukciju apraksti, loma filtrēta saraksts, otra pārbaude katram zvanam, melnraksti pirms apstiprinājumiem un žurnāls, ko var izlasīt. Izstrādātāji, kas veido lietotnes tirgum, publicē rīkus tajā pašā sarakstā saskaņā ar tiem pašiem noteikumiem, tāpēc lietotne ir lietojama jebkuram aģentam, tiklīdz tā ir instalēta. Šis modelis nav specifisks vienam produktam; jebkurš ERP, kas to pieņem, kļūst par kaut ko, ko aģents var darbināt.

Cilvēki uzdod jautājumus

Šis raksts tiek pārskatīts, kad mainās tajā aprakstītie produkti. Nākamais plānotais pārskats: 2026. gada 4. decembris.