How to build an MCP server for ECI JobBOSS2
Short answer
A JobBOSS2 MCP server is a small service that exposes read-only tools such as job lookup, material status and open PO queries over the SQL Server database, so any MCP client can use them. Build tools first, then auth and audit, then think about writes.
If you want more than one AI client to talk to JobBOSS2, say Claude for the office, ChatGPT for another team, and an internal agent, you do not want a separate integration for each. The Model Context Protocol gives them one way to discover and call your tools.
The server itself is not complicated. The design questions are which tools to expose, how big their outputs are, how users are identified, and what happens when someone tries to misuse them. A job shop's database holds customer pricing and sometimes controlled technical data, so these questions matter.
Below is a design that works on a typical on-prem JobBOSS2 install, written for a developer who knows SQL Server.
What teams use it for
One tool layer for many clients
Expose the same job, PO and inventory tools to Claude, other MCP-aware assistants and internal scripts.
Order desk assistant
get_job_status and get_delivery_schedule let customer service answer in seconds.
Purchasing visibility
list_overdue_pos and get_material_requirements support buyers and expediters.
Shop floor status for supervisors
get_work_center_queue returns what is waiting at each machine and how many hours.
Quote research
find_similar_jobs returns past jobs by part family, material and quantity range with hours and cost.
Audit-friendly agent foundation
A central place to log what any AI touched, instead of scattered ad hoc queries.
ECI JobBOSS2 integration surface
- Microsoft SQL Server is the data store. Build views over tables such as Job, Job_Operation, Material_Req, Delivery, PO_Header, PO_Detail, Work_Center and Customer (verify names in your version).
- Windows authentication or a SQL login can be used by the server process. Prefer a dedicated service account with SELECT on views only.
- If your edition offers the JobBOSS2 API, it can serve as an alternative backend for tools, with its own authentication.
- Official MCP SDKs exist for TypeScript and Python. Choose what your team can maintain, and a driver such as pyodbc or mssql for the database.
- JobBOSS2 application roles are enforced by the app, not the database, so your server must re-implement any per-user restrictions.
How it works
- 1
Inventory questions people ask
Collect 40 real questions from sales, planning, purchasing and quality. Group them into 8 to 12 tool candidates.
- 2
Create the views
One view per tool, with business-friendly column names and no sensitive columns the tool does not need.
- 3
Define tool schemas
Typed inputs (job number, date range, work center), explicit outputs, a maximum of a few hundred rows, and a clear description that tells the model when to use it.
- 4
Pick a transport
Use stdio for single-user desktop tests. Use streamable HTTP behind your reverse proxy with TLS for teams.
- 5
Add authentication and scoping
Validate a token on each request, map the user to allowed customers or sites, and apply that filter in the query, not in the prompt.
- 6
Add audit logging
Record user, tool, parameters, row count and duration to a table or log store that the MCP process cannot edit.
- 7
Test with adversarial prompts
Try asking for all customers, other users' data, and SQL fragments in parameters. The server must refuse or return nothing.
Example flows
Tool call: get_job_status
Trigger: A client asks for the status of a job number.
- Server validates the token and user role.
- Parameterised query against the job status view.
- Result trimmed to status, current operation, next work center and promised date.
- Call logged with the user and job number.
Result: The client answers the question without ever seeing the full job record.
Tool call: list_overdue_pos
Trigger: A buyer asks which POs are late for jobs starting this week.
- Server applies the buyer's site filter.
- View joins PO lines to material requirements and job start dates.
- Returns up to 100 rows sorted by days late.
Result: A focused expedite list instead of a full open-PO report.
Keeping data on-prem
Run the MCP server on a host inside your network, as a Windows service or a container, with the SQL login reaching only the reporting views. If a client is hosted (for example a cloud assistant), expose the server through a reverse proxy with TLS and IP allow lists, or keep clients local by using an open-weight model on your GPU hardware. For stricter environments, bind the server to an internal address only and use a model served in the same enclave. The server needs no internet access of its own.
Security checklist
- SELECT-only service account scoped to views; never db_owner and never the application's own login.
- Parameterised queries only. Never build SQL from model-supplied strings.
- Per-user authorisation enforced inside the server, with filters applied in SQL.
- Row caps and rate limits per user to prevent bulk extraction through repeated calls.
- Immutable audit logs, and a process to review them. Rotate tokens and secrets.
Ways to get it done
Open-source generic SQL MCP server
Effort: Hours to try
Fast for exploration, but a general query tool is too permissive for production. Wrap or restrict it.
Custom server in TypeScript or Python
Effort: 2 to 5 weeks including auth and audit
The right choice for most shops with a developer on hand.
Partner-built with Netray
Effort: A few weeks for scoped read tools
When you want the server, evaluation set and on-prem model hosting delivered together.
Pitfalls
- !Exposing a generic run_sql tool. It is convenient and makes every access control decision the model's problem.
- !Returning entire rows with columns like unit price and cost when the question needs only status.
- !Forgetting multi-company databases, so a user sees another entity's jobs.
- !Leaving stdio configurations with embedded passwords in user config files.
- !No versioning of tool schemas, so a rename silently breaks agents that depend on it.
Frequently asked questions
What is an MCP server in plain terms?
It is a small program that tells an AI app which actions it can take on your system and carries them out when asked. For JobBOSS2, those actions are things like looking up a job or listing late purchase orders, each with defined inputs and outputs.
Should the first version have write tools?
No. Start read-only. Writes into JobBOSS2 need to go through supported paths to keep calculated fields correct, and they need approvals. Add them later, one narrow action at a time.
Stdio or HTTP transport?
Stdio suits a single person trying it on their own machine. HTTP suits shared use: you can centralise authentication, logging and updates. Most production setups end up on HTTP behind a reverse proxy.
Does ECI ship an MCP server for JobBOSS2?
Check with ECI for current options. If none exists for your edition, a custom server over views is a well-trodden path and works with any MCP client.
How do we keep it in sync with schema changes?
Query views, not tables. When an ECI update changes a table, you adjust the view and the tool contract stays stable. Add a smoke test that runs each tool against a test database after upgrades.
Want MCP server working on your ECI JobBOSS2?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment