تصور کنید سازمان شما هنوز بر پایه یک سیستم حقوق و دستمزد حیاتی یا یک سیستم برنامهریزی منابع سازمانی (ERP) از سال ۱۹۹۸ میچرخد که هیچکس از کارکنان فعلی، منطق داخلی آن را بهطور کامل نمیفهمد. این کابوس مدیریتی اکنون راه حلی دارد؛ در ۲۲ اوت ۲۰۲۶، ابزار Oracle Forms MCP منتشر شد تا دستیاران هوشمند بتوانند بدون نیاز به نرمافزار اصلی Forms Builder، این ماژولهای باینری قدیمی را بخوانند و نمایهسازی کنند.
بسیاری از نرمافزارهای سازمانی قدیمی در فایلهای باینری با پسوند .fmb و .pll ذخیره شدهاند. این فرمتها برای مدل زبانی بزرگ (LLM) — که شبیه کتابخانهداری است که میلیاردها صفحه را خوانده و حالا با همان لحن جواب میدهد — کاملاً نامفهوم هستند، زیرا مدلها معمولاً فقط کدهای متنی مثل Kotlin یا Python را میفهمند. به دلیل بازنشستگی توسعهدهندگان اولیه، این سیستمها به «جعبههای سیاه» تبدیل شدهاند که تغییر آنها ریسک بالایی دارد و مستندسازی دستیشان بیش از حد پیچیده است. طبق گزارشهای فنی، این یک مشکل «ورودی» است، نه نقص در قدرت مدل.
به نقل از گزارش فنی منتشر شده در dev.to، سرور Oracle Forms MCP به عنوان یک لایه ترجمه عمل میکند. این سرور یک عامل (Agent) را به دایرکتوری ماژولها هدایت کرده و آنها را به فرمت متنی ساختاریافته تبدیل میکند تا مدل بتواند روی آنها پرسوجو کند. به همین دلیل، یک توسعهدهنده میتواند از مدلی مثل Claude بپرسد: «فایل ORDERS.fmb چه کاری انجام میدهد؟» و تحلیل دقیقی از بلوکها، تریگرها و منطق PL/SQL دریافت کند. این رویکرد در راستای تلاشهای گستردهتر اوراکل برای ادغام هوش مصنوعی در فرآیندهای سازمانی است، مشابه آنچه در سادهسازی فرآیندهای تدارکات از طریق رابطهای چت هوشمند مشاهده کردیم.
همانطور که در تحلیلهای قبلی ما دربارهی چالشهای استخراج داده از سیستمهای میرا اشاره کردیم، تبدیل فرمتهای بسته به متن، کلیدیترین گام برای مدرنسازی است.
خط لوله تبدیل
این سرور وظیفه دشوار استخراج متن از فرمتهای اختصاصی را از طریق سه حالت اولویتبندی شده انجام میدهد:
- دستورات تعریفشده توسط کاربر: کاربران میتوانند یک دستور سفارشی
--convert-commandبرای محیطهای خاص ارائه دهند. - ORACLE_HOME: سرور به دنبال یک نصب محلی اوراکل میگردد تا مبدلهای بومی (native converters) را پیدا کند.
- حالت کپی (Copy-mode): استفاده از فایلهای XML از پیش تبدیلشده (مانند
orders_fmb.xmlیاutils.pld). این قابلیت اجازه میدهد ابزار در محیطهای Docker یا لپتاپهایی که هیچ نرمافزار اوراکلی نصب ندارند، اجرا شود.
این سامانه بر ابزارهای دهه ۹۰ مثل frmf2xml (برای فایلهای .fmb، .mmb و .olb) و frmcmp_batch (برای فایلهای .pll) تکیه دارد. بر اساس مستندات، این ابزارها اختصاصی هستند و نمیتوانند به صورت باندل شده توزیع شوند. همچنین این ابزارها به شدت ناپایدار هستند؛ برای مثال frmf2xml مسیر خروجی را نمیپذیرد و مستقیماً در دایرکتوری کاری (working directory) مینویسد، بنابراین سرور باید دایرکتوری خروجی را به عنوان مسیر جاری (cwd) تنظیم کند تا فایلها در جای درست ذخیره شوند.
از آنجا که کدهای خروجی (exit codes) این ابزارها غیرقابل اعتماد هستند، سرور موفقیت را بر اساس سه معیار میسنجد: وجود فایل خروجی، غیرخالی بودن آن و جدیدتر بودن زمان ایجاد فایل نسبت به زمان فراخوانی. این موضوع یک نتیجه جالب دارد: اسکریپتهای Wrapper که از cp -p برای کپی فایلهای از پیش تولید شده استفاده میکنند، توسط سرور رد میشوند، زیرا دستور -p زمان تغییر (mtime) منبع را حفظ میکند و سرور تصور میکند فایل جدیدی ایجاد نشده است.
خروجی XML حاصل، حجیم و به شدت وابسته به نسخه است. برای مدیریت این حجم، سرور از یک گذر تکمرحلهای StAX (Streaming API for XML) استفاده میکند با یک قانون سختگیرانه: پارسر هرگز در مواجهه با واژگان ناشناخته متوقف نمیشود. هر المانی که شناسایی نشود، به صورت کلی نادیده گرفته میشود. پارسری که با دیدن یک تگ ناآشنا متوقف شود، در برابر ۳۰ سال نسخههای مختلف Forms کاملاً بیفایده است.
سطح ابزار و هدایت مدل
برای جلوگیری از سردرگمی یا «دستوپا زدن» مدلها، سرور یک سطح ابزار منتخب شامل ۱۶ ابزار را پیادهسازی کرده است. اگرچه این تعداد بیشتر از لیستهای معمول است، اما این ابزارها در یک سطح نیستند. آنها از دو فعل اصلی list_* و get_* در یک فضای اسمی، به همراه یک لایه پنجتایی برای یادداشتگذاری تشکیل شدهاند. سرور صراحتاً به مدل دستور میدهد توالی ورود را رعایت کند: ابتدا list_modules $
ightarrow$ سپس fetch_module $
ightarrow$ بعد get_module_overview $
ightarrow$ و در نهایت بررسی جزئیات (drill down).
تمام ابزارهای خواندن دارای برچسبهای readOnlyHint = true و idempotentHint = true و همچنین destructiveHint = false و openWorldHint = false هستند تا به عنوان دامنهای بسته، محلی و بدون اثر جانبی (side-effect-free) شناخته شوند. این اعلانها به کلاینتهایی که بر اساس یادداشتها دسترسی را محدود یا تایید میکنند، کمک میکند.
برای مدیریت هزینههای استنتاج (Inference) — که شبیه کرایه یک آشپزخانه صنعتی است و هرچه دستور پخت سنگینتر باشد هزینه بیشتر میشود — محدودیتهای فنی زیر اعمال شده است:
- صفحهبندی (Pagination): ابزار
search_sourceبرای جلوگیری از پر شدن پنجره متنی (Context Window) — که مثل میز کاری است و فقط جای چند ورق دارد — ازoffsetوnextOffsetاستفاده میکند. - تغییر سطح جزئیات: ابزارهای لیست، آرگومان
verbosity(مختصر یا مفصل) میگیرند که مقدار پیشفرض آن روی «مختصر» (concise) است. - نمایهسازی جانبی (Sidecar Indexing): بدنه PL/SQL هرگز در
index.jsonقرار نمیگیرد. این کدها در فایلهای.sqlجانبی استخراج شده و از طریق محدوده خطوط (line range) به آنها ارجاع داده میشود. این کار تضمین میکند کهget_triggerدقیقاً یک بدنه را بخواند، به جای اینکه مدل برای یافتن یک تکه کد، هزینه پردازش یک مگابایت JSON را بپردازد.
هر ابزار یک outputSchema تعریف میکند و هم محتوای ساختاریافته مطابق با آن طرح و هم متن JSON زیبا (pretty JSON) را برای کلاینتهای فاقد پشتیبانی از خروجی ساختاریافته بازمیگرداند. همچنین یک ToolRegistrationTest در سیستم تعبیه شده که اگر هر ابزاری بدون عنوان، یادداشتها یا طرح (schema) ارسال شود، فرآیند Build را با خطا مواجه میکند.
مدیریت خطا و تعامل با مدل
در این سیستم، خطاها به عنوان «محتوا» تلقی میشوند، نه استثنا (Exception). شکستهای مورد انتظار — مثل آرگومان اشتباه، ماژولی که هنوز fetch نشده یا تبدیل ناموفق — به صورت نتایج isError بازگردانده میشوند. متن خطاها بهگونهای نوشته شده که عامل (Agent) بتواند روی آن واکنش نشان دهد؛ مثلاً بهجای نمایش یک Stack Trace فنی و نامفهوم، پیام «ماژول ORDERS قدیمی است، تابع fetch_module را فراخوانی کنید» ارسال میشود. این دقت در مدیریت تعاملات عامل با سیستم، پاسخی به چالشهای رایج در اتصال عاملهای کدنویسی به APIهاست که ابزارهایی مانند Scout سعی در رفع توهمات آنها دارند.
لایه یادداشتگذاری (Annotation)
یکی از مهمترین ویژگیها، توانایی مدل برای نوشتن در سیستم است. از آنجا که فرمهای قدیمی بهندرت در یک بار بررسی فهمیده میشوند، سرور ابزارهای annotate_element (برای یادداشت، تگها، خلاصهها و طبقهبندی) و relate_elements (برای ایجاد ارجاعات متقاطع جهتدار، مثلاً ذکر اینکه یک تریگر خاص، یک واحد برنامهای خاص را فراخوانی میکند) را فراهم کرده است.
این یادداشتها از سه قانون پایداری سختگیرانه پیروی میکنند:
۱. تأییدشده، نه استنتاجی: یادداشتها در ذخیرهساز مخصوص خود قرار دارند، نه در کشِ دارای اثر انگشت (fingerprinted cache). بنابراین حذف کش یا بازخوانی مجدد یک ماژول، یادداشتها را پاک نمیکند.
۲. کلیدگذاری بر اساس هویت، نه موقعیت: کلید هر یادداشت ترکیبی از ماژول، نوع، نام و مسیر مالک است. هرگز از محدوده خطوط استفاده نمیشود، بنابراین بازنمایهسازی (re-indexing) باعث جابهجایی یادداشت یک تریگر نمیشود.
۳. پرچمگذاری انحراف: اگر منبع پس از نوشتن یادداشت تغییر کند، یادداشت به عنوان staleAgainstSource علامتگذاری میشود. این کار مانع از آن میشود که استدلالهای یک همکار بهطور خاموش به دلیل ویرایش یک فایل حذف شود.
شکافهای پروتکل و SDK
این سرور با هسته Kotlin Multiplatform و یک سرور JVM تحت لایسنس Apache-2.0 ساخته شده است. با این حال، نویسنده به شکافی در اکوسیستم در رابطه با مشخصات ۲۸ جولای ۲۰۲۶ اشاره میکند. در این نسخه، هسته پروتکل به حالت بدون وضعیت (stateless) تغییر کرده و دستدادن (handshake) اولیه initialize/initialized و همچنین Mcp-Session-Id حذف شده است. اکنون درخواستها نسخه پروتکل و هویت کلاینت را در بخش _meta حمل میکنند.
تغییرات دیگر نسخه ۲۰۲۶-۰۷-۲۸ شامل موارد زیر است:
- MRTR: رفتارهای شروعشده توسط سرور جایگزین شدهاند؛ اکنون یک ابزار
input_requiredرا بازمیگرداند و کلاینت باinputResponsesتلاش مجدد میکند. - کشینگ: ابزار
tools/listقابلیتهایttlMsوcacheScopeرا به دست آورده است. - وظایف (Tasks): این بخش به یک افزونه رسمی به نام
io.modelcontextprotocol/tasksمنتقل شده است. - منسوخشدنها: قابلیتهای Roots، Sampling، Logging و انتقال قدیمی HTTP+SSE در یک بازه زمانی ۱۲ ماهه منسوخ میشوند.
در حال حاضر SDK کاتلین هنوز روی نسخه ۲۵-۱۱-۲۵ است، در حالی که SDKهای سطح اول (TypeScript, Python, Go, C#) نسخه ۲۰۲۶-۰۷-۲۸ را عرضه کردهاند. توسعهدهندگان کاتلین باید برای این شکاف برنامهریزی کنند. البته سرور از پیش برای هسته بدون وضعیت طراحی شده است، زیرا هر چیز پایداری روی دیسک قرار دارد و دارای اثر انگشت است.
یک جزئیات حیاتی در پیادهسازی مربوط به ارتباط stdio است. از آنجا که stdout کانال اصلی پروتکل است، هرگونه println اتفاقی یا خروجی لاگر میتواند جریان JSON-RPC را فاسد کرده و منجر به خطاهای Parse مرموز در سمت کلاینت شود. برای جلوگیری از این اتفاق، سرور تمام لاگها را از مسیر Kermit $
ightarrow$ SLF4J $
ightarrow$ Logback $
ightarrow$ stderr هدایت میکند.
این تحول، نگهداری سیستمهای میرا را از یک تمرین «جرمشناسی» به یک گفتگوی تعاملی تبدیل میکند. سازمانها اکنون میتوانند سیستمهایی را که سه دهه منجمد شده بودند، مدرنسازی کنند.
گام بعدی شما
- اگر از Claude Code استفاده میکنید، پلاگین را با دستور
/plugin marketplace add aoreshkov/oracle-forms-mcpاضافه کنید. - برای استقرار مستقل، از ایمیج GHCR پروژه استفاده کنید.
- برای تست خط لوله تبدیل، دستور
server --forms-dir sample-formsرا اجرا کنید. - برای کاربران Claude Desktop، یک باندل
.mcpbتککلیکی پشتیبانی میشود. این پروژه در MCP Registry با شناسهio.github.aoreshkov/oracle-forms-mcpثبت شده است.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو