FWD » Core Development » Conversion Tools

For some time now, I've been expecting that we would write some kind of plugin to integrate with popular gen AI environments. For example, ChatGPT has a plugin design that can be implemented.

The problem (until recently) is that each gen AI service had its own integration model. In fall of 2024, Anthropic (makers of Claude) created an open standard called Model Context Protocol (see also What is the Model Context Protocol? from the official site). The core idea is that you can implement an "MCP Server" which is a process that listens on a socket and implements the MCP protocol. The protocol itself is patterned after the LSP (language server protocol) and the lower level transport protocol is JSON-RPC. The server can be implemented in any language (we will use Java).

The gen AI service can then call the MCP server to tell it about a prompt and the server will then respond with context that would help the gen AI answer that prompt.

I understand that OpenAI (i.e. ChatGPT et al) and Google (i.e. Gemini) will both be using MCP as well. It looks like it may become a widely used standard. If so, it is likely the best choice for this integration.

At the recent PUG in Boston, Progress was heavily pitching their work with MCP (not available yet). One thing that was interesting and looks promising is that they are working on an MCP server for code assist. Many IDEs (e.g. Cursor, Windsurf...) now have explicit integration with code assist agents that are backed by one of the LLM gen AIs. Many of these IDEs allow choosing which gen AI agent you use. The agent then has access to the source code of your project (some agents remember stuff and some don't, there are intellectual property/confidentiality/functionality pros and cons here). With that code access AND with the ability to expand context by connecting an MCP server (or more than one in a chained fashion), you can upgrade the code assist agent and make it more likely to succeed in dealing with your prompt.

The PSC approach was to migrate their 4GL language and OE documentation into markdown format and somehow feed that back via MCP. They also incorporate some 4GL programming best practices as statements in markdown. It is not clear how they process the prompt to determine what context to provide. I think that is the tricky part which we will have to develop.

We will need our own independently written version of 4GL language docs. By independently, I mean that we MUST NOT copy content from the OE docs. We are going to need this for our own IDE hover help anyway, so we should choose an approach where the same content can be used in both places. For that matter, we probably should surface this as 4GL language docs in our website/Redmine so that people don't have to refer to OE docs. A lot of this content already exists in our javadoc.

In addition to the 4GL language help, I think we have a great deal of potential in providing the ability to:

• integrate with AST processing/analysis/search/reports
  • analytics search or reports capabilities
  • accessing details calculated and stored in the ASTs like buffer scopes or indexes used
• answering questions like what would the Java code look like for a given 4GL input (conversion on the fly)
• answering questions about the converted code
  • why is the code implemented a certain way
  • what was the 4GL code/schema that the code came from
• answering questions about the FWD runtime
• project setup
  • take a set of artifacts from an existing 4GL app that compiles and runs in OE and turn it into a working project in FWD
  • will need to prompt for things that are missing but are required or are determined to be needed
  • 2 very different targets, both need to be handled
    • conversion
    • runtime

We should brainstorm other ideas here.