Model Context Protocol (MCP) ഇപ്പോൾ stateless ആയി മാറി. ഈ മാറ്റം വഴി ഡെവലപ്പർമാർക്ക് Cloudflare Workers-ന്റെ ഫ്രീ ടിയറിൽ (free tier) ചെറിയ MCP സെർവറുകൾ പ്രവർത്തിപ്പിക്കാൻ സാധിക്കും—എന്നാൽ ഓരോ റിക്വസ്റ്റും പ്ലാറ്റ്‌ഫോമിന്റെ 10 ms CPU പരിധിക്കുള്ളിൽ നിൽക്കണം എന്നത് പ്രധാനമാണ്.

ഈ മാറ്റം പ്രധാനമാകുന്നത് എന്തുകൊണ്ട്

രണ്ട് സമീപകാല മാറ്റങ്ങളാണ് ഇതിന് വഴിയൊരുക്കിയത്. ഒന്നാമതായി, MCP കോർ അതിന്റെ session-based ഡിസൈൻ ഉപേക്ഷിക്കുകയും ഇപ്പോൾ handshakes ഇല്ലാതെ പ്രവർത്തിക്കുകയും ചെയ്യുന്നു; കോഡിന്റെ ഏത് ഇൻസ്റ്റൻസിനും (instance) ഏത് റിക്വസ്റ്റും കൈകാര്യം ചെയ്യാൻ കഴിയും. രണ്ടാമതായി, Cloudflare തങ്ങളുടെ McpAgent ക്ലാസ് ഒഴിവാക്കി, പുതിയ സെർവറുകൾക്കായി പ്ലെയിൻ റിക്വസ്റ്റ് ഹാൻഡ്‌ലറുകൾ (plain request handlers) ഉപയോഗിക്കാൻ നിർദ്ദേശിക്കുന്നു. ഇവ രണ്ടും ചേർന്ന് Durable Objects അല്ലെങ്കിൽ മറ്റ് stateful സ്റ്റോറേജ് ആവശ്യങ്ങൾ ഇല്ലാതാക്കുന്നു, ഇവയായിരുന്നു ഫ്രീ പ്ലാനിൽ MCP പ്രവർത്തിപ്പിക്കുന്നതിനുള്ള പ്രധാന തടസ്സങ്ങൾ.

ഫ്രീ ടിയറിൽ യഥാർത്ഥത്തിൽ എന്തൊക്കെ ചെയ്യാൻ കഴിയും

ഒരു സ്റ്റാറ്റിക് സൈറ്റിൽ നിന്നുള്ള Markdown ഫയലുകൾ നൽകുന്ന ഒരു read-only MCP സെർവർ ഞങ്ങൾ നിർമ്മിച്ചു. മെത്തേഡുകൾ റൂട്ട് ചെയ്യുന്നതിനായി ഒരു ലളിതമായ switch statement ഉപയോഗിച്ച് list_articles, get_article എന്നീ രണ്ട് ടൂളുകൾ ഈ സെർവർ നടപ്പിലാക്കുന്നു. കഠിനമായ കണക്കുകൂട്ടലുകളില്ല, സ്റ്റാറ്റിക് അസറ്റുകൾ (static assets) ഫെച്ച് ചെയ്യുക മാത്രമാണ് ചെയ്യുന്നത്.

Cloudflare-ന്റെ CPU കണക്കാക്കുന്ന രീതി മൊത്തത്തിലുള്ള റെസ്പോൺസ് ടൈമിൽ (total response time) നിന്നും വ്യത്യസ്തമാണ്. നിങ്ങളുടെ JavaScript പ്രവർത്തിപ്പിക്കാൻ ചെലവഴിക്കുന്ന സൈക്കിളുകൾ മാത്രമേ CPU ടൈമിൽ കണക്കാക്കൂ; നെറ്റ്‌വർക്ക് കോളുകൾക്കോ ഡിസ്ക് റീഡിംഗിനോ വേണ്ടി കാത്തുനിൽക്കുന്ന സമയം ഇതിൽ ഉൾപ്പെടുത്തില്ല. ഈ വ്യത്യാസം വളരെ പ്രധാനമാണ്, കാരണം ഫ്രീ ടിയറിൽ ഓരോ റിക്വസ്റ്റിനും CPU പരിധി 10 ms ആണ്, എന്നാൽ മൊത്തത്തിലുള്ള ലേറ്റൻസി (latency) ഇതിലും കൂടുതലായിരിക്കാം.

