Issues fixed in OpenEdge MCP Server 1.1

In OpenEdge MCP Server 1.0.0, running mcpgen <command> --help (for example, mcpgen restart --help) displayed an unexpected -c in the usage line in place of the utility name (for example, usage: -c restart [-h] [--no-smoke] [name]). This made -c look like a required parameter, which was misleading. The issue affected the help output for all mcpgen subcommands.

This issue has been resolved in MCP Server 1.1.0. The usage line for mcpgen subcommands now correctly displays mcpgen as the program name (for example, usage: mcpgen restart [-h] [--no-smoke] [name]), and the program name is shown consistently across the help output on all supported platforms.

Affected Version: MCP Server 1.0.0

Fixed Version: MCP Server 1.1.0

In OpenEdge MCP Server 1.0.0, the help output displayed by mcpgen --help used the header "Flags" to list command parameters. This was inconsistent with the terminology used elsewhere in the mcpgen utility help, which refers to these parameters as "Options."

This issue has been resolved in MCP Server 1.1.0. The mcpgen --help output now uses the header "Options" (with a capital "O"). The only change is to the heading text. The available options and how they work are unchanged.

Affected Version: MCP Server 1.0.0

Fixed Version: MCP Server 1.1.0

The mcpgen client command now supports file-based argument input via the new --args-file option. Users can specify a file path containing the JSON payload as an alternative to providing it inline with the --args argument. A shortcut syntax --args @file is also supported and is equivalent to --args-file. This enhancement improves cross-platform compatibility, particularly on Windows where passing inline JSON through --args can be problematic.

In OpenEdge MCP Server 1.0.0, the --json option for the mcpgen client command was missing from the mcpgen --help and mcpgen --help-all output, although it was listed in mcpgen client --help.

This issue has been resolved in MCP Server 1.1.0. The --json option is now listed for the client command in all help output, and the client option descriptions are consistent across mcpgen --help, mcpgen --help-all, and mcpgen client --help.

In OpenEdge MCP Server 1.0.0, mcpgen openapi-gen failed with a "Catalog file not found" error when the catalog file was specified with a relative path (for example, .\SportsService.json); only absolute paths worked. Relative paths passed to mcpgen update (--spec, --prompts, and --context) were affected in the same way.

This issue has been resolved in MCP Server 1.1.0. Relative paths are now resolved from the directory where you run mcpgen. Absolute paths and URLs continue to work as before.

In OpenEdge MCP Server 1.0.0, when mcpgen openapi-gen was run against the static catalog file of an OpenEdge Data Service that uses WEB transport (for example, http://host:8810/Sports/static/SportsService.json), the generated OpenAPI spec used the static catalog URL as the server url. As a result, the MCP server could not reach the service.

This issue has been resolved in MCP Server 1.1.0. The generated OpenAPI spec now uses the service endpoint (for example, http://host:8810/Sports/web/pdo/SportsService) as the server url.

An issue was identified in the OpenEdge MCP Server where the DELETE operation did not function correctly when OpenEdge Business Entities passed a body with the request. This caused invalid OpenAPI Specification generation and failures in downstream API calls, as the required Content-Type headers were not being set properly.

This issue has been resolved in MCP Server 1.1.0. The DELETE operation now correctly handles body, path, and query parameters, sets the appropriate Content-Type headers, and generates a valid OpenAPI Specification.

When running OpenEdge Business Entity services locally, the OpenEdge MCP Server was unable to automatically invoke those local services. Because the MCP Server runs inside Docker, references to "localhost" in the OpenAPI Specification pointed to the Docker container's localhost rather than the host machine, requiring users to manually configure network settings to connect.
This issue has been resolved in MCP Server 1.1.0. The generated docker-compose.mcp.yml now includes a commented-out extra_hosts block (marked as "DEVELOPMENT ONLY") that allows developers to optionally map a stable hostname (data.service) to the host machine's IP address, enabling the MCP container to reach services running outside of Docker. This mapping is automatically removed from production export bundles to avoid any security exposure.

The OpenEdge MCP Server's OpenAPI specification generator was not preserving the hierarchical schema structure for external Business Entity objects. Dataset and temp-table levels (e.g., dsBin → ttBin) were being flattened out, removing the nested hierarchy. This caused MCP Tool Schema failures when performing POST, PUT, or DELETE operations because the expected request body structure did not match the OpenEdge Data Object Service requirements.

This issue has been resolved in MCP Server 1.1.0. The OpenAPI specification generator now correctly produces the nested hierarchy (dataset and temp-table levels) in the request body schemas for POST and PUT operations, enabling successful CRUD operations against OpenEdge Data Services.

Several example JSON configuration files included in the OpenEdge MCP Server distribution contained syntax errors that could cause issues when used as templates for configuration. The affected files were:

• mcp_server_config.jwks.example.json
• mcp_server_config.oauth_sso.example.json
• mcp_server_config.routes.include-write.example.json
• mcp_server_config.verbose.json

This issue has been resolved in MCP Server 1.1.0. All example JSON configuration files in the examples/ directory now contain valid JSON syntax.

In the OpenEdge MCP Server distribution package, the IMAGES_MANIFEST.txt file incorrectly indicated that no images were included, displaying "(no images)" despite the images directory containing two container image files.

This issue has been resolved in MCP Server 1.1.0. The IMAGES_MANIFEST.txt file now correctly lists all container images included in the distribution package.