For manufacturers and distributors running Canias ERP

A Canias ERP MCP server that answers through TROIA web services under each user's own rights

A Canias ERP MCP server gives Claude, ChatGPT or Copilot read-first tools for production orders, materials and sales orders. Canias exposes TROIA Web Services 2.0, a session-based SOAP interface where each object is a TROIA service. IAS ships no MCP server as of 21 September 2026, so Pexon builds one against your installation.

Why Canias ERP is hard for agents

Where a Canias ERP connection needs engineering, not configuration

01 · Protocol

SOAP sessions and XML strings

The web service is SOAP only and session-based, with parameters passed as XML strings and passwords hashed with MD5. An MCP server has to handle login, logout, session expiry and the XML conversion before any tool answers a question.

02 · Objects

No fixed business-object API

Every object needs a TROIA service written and registered, with its own user rights. Because customers change the source code, services differ per installation. The first tools are usually new TROIA services, agreed in the blueprint.

03 · Docs

Dated tooling, unclear documentation owner

IAS's Java connector was last updated in 2016. The TROIA web service reference sits on a readthedocs site that is not clearly published by IAS. Every detail is checked against your application server before a tool is built.

04 · Ownership

Who owns your TROIA code

Customers in DACH may be served through partners, and many have their own TROIA changes. Before new services are written, it has to be clear who owns and maintains the TROIA codebase on your system.

Checked 21 September 2026

Canias ERP at a glance: interfaces, access and what exists for AI

	What we found
Interfaces	TROIA Web Services 2.0 (CaniasWebService, module WSR) (SOAP, docs public): four methods: login, logout, callService and listServices; each service is a TROIA class method registered as a web service; Web Service 1.0 is deprecated and no REST API is documented · TROIA platform (4GL on the ERP database, docs public): customers get the source code; new services are written in TROIA without a restart, which is the normal way to expose a new object
Authentication	Session-based: login takes client, language, database and application server, user name and an MD5-hashed password, and returns a session ID and security key that every callService needs. User rights are set per service.
Vendor MCP server	No vendor server. No IAS or Canias MCP server, and nothing for Canias or TROIA in GitHub or the MCP directories; IAS publishes SOAP web services only.
Vendor AI assistant	None found.
Other connectors	IAS's own Java connector for Web Service 2.0 is on GitHub, last updated in 2016; no AI or MCP connector exists.

IAS Industrial Application Software (IAS Bilgi Islem A.S.) (TR). Mid-sized manufacturers and distributors that want to customise the ERP at source level; IAS states more than 1,400 customers and 70,000 users in 32 countries, with offices in Germany, Turkey, South Korea, Switzerland and the US.

What we build

A first Canias ERP tool list, written as the manifest your IT team signs

Built on what IAS Industrial Application Software (IAS Bilgi Islem A.S.) documents: any TROIA service registered as a web service in your installation, the list of services the user may call. Backends named below are documented resources; "confirmed in blueprint" means the vendor documentation sits behind a login and the resource is checked against your release first.

# canias-erp-mcp-server: tool manifest, draft for blueprint week 1
# Every tool runs as the person asking. Nothing is written without a person confirming.
tools:
  list_services:         # session -> TROIA web services this user may call
    backend: CaniasWebService listServices()
    mode: read
  call_troia_service:    # service ID and parameters -> XML result, administrators only
    backend: CaniasWebService callService()
    mode: read
  get_production_orders: # date range, status -> production orders
    backend: custom TROIA service, confirmed in blueprint
    mode: read
  get_material:          # material number -> master data
    backend: custom TROIA service, confirmed in blueprint
    mode: read
  draft_sales_order:     # customer, items -> order draft a person confirms
    backend: custom TROIA service, confirmed in blueprint
    mode: propose
audit: every call logged with user, tool, arguments and the Canias ERP response

The manifest is the contract. A question that needs an operation not on it gets a new line and a review, not a wider permission.

Canias ERP holds the records. An assistant without a governed way in answers from whatever someone pasted into the chat. The connector is the governed way in: named operations, the person's own permissions, every call logged.

What the connector answers, and what it will not do

Questions it answers

Which production orders were released this week, and what is their status?
Has sales order X been transferred into Canias, and with which positions?
Does material Y exist, and what are its master data?

What it will not do

Create an order by itself: the only write tool drafts a sales order and a person confirms it in Canias.
Read more than the asking user may read; per-service user rights in Canias decide every call.
Call arbitrary TROIA services for normal users: the generic service call is limited to administrators.

When this is the wrong page

If you need a reporting layer across years of Canias data, a warehouse fed from the database is the better path. A connector is right when an assistant in Claude, ChatGPT or Copilot needs live answers from Canias under each user's own rights.

Start with the Readiness Blueprint.

Two weeks, €4,900 fixed price. Week one agrees the tool list with your Canias ERP owners and checks every backend against your release and licence. Week two tests whether a person's own Canias ERP permissions reach through the connector. You keep the manifest and a costed build plan, whoever builds it. All prices are net and exclude VAT.

What we need from you: a named Canias ERP administrator, a test or sandbox system we may call, and one business owner who can say which questions the assistant should answer first. The first production connector is usually a use-case pilot from €15,000; it runs in your environment, and the code is yours.

Sources: Programming with TROIA: Web Services · troia-webservice-connector (GitHub) · Canias development (TROIA) · Canias WSR module · About Canias. Read 21 September 2026. Vendor documentation changes; verify against the current release.

Connectors for 100 source systems — the dated catalogue this page belongs to
Claude MCP server development — how we build an MCP server for any internal system

Questions Canias ERP teams ask before the first tool call

Does Canias ERP have its own MCP server?

Not as of 21 September 2026. IAS publishes SOAP web services only, and nothing for Canias or TROIA appears in GitHub or the MCP directories. An assistant has to be connected through TROIA Web Services 2.0.

What licences or access does a Canias ERP connector need?

It needs the WSR web service module on your application server and the TROIA services the tools call, registered with user rights. Licence terms for WSR are not public, so check with IAS or your Canias partner; we confirm them in the blueprint.

Can the assistant see data a user is not allowed to see in Canias?

No. Each session logs in as the asking person, and Canias checks that user's rights for every service called. The generic service call is limited to administrators, so normal users only reach the named tools.

What does a Canias ERP connector cost?

The two-week Readiness Blueprint is fixed at €4,900: agreed tool list, backends checked against your release, identity tested end to end, costed build plan. The production connector is usually a use-case pilot from €15,000. Prices are net, excluding VAT.

Next step

Not a sales call. An architecture call.

Thirty minutes with the engineer who would build the connector, with your Canias ERP administrator in the room if you like.