MCP-rajapinnan käytössä Claude Coden kautta on muutamia ongelmia, joista aiheutuu mm. puuttuvia ja virheellisiä tietoja tekoälyn luomissa tositteissa sekä pakollisia manuaalisia steppejä tiedostojen lähetyksessä. Tässä clankerin itse tekemä kooste korjausehdotuksineen.

1. Tositteen päivämäärä ja kuvaus ohitettiin luonnissa ilman virhettä

Työkalu: bookkeeping_document_create

Mitä tapahtui: Kaksi MANUAL-tositetta luotiin yhdellä kutsulla. Päivämäärä ("date": "2026-07-31") ja kuvaus ("description") annettiin blueprint-olion sisällä. Kutsu onnistui (write_outcome: committed), mutta molemmat tositteet saivat päivämääräksi 2026-10-28 ja tyhjän kuvauksen. Kumpikaan arvo ei ollut annettu: kutsun päivä oli 2026-11-01, eikä 28.10. liity aineistoon mitenkään.

Tositteet: bd:1905014 (luontihetkellä numero 261028-1) ja bd:1905015 (261028-2), nykyään 260731-4 ja 260731-3.
Korjaus onnistui bookkeeping_document_update-työkalulla, kun date ja description annettiin payloadin ylätasolla.

Ongelmat:

bookkeeping_document_create-työkalun skeema ei kerro, mihin date ja description kuuluvat. Payloadissa on additionalProperties: true, ja dokumentoidut kentät ovat vain blueprint, attachment_ids, contact, contact_id, tag_ids ja tag_names. Päivämäärä on kirjanpitotositteen pakollinen tieto, mutta se puuttuu skeemasta kokonaan.
Tuntemattomat tai väärään paikkaan annetut kentät ohitetaan hiljaa. Kirjanpidossa väärä päivä voi siirtää tositteen väärälle ALV-kaudelle tai tilikaudelle.
Puuttuva päivä korvataan arvolla, jonka alkuperä ei selviä (2026-10-28).

Ehdotus: dokumentoi date ja description skeemassa ja tee päivämäärästä pakollinen. Hylkää tunnistamattomat kentät virheellä, tai palauta ainakin varoitus ohitetuista kentistä.

2. Kuvauksen 256 merkin raja ei näy skeemassa, ja luonti ja päivitys käyttäytyvät eri tavoin

Työkalut: bookkeeping_document_create, bookkeeping_document_update

Kohdan 1 luontikutsun kuvaukset olivat yli 256 merkkiä. Luonti ei antanut virhettä, ja kuvaus jäi tyhjäksi. Päivityskutsu samalla kuvauksella hylättiin virheellä {"description":["Arvo saa olla enintään 256 merkkiä pitkä."]}. Aineistosta ei selviä, ohittiko luonti kuvauksen sen paikan vai sen pituuden vuoksi.

Ehdotus: kerro pituusraja skeemassa (maxLength: 256) ja validoi kuvaus samoin luonnissa ja päivityksessä.

3. Tiedostoja ei voi lähettää muualta kuin keskustelun liitteistä

Työkalu: bookkeeping_file_upload

Työkalu hyväksyy vain attachment_refs-viitteitä (att:…), eli tiedostoja, jotka käyttäjä on liittänyt keskusteluun claude.ai:ssa. Koneelle tallennettua tiedostoa ei voi lähettää komentoriviasiakkaasta (Claude Code) eikä muista MCP-asiakkaista, joissa tällaista liitemekanismia ei ole. Tämän vuoksi siirtotositteille ei saatu liitettyä tositeaineistoa: Procountorin raportit, tiliotteet ja laskujen PDF:t.

MCP-protokollassa ei ole vakiotapaa siirtää tiedostoa asiakkaalta palvelimelle, joten rajoitus on osin yleinen. Muut MCP-palvelimet ratkaisevat sen esimerkiksi näin:

Esiallekirjoitettu lähetysosoite: työkalu palauttaa väliaikaisen URL:n, johon asiakas lähettää tiedoston HTTP:llä.
Base64-sisältö työkalun parametrina pienille tiedostoille, esimerkiksi enintään muutaman megatavun PDF:ille.

Ehdotus: lisää toinen näistä, jotta tositteiden liitteet voi viedä myös muista asiakkaista.

4. Blueprintin rakennetta ei ole dokumentoitu

Työkalut: docs_retrieve (kind=blueprint), bookkeeping_document_create

Työkalun kuvaus neuvoo hakemaan blueprintin rakenteen docs_retrieve-kutsulla. Palautettu ohje käsittelee kuitenkin vain raportointia ja poikkeamien etsintää. Siinä ei kuvata blueprintin kenttiä, kuten blueprint_type, debet_entries, credit_entries, expense_entries, account_id, vat_code, vat_rate, vat_method ja amount, eikä sitä, ovatko summat bruttoja vai nettoja tai mitä vat_method tarkoittaa. Rakenne jouduttiin päättelemään hakemalla olemassa oleva tosite (bookkeeping_document_retrieve) ja kopioimalla sen muoto.

Lisäksi rivit viittaavat tileihin sisäisellä tunnisteella (account_id, esim. 8423496), vaikka ohjeissa kehotetaan käyttämään tilinumeroita. Tilinumerolla ei voi kirjoittaa, joten jokainen tili on haettava ensin tilikartasta.

Ehdotus: kuvaa blueprintin kentät ja esimerkki MANUAL-tositteesta ohjeessa tai skeemassa, ja hyväksy riveillä tilinumero (account_number) sisäisen tunnisteen vaihtoehtona.

5. Avaussaldon etumerkkikäytäntö ei näy dokumentaatiossa

Työkalu: bookkeeping_account_update (opening_balance)

Ohjeesta ei selviä, annetaanko vastattavaa-tilien (oma pääoma, velat) avaussaldo positiivisena vai negatiivisena. Raportointityökalut käyttävät eri käytäntöä (net = debet − kredit). Käytäntö jouduttiin selvittämään kirjoittamalla testiarvo ja lukemalla tase: tilin luonnollinen puoli on positiivinen, eli sekä saamiset että velat ovat positiivisia ja tappio negatiivinen.

Avaussaldoja ei myöskään tarkisteta kokonaisuutena. Välitilassa vastaavaa ja vastattavaa eivät täsmänneet, eikä työkalu varoittanut siitä.

Ehdotus: dokumentoi etumerkkikäytäntö ja tarjoa työkalu, joka asettaa kaikki avaussaldot yhdellä kutsulla ja tarkistaa, että ne täsmäävät. Vaihtoehtoisesti palauta täsmäysero vastauksessa.