Most organizations running decade-old SOAP services face the same problem: the systems of record that power their business are not going away, but the teams building AI agents need to connect to them. Legacy2mcp bridges that gap by turning a WSDL URL into a typed MCP server in minutes, without writing a single line of adapter code.
What it does with a WSDL
You point legacy2mcp at a WSDL endpoint. The tool introspects every operation on every port and binding, converts the XSD input types into JSON Schema, and registers one MCP tool per operation. Each tool is named with the adapter ID and operation name, so the mapping from WSDL to MCP is explicit and auditable.
The schema generation handles simple types, nested complex types, enums, and repeated elements as arrays, all converted recursively with depth limiting for pathological WSDLs. The resulting schemas are not hand-maintained. They are derived directly from the WSDL's own type definitions, so they cannot drift from what the service actually accepts.
When an MCP client calls one of these tools, legacy2mcp validates the arguments against the generated JSON Schema before making any network call. The validation uses additionalProperties set to false, so unexpected arguments fail immediately rather than reaching the SOAP endpoint. The response is serialized back to plain JSON for the client.
Safety by default
The tool ships with a safe-by-default posture. Operations whose names look like writes, Create, Update, Delete, Cancel, Submit, Pay, and similar patterns, are excluded unless you explicitly set allow_write_operations to true. On top of that heuristic, you can define include_operations and exclude_operations lists to control exactly which operations the agent may call.
Every call is audit-logged as a single JSON line containing the tool name, arguments, timestamp, and outcome. The log gives you a record of exactly what the agent did, which matters for compliance and debugging. Secrets like passwords are read from named environment variables and never written into configuration files.
The security model is documented honestly in the project's security documentation, covering what is protected today and what is not yet addressed. That transparency is unusual for tools in this space and worth noting for teams evaluating the risk of exposing legacy systems to AI agents.
Why this matters for legacy systems
Organizations running 10 to 20 year old SOAP services have systems of record, middleware, back-office platforms, and line-of-business applications that are not going away. These systems contain the data and workflows that the business depends on. Teams building AI agents need to access that data, but the traditional approach, hand-writing a bespoke adapter for each WSDL, is slow, error-prone, and produces schemas that immediately start drifting from the service.
Legacy2mcp eliminates that problem by generating the adapter from the WSDL itself. The tool schema is derived from the service definition, not hand-copied from documentation. When the backend team changes an operation's contract, the next generation of MCP tools reflects that change. You can catch regressions by diffing the generated tools against a committed snapshot in CI.
Use cases include letting an agent read status and detail records from a legacy back-office platform, exposing account and transaction reads from a financial services system without exposing transfers, surfacing order status and inventory from an old SOAP middleware layer, and giving a support copilot safe typed access to the system of record instead of scraping a UI.
CI integration and the inspect command
The inspect command loads the config, contacts the WSDL, builds every tool schema, and exits non-zero if anything fails. Run it as a pipeline gate to verify that the WSDL still generates valid MCP tools. If the backend team changes an operation's contract, the pipeline catches it before it reaches production.
A GitHub Actions workflow example shows how to run inspect, save the output as JSON, and diff it against a committed snapshot. The pipeline fails if the generated tools differ from the snapshot, which means contract changes are caught at the pull request stage, not when an agent tries to call a nonexistent operation.
The tool is available on PyPI and the MCP Registry. Installation is a single pip command, and the project includes a Dockerfile for packaging with your config. The MCP server speaks over stdio, which is the transport that Claude Desktop and most agent frameworks use to spawn servers.
What is on the roadmap
The SOAP/WSDL adapter is implemented and tested, with a test suite that runs against an in-process mock service without needing network access. A database adapter with parameterized queries, table allowlists, and operation allowlists is planned, as is a queue adapter for Kafka, RabbitMQ, and SQS. The BaseAdapter interface is the extension point for building new adapters, and contributions are welcome.
For teams with legacy systems that need to become accessible to AI agents, legacy2mcp provides a concrete path forward. Point it at the WSDL, review the generated tools, and start calling them from any MCP client. The schemas are derived from the service definition, the calls are validated and logged, and the write operations are excluded by default. It is a narrow tool for a specific problem, and it does that problem well.