ഫ്രീ ടിയറിലെ ഞങ്ങളുടെ അളവുകൾ ഇപ്രകാരമാണ്:

  • server/discover: 0-1 ms CPU
  • tools/list: 0 ms CPU
  • get_article (largest file): 1-2 ms CPU

ഏറ്റവും വലിയ ലേഖനം പോലും 10 ms ബജറ്റിന്റെ ഒരു ചെറിയ ഭാഗം മാത്രമേ ഉപയോഗിച്ചുള്ളൂ. ക്ലയന്റ് സൈഡിൽ കണ്ട സാവധാനത്തിലുള്ള പ്രവർത്തനം ഫയൽ വായിക്കാൻ കാത്തുനിൽക്കുന്നത് മൂലമാണ്, കോഡ് പ്രവർത്തിക്കുന്നത് മൂലമല്ല.

പരിധി എവിടെയാണ് തടസ്സമാകുന്നത്

ഡാറ്റ വ്യക്തമായ ഒരു പാറ്റേൺ കാണിക്കുന്നു:

  • ഡാറ്റ നൽകുന്ന ടൂളുകൾ (ലളിതമായ റീഡുകൾ, ലിസ്റ്റിംഗുകൾ) സുഖമായി പരിധിക്കുള്ളിൽ നിൽക്കുന്നു.
  • കമ്പ്യൂട്ട്-ഹെവി ടൂളുകൾ (parsing, rendering, hashing, അല്ലെങ്കിൽ ഏതെങ്കിലും അൽഗോരിതമിക് ജോലികൾ) 10 ms ബജറ്റ് വേഗത്തിൽ തീർക്കാൻ സാധ്യതയുണ്ട്.

ഒരു ടൂളിന് ചെറിയ പ്രോസസ്സിംഗിനേക്കാൾ കൂടുതൽ ആവശ്യമുണ്ടെങ്കിൽ, ഡെവലപ്പർമാർക്ക് പെയ്ഡ് Workers പ്ലാനിലേക്ക് മാറേണ്ടി വരും. $5 പ്ലാൻ റിക്വസ്റ്റ് പരിധി 30 സെക്കൻഡിലേക്ക് ഉയർത്തുന്നു.

ആർക്കാണ് നേട്ടം, ആർക്കാണ് സമയം ശ്രദ്ധിക്കേണ്ടത്

നിലവിൽ Markdown ഫയലുകളോ RSS ഫീഡോ ഹോസ്റ്റ് ചെയ്യുന്ന ചെറിയ സൈറ്റുകൾക്ക് ഒരു പുതിയ റൂട്ട് വഴി ഒരു MCP എൻഡ്പോയിന്റ് (endpoint) നൽകാനും ഫ്രീ പ്ലാനിൽ തന്നെ തുടരാനും സാധിക്കും. ഇത് ഹോബിസ്റ്റുകൾക്കും (hobbyists), ഡോക്യുമെന്റേഷൻ സൈറ്റുകൾക്കും, കുറഞ്ഞ ട്രാഫിക് ഉള്ള ബ്ലോഗുകൾക്കും കുറഞ്ഞ പ്രവർത്തനച്ചെലവും ലളിതമായ സംവിധാനവും നൽകുന്നു.

ഒരു ടൂളിന് ചെറിയ പ്രോസസ്സിംഗിനേക്കാൾ കൂടുതൽ ആവശ്യമുണ്ടെങ്കിൽ, ഡെവലപ്പർമാർക്ക് പെയ്ഡ് Workers പ്ലാനിലേക്ക് മാറേണ്ടി വരും.

