Skip to content

What is in the solution package

Installing anything into an ERP deserves a careful look first. This page lists every component of MCP-Solution.cab, what each one does, and what they do not do.

You do not have to take this page’s word for it. Verify the package yourself before you install it.

The package installs four functions and two sign-in screens, plus the menu entries that reach them. It reads and writes four configuration rows. It touches no business data: no parts, no orders, no ledger, no customers.

Component What it is
MCP function library Four Epicor Functions. Key management and token signing
Ice.UI.MCPAuth The Kinetic sign-in screen
MCPToken dashboard and BAQ The same sign-in for Classic environments
Two menu entries How your users reach the two screens

All four live in one Epicor Function Library named MCP. You can read every line of their source in Epicor at any time, before or after installing: open Function Maintenance and select the MCP library.

Epicor Functions Maintenance showing the MCP library with its four functions: CreateKeys, CreateToken, RegisterTenant and RotateKey

Nothing is compiled or hidden. Click any function to read its C#.

Generates a 2048-bit RSA keypair the first time you register, and writes it to two Ice.SysConfig rows: LensMCPPub (public) and LensMCPPrv (private).

The private key never leaves your Epicor server. Cutova receives only the public key, which is all it needs to check that a token really came from your system.

Runs when one of your users authorizes an AI client. It builds a short JSON token saying “this is <your user>, on <this instance>”, signs it with the private key, and returns it.

It does not send anything anywhere. It returns the token to the screen that asked for it.

Two checks run before it signs:

  • The destination must be on the allowlist stored in the LensRedirect row. If it is not, the function refuses and signs nothing.
  • If that allowlist row is missing or empty, it also refuses. It does not fall back to signing for anyone.

RegisterTenant: records which Cutova tenant this instance belongs to

Section titled “RegisterTenant: records which Cutova tenant this instance belongs to”

Writes the LensTen row: your tenant id, your instance id, and the token issuer and audience. It also adds the Cutova address to the LensRedirect allowlist.

With the current library, re-registering adds the address and retains existing allowlist entries. It reuses the existing keypair, so this does not sign out connected users.

RotateKey: replaces the signing keypair on purpose

Section titled “RotateKey: replaces the signing keypair on purpose”

For the day you want a new keypair. Everyone connected has to authorize again afterwards, so this is a deliberate action, not routine maintenance.

Your users see one of these when an AI client asks for access. Both do the same job; you get both, and your environment uses whichever fits.

A full-page notice explaining what they are approving, with Authorize and Cancel. Approving calls CreateToken and hands the token back to Cutova. Cancel leaves without issuing anything.

The Kinetic MCP Auth screen, showing the authorization notice with Authorize and Cancel buttons

Reached from the menu entry Cutova.ai MCP for Kinetic Auth.

Classic environments cannot do the browser redirect the Kinetic screen uses, so this one is a dashboard with a BAQ behind it. It shows the same notice and produces the same token, and the user copies and pastes it into Cutova instead of being redirected.

The Classic MCP Token window, showing the same notice, a token field and a Copy Token button

Same function, same token, same checks. Only the delivery differs. The token in that field is scrubbed in this screenshot: treat a real one as a password.

Reached from the menu entry Cutova.ai MCP for Kinetic Auth Classic.

This is the part most Epicor administrators want first.

  • It reads and writes no business data. No parts, orders, jobs, invoices, customers, ledger.
  • It touches four Ice.SysConfig rows and nothing else in your database: LensMCPPub, LensMCPPrv, LensTen, LensRedirect.
  • It changes no existing Epicor screen, BO, BPM or report. Everything it installs is new and named MCP* or Ice.UI.MCPAuth.
  • It grants Cutova no permissions of its own. Every later action runs as the signed-in Epicor user, limited to that user’s own Epicor permissions, and is recorded against their user id.
  • It sends nothing outbound on install. Nothing calls out until one of your users chooses to authorize.
  • Your Epicor password is never shared. Authorizing issues a signed token; it does not hand over credentials.

The download button is not the only thing vouching for the package.

Open /api/mcp-solution.cab.json on your Cutova server. It reports the library revision, the size, a sha256 of the exact bytes the button serves, and a set of markers naming the fixes that must be present. The console shows the same revision beside the button.

The .cab is a zip. Rename it and open it if you want to read the manifest and see the component list for yourself.

Installing it is step two of three. It does nothing until you complete registration in the Cutova console, which is what writes LensTen and the allowlist. Until then the functions are present and inert.

Read Register your Epicor instance for the whole sequence.