A salesperson asks AI, "Do we have enough of this product to deliver on Friday?" AI reads the ERP and reports 120 units. That sounds useful. But if 80 are reserved for other orders and another 20, outside those reservations, are awaiting inspection, the salesperson still cannot promise the shipment.
A connection can work correctly and still leave this question unanswered. The system returned the requested figure. The figure and the business question mean different things.
Episode 1 separated protocols, standards and open source to ask which parts of a company's investment could move with it when it changes AI products. This episode follows the stock-availability question into the ERP connection: what AI can read, how it obtains that information and what it may do next. Business owners need to decide these points with sales, warehouse staff and the systems team, even if they never write an API themselves.
The API provides access; the tool defines the task
An ERP integration may use the system's API to retrieve data or submit an action. The application can then wrap that access in a tool AI can call, such as product search or an availability check. The tool's name, required inputs and returned fields influence what AI can understand and attempt.
Model Context Protocol, or MCP, is one option for connecting these tools to AI applications. MCP servers can expose named tools with schemas, allowing interaction with external systems, including APIs and databases. MCP Tools specification
The user's aim might be simple: ask what is available and receive an answer they can check. The technical team must decide whether to connect the application's tools directly to the ERP API or introduce MCP for tools that several applications may share. That choice depends on the existing systems, intended reuse and maintenance costs. With one application and a clear API, consider what an additional integration component would cost to maintain.
MCP defines context exchange. It does not prescribe how an application uses its model or manages that context. A successful connection therefore still needs a business check: does the answer follow the company's rules? MCP architecture
Start with the question the employee must answer
Choose one question salespeople actually need answered. Ask the warehouse owner what they check before saying "we can ship." One company may subtract reservations; another must also consider the customer's assigned warehouse, quality inspection or transport arrangements.
Agree on which records determine availability, when the data was refreshed, which unit of measure applies and which company and warehouse are included. If the ERP has no reliable delivery-date evidence, the tool should report what it can establish and identify what a person still needs to check.
This makes a design choice easier to assess. A general query tool offers flexibility, but reviewers must establish which data AI selected. A tool that requires a product code, warehouse and reference date narrows the work and makes its meaning easier to inspect. For an initial pilot, a scope that people can verify deserves priority.
"Read only" needs a boundary too. Sales staff may need quantities and allocation status without product costs or another group company's records. Test with the actual accounts and data boundaries intended for the pilot.
The MCP specification makes authorization support optional for implementations. Its authorization flow covers HTTP transports; STDIO implementations instead obtain credentials from their environment. These connection mechanisms do not settle who may approve a discount, credit limit or stock reservation. The company still needs to implement its own authority rules. MCP Authorization