ലോഞ്ച് ചെയ്യുന്നതിന് മുമ്പ് എന്തൊക്കെ പരിശോധിക്കണം

  • നിങ്ങളുടെ ടൂൾ പ്രൊഫൈൽ ചെയ്യുക: കുറച്ച് റിക്വസ്റ്റുകൾ റൺ ചെയ്ത് Cloudflare ഡാഷ്‌ബോർഡിലെ CPU മീറ്റർ പരിശോധിക്കുക.
  • സ്റ്റാറ്റിക്, ഡൈനാമിക് പാത്തുകൾ വേർതിരിക്കുക: സ്റ്റാറ്റിക് ഫയൽ സർവിംഗ് ഫ്രീ ടിയറിൽ നിലനിർത്തുക, കമ്പ്യൂട്ട്-ഇന്റൻസീവ് കോളുകൾ പെയ്ഡ് വർക്കറിലേക്കോ മറ്റൊരു ബാക്കെൻഡിലേക്കോ റൂട്ട് ചെയ്യുക.
  • മറഞ്ഞിരിക്കുന്ന ലേറ്റൻസി ശ്രദ്ധിക്കുക: നെറ്റ്‌വർക്ക് കാത്തിരിപ്പ് സമയം CPU പരിധിയിൽ കണക്കാക്കില്ലെങ്കിലും അത് ഉപയോക്താവിന്റെ അനുഭവത്തെ ബാധിക്കും. നിങ്ങൾ നൽകുന്ന ഫയലുകൾക്കായി എഡ്ജ് കാഷിംഗ് (edge caching) പരിഗണിക്കുക.

ഒരു വിയോജിപ്പ്: ഫ്രീ പ്ലാൻ പരിധിയില്ലാത്തതല്ല

Stateless കോർ വന്നതോടെ Durable Objects-ന്റെ ആവശ്യം ഇല്ലാതായെങ്കിലും, 10 ms എന്ന പരിധി ഇപ്പോഴും നിലനിൽക്കുന്നു. ചെറിയ രീതിയിലുള്ള പാഴ്സിംഗിന്റെ (ഉദാഹരണത്തിന്, markdown to HTML കൺവേർഷൻ) ചിലവ് കുറവാണെന്ന് കരുതി അവഗണിക്കുന്ന ഡെവലപ്പർമാർക്ക് അപ്രതീക്ഷിതമായി ഈ പരിധിയിൽ തടസ്സമുണ്ടാകാം. ഫ്രീ ടിയർ "serve-as-is" (ലഭ്യമായത് പോലെ നൽകുക) സാഹചര്യങ്ങൾക്ക് അനുയോജ്യമാണ്, അല്ലാതെ തത്സമയ ഉള്ളടക്ക നിർമ്മാണത്തിന് (on-the-fly content generation) അല്ല.

Cloudflare-ൽ MCP-യുടെ ഭാവി എന്താണ്

നിങ്ങളുടെ സൈറ്റിലെ ഉള്ളടക്കം നിലവിൽ ഒരു സ്റ്റാറ്റിക് ബക്കറ്റിൽ (static bucket) ഉണ്ടെങ്കിൽ, ഏതാനും വരി കോഡിലൂടെയും ഒരു റൂട്ട് വഴിയും ഒരു MCP എൻഡ്പോയിന്റ് ചേർക്കുന്നത് വളരെ ലളിതമാണ്. 10 ms CPU പരിധിക്കുള്ളിൽ നിൽക്കുന്നിടത്തോളം കാലം, സൗജന്യമായി ഹോസ്റ്റ് ചെയ്യാവുന്ന ഒരു പ്ലെയിൻ HTTP എൻഡ്പോയിന്റ് എന്ന നിലയിൽ ചെറിയ സെർവറുകളുടെ ആവശ്യങ്ങളുമായി ഈ പ്രോട്ടോക്കോൾ ഇപ്പോൾ പൊരുത്തപ്പെടുന്നു.