Με πάνω από 20 χρόνια εμπειρίας, μεταμορφώνουμε την ψηφιακή σας παρουσία. Εξειδικευόμαστε στην κατασκευή ιστοσελίδων και E-Shop, το SEO και το Digital Marketing, τα ERP λογισμικά και τους έξυπνους αυτοματισμούς που απογειώνουν την επιχείρησή σας.
Διεύθυνση:
Εγνατία 154, Θεσσαλονίκη 546 36
Τηλέφωνο:
+30 231 231 4095
E-mail:
hello@twodots.gr
Έτοιμοι για το επόμενο βήμα;
Τι αλλάζει με το stateless MCP 2026-07-28: explicit handles, authorization ανά αντικείμενο, idempotency και ασφαλείς multi-turn AI agents σε παραγωγή.
Στο MCP 2026-07-28 τα protocol-level sessions καταργήθηκαν: κάθε request είναι αυτοτελές και, όταν μια εφαρμογή χρειάζεται συνέχεια, ο server εκδίδει ένα explicit handle που το μοντέλο περνά στις επόμενες κλήσεις.
Η αλλαγή απλοποιεί την οριζόντια κλιμάκωση, επειδή μια κλήση μπορεί να φτάσει σε οποιοδήποτε instance χωρίς sticky routing ή κοινό session store. Δεν μετατρέπει όμως το μοντέλο σε βάση δεδομένων ούτε κάνει το state αξιόπιστο από μόνο του. Το καλάθι, η παραγγελία, το CRM record ή το browser task εξακολουθούν να ανήκουν στην εφαρμογή· το μοντέλο μεταφέρει μόνο το αναγνωριστικό που συνδέει την επόμενη ενέργεια με το σωστό αντικείμενο.
Για μια επιχείρηση που σχεδιάζει AI αυτοματισμούς με πραγματικές ενέργειες, το κρίσιμο συμπέρασμα είναι σαφές: το handle είναι μη έμπιστη είσοδος. Authorization ανά αντικείμενο, tenant isolation, idempotency, audit trail και ανθρώπινη επιβεβαίωση για ενέργειες υψηλού αντικτύπου πρέπει να επιβάλλονται από τις υπηρεσίες, όχι από το prompt ή τη μνήμη του μοντέλου. Η ίδια αρχή βρίσκεται στον πυρήνα της διακυβέρνησης multi-LLM agents.
Τέσσερα διαφορετικά επίπεδα που δεν πρέπει να συγχέονται
Μεταφέρει έκδοση, μέθοδο, capabilities και arguments. Στη νέα έκδοση δεν χρειάζεται μόνιμο protocol session.
Δείχνει ποιο καλάθι, task ή browser αφορά η επόμενη κλήση. Είναι ordinary tool argument και όχι νέο wire primitive.
Παραμένει στη βάση δεδομένων, στο CRM, στο e-shop ή στην υπηρεσία που είναι η πηγή αλήθειας.
Αποφασίζει αν ο caller επιτρέπεται να χρησιμοποιήσει το συγκεκριμένο handle για τη συγκεκριμένη ενέργεια.
Η επίσημη έκδοση 2026-07-28 του Model Context Protocol αφαίρεσε το ζεύγος initialize/initialized και το header Mcp-Session-Id. Κάθε request μεταφέρει πλέον όσα χρειάζεται για να ερμηνευτεί, ενώ το προαιρετικό server/discover επιτρέπει σε έναν client να μάθει τις δυνατότητες του server πριν από άλλη ενέργεια. Στο HTTP, η έκδοση του πρωτοκόλλου και τα στοιχεία δρομολόγησης γίνονται ορατά στο ίδιο το request.
Η αλλαγή δεν είναι απλώς βελτίωση σύνταξης. Στην προηγούμενη γενιά του πρωτοκόλλου, ο server μπορούσε να εκδώσει session ID και ο client όφειλε να το επιστρέφει. Σε ένα οριζόντιο deployment αυτό συχνά οδηγούσε σε sticky routing ή shared session storage. Με το stateless core, οποιοδήποτε συμβατό instance μπορεί να αναλάβει την κλήση χωρίς να γνωρίζει τι συνέβη σε προηγούμενο transport session.
Η επίσημη ανακοίνωση συνδέει τη νέα αρχιτεκτονική και με Multi Round-Trip Requests, header-based routing, cacheable list results και ενισχύσεις authorization. Αυτά είναι ξεχωριστά χαρακτηριστικά. Η κατάργηση sessions από μόνη της δεν λύνει τη διαχείριση ταυτότητας, τη μακρόχρονη εκτέλεση ή την ασφάλεια ενός workflow· αλλάζει το σημείο στο οποίο πρέπει να σχεδιαστούν.
Ένα e-shop εξακολουθεί να αποθηκεύει καλάθια και παραγγελίες. Ένα CRM εξακολουθεί να κρατά επαφές, εταιρείες και tickets. Ένα coding εργαλείο εξακολουθεί να έχει repository, branch και pull request. Η νέα προδιαγραφή αφαιρεί την κρυφή συσχέτιση στο transport· δεν αφαιρεί τα επιχειρησιακά δεδομένα ούτε την ανάγκη συνέχειας.
Η διάκριση είναι κρίσιμη για την αρχιτεκτονική. Το μοντέλο δεν πρέπει να γίνει η πηγή αλήθειας για την παραγγελία ή τον πελάτη. Αν το context συμπιεστεί, λήξει ή επαναφορτωθεί, η εφαρμογή πρέπει να μπορεί να ανακτήσει το αντικείμενο με ελεγχόμενο αναγνωριστικό και να επαληθεύσει ξανά την πρόσβαση. Το state παραμένει server-side, με lifecycle, versioning και κανόνες που δεν εξαρτώνται από τη φυσική γλώσσα.
Αυτό κάνει το stateless MCP κοντά σε μια γνωστή αρχή του web: το request κατονομάζει τον πόρο που θέλει να διαβάσει ή να αλλάξει. Το κρίσιμο επιπλέον βήμα για agentic συστήματα είναι ότι το argument μπορεί να επιλεγεί ή να επανεκπεμφθεί από μοντέλο. Άρα πρέπει να αντιμετωπίζεται όπως κάθε client-controlled identifier, όχι ως απόδειξη ιδιοκτησίας.
Το SEP-2567 χρησιμοποιεί ένα καλάθι ως απλό παράδειγμα. Ο server προσφέρει ένα εργαλείο δημιουργίας καλαθιού, επιστρέφει basket_id και τα επόμενα εργαλεία απαιτούν το ίδιο ID ως argument. Το handle βρίσκεται στο transcript, οπότε ένας client που αποθηκεύει τη συνομιλία μπορεί να το φέρει ξανά μπροστά στο μοντέλο μετά από reload ή αλλαγή συσκευής.
Τα explicit handles δεν αποτελούν ειδικό τύπο του MCP. Στο wire format είναι ordinary strings. Η σχέση ανάμεσα στο output ενός εργαλείου και στο input του επόμενου προκύπτει από τα ονόματα και τις περιγραφές των tools. Αυτή η ευελιξία επιτρέπει πολλαπλά καλάθια, browser contexts ή tasks μέσα στην ίδια συνομιλία, αλλά αυξάνει και την ανάγκη για σαφή tool schemas και ακριβείς επιστροφές.
Ένα καλό tool result δεν επιστρέφει μόνο ένα αδιαφανές ID. Επιστρέφει ασφαλή στοιχεία επιβεβαίωσης, όπως τύπο αντικειμένου, masked reference, owner context που δεν αποκαλύπτει προσωπικά δεδομένα, version και expiry. Έτσι ο orchestrator, το μοντέλο και ο reviewer μπορούν να εντοπίσουν μια προφανή ασυμφωνία πριν από mutation, χωρίς αυτά τα στοιχεία να αντικαθιστούν τον server-side έλεγχο.
Το πρώτο όφελος είναι η απλούστερη κλιμάκωση. Requests μπορούν να μοιραστούν με round-robin load balancing, επειδή το instance δεν χρειάζεται να αναζητήσει protocol session που δημιουργήθηκε αλλού. Η αντικατάσταση ενός κόμβου δεν κόβει από μόνη της τη συνέχεια, εφόσον τα πραγματικά δεδομένα της εφαρμογής βρίσκονται σε κοινή, ανθεκτική υπηρεσία.
Το δεύτερο όφελος είναι η παρατηρησιμότητα. Όταν το order_id ή το task_id εμφανίζεται ρητά στο tool call, μπορεί να συσχετιστεί με caller, model version, conversation, idempotency key και downstream αποτέλεσμα. Η ομάδα μπορεί να δει ποια μετάβαση άλλαξε στόχο, αντί να αναζητά μια αόρατη εξάρτηση από σύνδεση ή sticky session.
Το τρίτο όφελος είναι η καθαρότερη αποτυχία. Ένα request μπορεί να επαναληφθεί σε άλλο instance χωρίς να χρειάζεται ανακατασκευή transport session. Αυτό δεν σημαίνει ότι κάθε mutation είναι ασφαλές να επαναληφθεί. Η εφαρμογή χρειάζεται idempotency semantics που αναγνωρίζουν την ίδια επιχειρησιακή πρόθεση, ειδικά σε πληρωμές, refunds, δημιουργία tickets και αποστολές.
Σε παραδοσιακό κώδικα ο client περνά ένα ID επειδή η ροή έχει προγραμματιστεί ρητά. Σε ένα agentic workflow το μοντέλο μπορεί να διαβάσει το handle από το αποτέλεσμα ενός tool, να το διατηρήσει μέσα σε πολλές στροφές και να το τοποθετήσει σε επόμενη κλήση. Η ορθότητα της συσχέτισης εξαρτάται έτσι και από τη συμπεριφορά του μοντέλου, όχι μόνο από τον compiler ή το API client.
Η εύκολη αποτυχία είναι ένα handle που λείπει ή έχει λήξει: ο server το απορρίπτει. Η δύσκολη αποτυχία είναι ένα διαφορετικό αλλά καλοσχηματισμένο και υπαρκτό handle. Το API μπορεί να επιστρέψει HTTP success, ενώ η ενέργεια εφαρμόστηκε στο λάθος καλάθι, campaign ή customer record. Γι’ αυτό τα availability dashboards δεν αρκούν για να αποδείξουν επιχειρησιακή ορθότητα.
Η αντιμετώπιση δεν είναι να «θυμάται καλύτερα» το μοντέλο. Είναι να μειωθεί η εξουσία ενός λάθους argument: scopes ανά υπηρεσία, object-level authorization, tenant context που παράγεται server-side, preview πριν από κρίσιμη αλλαγή και επιβεβαίωση στόχου με ακριβή στοιχεία. Το μοντέλο μεταφέρει την πρόθεση· η εφαρμογή επιβάλλει τα όρια.
Η εργασία «LLMs Get Lost In Multi-Turn Conversation» σύγκρινε fully specified single-turn prompts με οδηγίες που αποκαλύπτονταν σταδιακά σε multi-turn συνομιλίες. Σε περισσότερες από 200.000 προσομοιώσεις με 15 μοντέλα και έξι generation tasks, οι συγγραφείς αναφέρουν μέση πτώση επίδοσης 39%. Η aptitude μειώθηκε κατά μέσο όρο 16%, ενώ το μέτρο unreliability αυξήθηκε 112%.
Η κλίμακα και τα βασικά ευρήματα της multi-turn μελέτης
Οι τιμές αφορούν το συγκεκριμένο πειραματικό setup με sharded instructions. Δεν είναι failure rate για MCP handles ή production agents.
Η ανάλυση κάλυψε περισσότερες από διακόσιες χιλιάδες simulated conversations.
Το πείραμα περιέλαβε ανοικτά και κλειστά μοντέλα διαφορετικών δυνατοτήτων.
Η reported απόδοση ήταν χαμηλότερη στο multi-turn setup σε σχέση με πλήρες single-turn input.
Η μεγαλύτερη μεταβολή εντοπίστηκε στη διακύμανση μεταξύ καλύτερων και χειρότερων runs.
Το σωστό συμπέρασμα είναι να δοκιμάζεται η πραγματική ροή σε βάθος συνομιλίας, με το μοντέλο και τα tools που θα μπουν σε παραγωγή — όχι να εφαρμόζεται το 39% ως πρόβλεψη σε κάθε agent.
Η μελέτη δεν αξιολόγησε MCP state handles ούτε μετρά την πιθανότητα να αλλαχτεί ένα basket_id. Επίσης, οι εργασίες της βασίζονταν σε σταδιακά αποκαλυπτόμενες απαιτήσεις, όχι σε ένα production tool trace. Η σύνδεση με το stateless MCP είναι αρχιτεκτονική υπόθεση: αφού το μοντέλο πρέπει να μεταφέρει κρίσιμη πληροφορία ανάμεσα σε στροφές, αξίζει να ελεγχθεί σε πραγματικές multi-turn συνθήκες.
Οι δοκιμές πρέπει να περιλαμβάνουν context pressure, retries, compaction, πολλαπλά ταυτόχρονα handles, αλλαγή σειράς tools και επανέναρξη συνομιλίας. Το pass στο πρώτο ή δεύτερο turn δεν πιστοποιεί τη ροή. Χρειάζονται negative cases όπου το handle λείπει, έχει λήξει, ανήκει σε άλλο tenant ή είναι έγκυρο αλλά δεν αντιστοιχεί στην πρόθεση του χρήστη.
Το SEP-2567 είναι σαφές για authenticated servers: ο server πρέπει να ελέγχει τον συνδυασμό handle και auth context σε κάθε κλήση. Το ID κατονομάζει τον πόρο, ενώ η ταυτότητα και τα ACLs αποφασίζουν την πρόσβαση. Για unauthenticated servers, όπου το handle λειτουργεί σαν capability token, η πρόταση ζητά τουλάχιστον 128 bits κρυπτογραφικά ασφαλούς entropy και περιορισμένη διάρκεια ζωής.
Η Akamai επισημαίνει ότι predictable tracking IDs ή state objects χωρίς αυστηρή επικύρωση μπορούν να επιτρέψουν workflow hijacking, πρόσβαση σε πληροφορίες άλλου agent και cross-tenant actions. Το ίδιο ισχύει για client-supplied metadata: ένα πεδίο που δηλώνει tenant ή ρόλο δεν πρέπει να θεωρείται αξιόπιστο επειδή βρίσκεται στο request. Ο tenant πρέπει να παράγεται από verified identity και server-side policy.
order_id, browser_id ή campaign_id δεν αποδεικνύει ότι ο caller επιτρέπεται να το διαβάσει ή να το αλλάξει. Κάθε mutation χρειάζεται object-level authorization και έλεγχο tenant στην τελική υπηρεσία.Αυτή η λογική ταιριάζει με όσα μαθαίνουμε από AI agents που απαιτούν ανεξάρτητη επαλήθευση και audit trail. Η έξοδος του μοντέλου είναι πρόταση προς εκτέλεση, όχι απόφαση πρόσβασης. Αν ένα prompt injection αλλάξει argument, η πολιτική πρέπει να απορρίψει την κλήση πριν αγγίξει το επιχειρησιακό αντικείμενο.
Πότε ένα handle είναι ασφαλές για χρήση;
Όταν είναι αδιαφανές και περιορισμένης διάρκειας, συνδέεται με verified caller και tenant, ελέγχεται για την επιτρεπόμενη πράξη και δεν αρκεί μόνο του για authorization.
Αν η εφαρμογή αποδέχεται οποιοδήποτε υπαρκτό ID που επιστρέφει το μοντέλο, το workflow δεν είναι έτοιμο για production — ακόμη κι αν όλα τα happy-path tests περνούν.
Ο πρώτος έλεγχος είναι object-level authorization. Κάθε tool call πρέπει να δεσμεύει caller, tenant, handle και action. Ένα read μπορεί να επιτρέπεται ενώ ένα refund όχι. Ένας customer-support agent μπορεί να βλέπει masked στοιχεία χωρίς να έχει δικαίωμα αλλαγής billing account. Η πολιτική πρέπει να εφαρμόζεται όσο πιο κοντά γίνεται στην πηγή αλήθειας.
Ο δεύτερος έλεγχος είναι idempotency. Το key πρέπει να αναγνωρίζει την ίδια επιχειρησιακή εντολή και να αποθηκεύει το αποτέλεσμα για ασφαλές retry. Αν ο agent επαναλάβει τη δημιουργία ticket ή τη χρέωση μετά από timeout, η εφαρμογή επιστρέφει το προηγούμενο αποτέλεσμα αντί να εκτελέσει δεύτερη φορά την πράξη. Σε non-idempotent αλλαγές, το retry policy χρειάζεται ρητή ανθρώπινη έγκριση.
Ο τρίτος έλεγχος είναι audit trail που συνδέει conversation, model και έκδοση, tool, caller identity, masked handle, idempotency key, policy decision και downstream result. Τα logs πρέπει να επιτρέπουν ανακατασκευή της απόφασης χωρίς να αποθηκεύουν secrets ή πλήρη προσωπικά δεδομένα. Alerts χρειάζονται για αλλαγή handle μέσα στην ίδια πρόθεση, cross-tenant rejection, ασυνήθιστα retries και mutation χωρίς προηγούμενο preview.
Σε άρθρο της Red Hat περιγράφεται περίπτωση όπου agent επέλεξε διαφορετικό account identifier και API με υπερβολικά ευρεία credentials χρέωσε 4.000 δολάρια σε λάθος πελάτη. Πρόκειται για vendor-authored operational example, όχι για ανεξάρτητα δημοσιευμένη incident report. Το χρήσιμο μάθημα είναι το control gap: η επιτυχής κλήση δεν σημαίνει σωστό στόχο, και scoped credentials μαζί με downstream validation περιορίζουν τον αντίκτυπο.
Σε ένα e-shop με agentic λειτουργίες, τα cart IDs, order IDs και return IDs πρέπει να αντιμετωπίζονται ως μη έμπιστα inputs. Ο authenticated χρήστης πρέπει να συνδέεται server-side με το αντικείμενο, ενώ αλλαγή διεύθυνσης, επιστροφή χρημάτων ή αγορά χρειάζεται preview με ποσό, παραλήπτη και επιβεβαίωση. Ένα handle που υπήρχε νωρίτερα στη συνομιλία μπορεί να είναι ληγμένο ή να αφορά διαφορετικό καλάθι.
Σε CRM και marketing, το ίδιο πρόβλημα εμφανίζεται σε contact IDs, campaign IDs, audience IDs και ad accounts. Ένας agent μπορεί να δημιουργήσει σωστό κείμενο και να το εφαρμόσει σε λάθος campaign. Περιορισμένα scopes, staging changes, diff πριν από mutation και approval από campaign owner μειώνουν τον κίνδυνο. Το tenant ή ο λογαριασμός διαφήμισης δεν πρέπει να επιλέγεται αποκλειστικά από ελεύθερο text.
Στο customer support με AI agents, το conversation handle πρέπει να διαχωρίζεται από την customer identity. Η ύπαρξη ticket ID δεν δίνει αυτομάτως πρόσβαση σε billing ή προσωπικά δεδομένα. Η υπηρεσία μπορεί να επιστρέφει masked reference και σαφή allowed actions, ενώ escalation σε άνθρωπο ενεργοποιείται όταν ο στόχος αλλάζει, η ταυτότητα δεν επιβεβαιώνεται ή το αίτημα έχει οικονομικό αποτέλεσμα.
Σε coding και back-office workflows, branch, pull request, document και invoice IDs χρειάζονται version checks. Αν το αντικείμενο άλλαξε μετά το τελευταίο tool result, η εφαρμογή πρέπει να ζητήσει refresh αντί να εφαρμόσει stale mutation. Η stateless μεταφορά διευκολύνει το retry· δεν δικαιολογεί blind write πάνω σε παλιά έκδοση.
Ξεκινήστε με ένα χαμηλού ρίσκου read-only use case και καταγράψτε ποιο state πρέπει πραγματικά να επιβιώνει μεταξύ κλήσεων. Για κάθε handle ορίστε issuer, object type, owner context, TTL, επιτρεπόμενες πράξεις και τρόπο ανάκλησης. Αν δεν μπορείτε να περιγράψετε αυτά τα στοιχεία, η ροή πιθανότατα κρύβει session state μέσα σε ένα ασαφές string.
Στη συνέχεια δοκιμάστε τη ροή με το πραγματικό μοντέλο και διαφορετικά turn depths. Εισάγετε λάθος αλλά έγκυρα IDs, expired handles, cross-tenant values, retries μετά από timeout και παράλληλα tasks. Το σύστημα πρέπει να απορρίπτει ασφαλώς, να μην αποκαλύπτει αν υπάρχει ξένο αντικείμενο και να καταγράφει policy decision που μπορεί να ελεγχθεί.
Έξι βήματα για production-ready stateless MCP
Καταγράψτε καλάθια, tasks, documents και άλλα αντικείμενα που πρέπει να συνεχίζουν μεταξύ tool calls, μαζί με την πηγή αλήθειας τους.
Ορίστε ποιο tool εκδίδει κάθε handle, πού χρησιμοποιείται, πότε λήγει και ποια ασφαλή στοιχεία επιβεβαίωσης επιστρέφονται.
Ελέγξτε object-level access σε κάθε request και παράγετε tenant context server-side αντί να εμπιστεύεστε model-supplied metadata.
Χρησιμοποιήστε idempotency keys, version checks και αποθηκευμένο αποτέλεσμα ώστε timeout ή retry να μη δημιουργεί δεύτερη χρέωση ή εγγραφή.
Συμπεριλάβετε compaction, restart, πολλά handles, αλλαγή μοντέλου, expired IDs, cross-tenant attempts και λάθος αλλά υπαρκτούς στόχους.
Για οικονομικές, δημόσιες ή μη αναστρέψιμες πράξεις, εμφανίστε τον ακριβή στόχο, ζητήστε έγκριση και αποθηκεύστε πλήρες policy trail.
Η μετάβαση σε sessionless MCP δεν είναι λόγος να αποφεύγονται οι agents. Είναι ευκαιρία να γίνει η συνέχεια ορατή και ελέγξιμη. Όπως και σε μια επιχειρηματική πλατφόρμα που περνά από prototype σε production, η αξία εμφανίζεται όταν η ευκολία ανάπτυξης συνοδεύεται από identity, policy, observability και rollback.
Το τελικό κριτήριο δεν είναι αν το μοντέλο θυμήθηκε το handle στα tests. Είναι αν η εφαρμογή παραμένει ασφαλής όταν το μοντέλο το ξεχάσει, το επαναλάβει ή επιλέξει άλλο. Το stateless MCP μεταφέρει τη συνέχεια σε ρητά arguments· η εμπιστοσύνη πρέπει να παραμένει στις υπηρεσίες που μπορούν να την αποδείξουν και να την επιβάλουν.
Από MCP prototype σε ασφαλές workflow
Η TWO DOTS χαρτογραφεί agentic ροές, συνδέει εφαρμογές και APIs και ορίζει authorization, idempotency, observability και ανθρώπινα approval gates για κάθε κρίσιμη ενέργεια.
Συχνές ερωτήσεις
Στην έκδοση 2026-07-28 κάθε protocol request είναι αυτοτελές και δεν χρησιμοποιεί initialize handshake ή Mcp-Session-Id. Η εφαρμογή μπορεί ακόμη να διατηρεί state μέσω δικών της πόρων και explicit handles.
Είναι ένα ordinary tool argument, όπως basket_id ή task_id, που εκδίδει ο server και το μοντέλο περνά σε επόμενες κλήσεις για να κατονομάσει το σωστό application object.
Όχι. Ο server πρέπει να ελέγχει handle, verified identity, tenant και επιτρεπόμενη ενέργεια σε κάθε κλήση. Η κατοχή ή η γνώση ενός ID δεν είναι authorization.
Επειδή οποιοδήποτε συμβατό server instance μπορεί να χειριστεί το request χωρίς sticky routing ή κοινό protocol session store, εφόσον τα application data παραμένουν σε ανθεκτική κοινή υπηρεσία.
Όχι. Το 39% αφορά έξι generation tasks με sharded instructions σε simulated conversations. Η μελέτη δεν δοκίμασε MCP handles και δεν αποτελεί production failure rate.
Με idempotency key δεμένο στην επιχειρησιακή πρόθεση και αποθηκευμένο αποτέλεσμα. Το ίδιο αίτημα επιστρέφει το προηγούμενο αποτέλεσμα αντί να εκτελεί ξανά τη mutation.
Conversation, model και έκδοση, caller identity, tool, masked handle, idempotency key, policy decision, version του αντικειμένου και downstream αποτέλεσμα, χωρίς secrets ή περιττά προσωπικά δεδομένα.
Πριν από οικονομική, δημόσια, νομικά ευαίσθητη ή μη αναστρέψιμη πράξη, καθώς και όταν αλλάζει στόχος, λείπει identity proof ή υπάρχει ασυμφωνία ανάμεσα στο handle και την πρόθεση.
Πηγές
