Ingen klientcredential til dokumentationsserveren
Den lokale stdio-server skal ikke konfigureres med Supabase service role, kundens sessioncookie eller et produktionsapptoken. Den bruger dem ikke. At give den sådanne værdier skaber kun en unødvendig hemmelighed i en ekstra proces og dens konfiguration.
Serveren accepterer kendte side-ID'er, kendte operationer og et eksplicit journalinput. Den accepterer ikke SQL, en generisk HTTP-metode med en fri destination eller en filsti. Afgrænsningen gælder serverkoden, ikke blot dens sproglige instruktion til modellen.
Dokumentindhold er ikke instruktioner til systemet
En dokumentationsside kan indeholde curl, JSON og eksempler på fejl. Klienten skal behandle dette som information, ikke som en ordre om at udføre handlinger automatisk. Et eksempel med en placeholder er ikke et credential og skal ikke udfyldes med et tilfældigt token fra en anden forbindelse.
Særligt ved en fremtidig udvidelse med kundedokumenter skal indholdet være ubetroet: en faktura kan indeholde tekst, der forsøger at få modellen til at sende data et andet sted hen. En modelbesked kan ikke tilsidesætte serverens scopekontrol eller bankforbud.
Beskrivende værktøjsmetadata
Værktøjerne annonceres som read-only og uden åben netværksadgang. Det hjælper klienten med at vise risikoen, men metadata skal ikke bruges som det eneste sikkerhedsbevis. En forkert implementation kan annoncere et ufarligt værktøj og stadig skrive data; derfor skal den faktiske kode og transport undersøges.
De fire værktøjer udfører kun de dokumenterede lokale operationer. hours_api_describe giver en beskrivelse, ikke indholdet af den beskrevne route. hours_journal_validate returnerer altid, at intet er bogført.
Protokolgrænser
Den moderne server kræver den understøttede protokolversion på hver request. Store meddelelser, ugyldig UTF-8, forkert JSON og ukendte metoder afvises. stdout indeholder kun protokolmeddelelser; almindelig logging hører på stderr.
Serveren henter ikke eksterne JSON Schema-referencer fra netværket. En schemahenvisning må ikke blive en indirekte URL-henter. Dokumentationslæsning har egne tekstgrænser, så en klient kan fortsætte via next_offset uden at behøve et ubegrænset enkeltresultat.
Fjern-MCP med kundedata
En fjern-MCP, der kan handle på kundens data, kræver mere end at eksponere den lokale stdio-handler på en webadresse. Ressourceidentifikation, audience, tokenvalidering, brugerautorisation, revocation, sessionhåndtering og transportadfærd skal passe til den valgte protokolversion.
En sådan MCP må heller ikke videresende et modtaget token til en anden tjeneste, som om det automatisk var gyldigt dér. Den skal bruge den samme afgrænsede Hours-adgangsmodel som partnergatewayen og må ikke kunne åbne bankfelter gennem en alternativ kanal. Hours MCP tilbyder ikke et sådant fjernflow.
Bekræftelse ved finansielle handlinger
Dokumentationsserveren har ingen finansielle skriveværktøjer. Et senere værktøj til bogføring skal have et særskilt, håndhævet mandat og en tydelig skelnen mellem prepare og commit. Klienten skal kunne vise den konkrete handling og dens konsekvens, ikke kun et generelt "tillad værktøjer"-valg.
En brugerbekræftelse i chatten er ikke i sig selv en verificeret kundegrant i Hours. En AI-agent må ikke selv tildele scope, vælge en fremmed organisation eller konstruere et bogføringsmandat ud fra et tekstsvar.
Drift og review
Pin den version, teamet bruger. Registrér ændringer i værktøjsnavne, inputfelter, output og capabilities. En opgradering fra den ældre til den moderne indgang skal testes med den konkrete klient; det er ikke kun en versionsstreng i et dokument.
Ved fejl skal support bruge et syntetisk reproducerbart eksempel. Del ikke en hel samtale med kundebilag eller tokens som standard. Kontrollér også AI-klientens egen databehandling: at Hours MCP ikke gemmer kundedata betyder ikke, at en tredjepartsklient aldrig behandler det, brugeren selv indsætter i samtalen.