Build Tools to Query Your ERP Inventory System

Your procurement team needs to check stock levels, look up parts by SKU, and see incoming purchase orders. The ERP system has a REST API, but only engineers know how to query it. Every time someone on the procurement team needs a number, they file a request and wait.

This playbook walks you through building a set of read-only tools that wrap your ERP's API so anyone on the team can look up inventory data from their AI client. You will build four tools: a part lookup, a stock level check, a purchase order search, and a batch availability checker. By the end, your procurement team can ask questions like "What's the stock level for part AB-7042?" and get an answer in seconds.

Most of this workflow happens from your AI client (Claude Desktop, ChatGPT, Cursor) through the MCP connection to Assist. The one exception is credential configuration: the ERP API token should be entered directly in the Assist UI under the Permissions tab of each tool so it never passes through chat.

What you need before you start

  • An Assist workspace with an MCP connection configured in your AI client
  • Your ERP system's API base URL (for example, https://erp.internal.company.com/api/v1)
  • An API key or bearer token for the ERP API
  • A few sample part numbers or SKUs you can use for testing

Phase 1: Explore the API

Before building anything, figure out what the ERP API offers. If you have API documentation, have the AI read it. If you do not, start by describing what you know.

"I need to build tools that query our ERP inventory system. The API is at https://erp.internal.company.com/api/v1. It uses bearer token authentication. The main endpoints I know about are /parts, /inventory, and /purchase-orders. Can you help me plan what tools to build?"

The AI will ask clarifying questions about the API structure. Answer what you know and be honest about what you do not. The AI can help you figure out the rest as you build.

"The /parts endpoint accepts a GET request with a part_number query parameter and returns part details. The /inventory endpoint accepts a part_number and returns current stock levels across all warehouses. The /purchase-orders endpoint supports searching by part_number, status, and date range."

Now the AI has enough context to start building. You do not need to know every field in every response -- you will discover the details as you test.

Phase 2: Build the part lookup tool

Start with the simplest tool. A part lookup takes a part number and returns details about that part.

"Create a tool called 'erp_lookup_part' that takes a part_number string and calls GET /parts?part_number={part_number} on our ERP API. Use bearer token auth from an environment variable called ERP_API_TOKEN. The tool should return the part name, description, category, and unit cost."

The AI creates the tool with the handler code, sets up the input schema, and writes the fetch call. Review what it generated. You might see something you want to adjust.

"That looks right, but also include the manufacturer and lead_time_days fields in the response. And add error handling for when the part number is not found -- the API returns a 404 in that case."

The AI updates the code. Now test it.

"Test erp_lookup_part with part_number 'AB-7042'."

If the test fails with a network error, the tool needs network permissions. Open the tool in the Assist UI, click the Permissions tab, and add erp.internal.company.com under Network Access.

If the test fails with a 401 authentication error, the API token is not configured. In the same Permissions tab, under Environment Variables, add ERP_API_TOKEN as a custom variable and paste the token value into the masked input. Do not paste the token into chat -- the masked input field in the Permissions tab keeps the value out of the LLM context and chat history. See Managing Permissions for the full UI flow.

Run the test again. When it succeeds, review the output. You might notice the response includes more fields than you expected, or the format is not quite right.

"The response includes a lot of internal fields we don't need. Only return part_number, name, description, category, manufacturer, unit_cost, and lead_time_days."

Iterate until the output is clean and useful. When you are satisfied, move on.

Phase 3: Build the stock level check tool

Now build a tool that checks current inventory levels for a part.

"Create a tool called 'erp_check_stock' that takes a part_number and calls GET /inventory?part_number={part_number}. Return the stock level for each warehouse, plus the total across all warehouses. Use the same ERP_API_TOKEN for authentication."

Test it with a part number you know has inventory.

"Test erp_check_stock with part_number 'AB-7042'."

Review the output. The raw API response probably returns an array of warehouse objects. You want the tool to summarize this into something useful.

"The output is good but add a 'total_available' field that sums the quantity across all warehouses. Also add a 'low_stock' boolean that is true if total_available is below the part's reorder_point. You can get the reorder_point from the /parts endpoint."

This is an important moment. The tool now needs to make two API calls: one to get inventory levels and one to get the reorder point from the part details. The AI will update the code to chain these calls.

"Test it again with 'AB-7042'. Also test with a part number that does not exist to make sure it handles that gracefully."

When both cases work, move on.

Phase 4: Build the purchase order search tool

The procurement team needs to see incoming purchase orders for a part. This tool is more complex because it supports multiple search parameters.

"Create a tool called 'erp_search_purchase_orders' that searches purchase orders. It should accept: part_number (optional), status (optional, one of 'open', 'in_transit', 'received', 'cancelled'), date_from (optional, ISO 8601 date), and date_to (optional, ISO 8601 date). Call GET /purchase-orders with these as query parameters. Return the PO number, vendor name, part number, quantity, expected delivery date, and status."

Test with a simple query first.

"Test erp_search_purchase_orders with part_number 'AB-7042' and status 'open'."

Review the results. You will likely want to refine the output format.

"That looks right but the dates are coming back in Unix timestamps. Convert them to ISO 8601 format. Also sort the results by expected_delivery_date ascending so the soonest deliveries show first."

Test edge cases.

"Test with no parameters to see what happens when you search without filters."

If the API returns too many results, add pagination or a limit.

"The API returned 500 results. Add a limit parameter with a default of 25, and include the total count in the response so the user knows how many results exist."

Phase 5: Build the batch availability check tool

The procurement team often needs to check availability for multiple parts at once -- for example, all the parts in a bill of materials.

"Create a tool called 'erp_batch_check_availability' that takes an array of part_number strings. For each part, call the stock check and return the part number, total available quantity, whether it is in stock, and whether there are any open purchase orders. Return the results as an array."

This tool combines data from the inventory endpoint and the purchase orders endpoint for each part. The AI will write the code to make these calls efficiently.

"Test it with ['AB-7042', 'CD-1198', 'EF-3301']."

Review the output. You might want a summary.

"Add a summary at the top of the response that says how many parts are in stock, how many are low, and how many have open POs."

"The response is good. But the tool is slow because it makes API calls sequentially. Can you parallelize the calls for each part?"

The AI will refactor the code to use Promise.all for concurrent requests. Test again to verify it is faster and still returns correct results.

Phase 6: Test end to end

Now test all four tools together in a realistic workflow. Ask the kind of question your procurement team would actually ask.

"I need to prepare for a production run of product X. Can you check if we have enough of parts AB-7042, CD-1198, and EF-3301? For any parts that are low, show me the open purchase orders."

The AI will use your tools to check stock levels, identify which parts are low, and pull up purchase orders for those parts. This is the experience your procurement team will have.

If something is wrong -- a field is missing, a format is confusing, an error message is unclear -- fix it now.

"The stock check for CD-1198 shows it in a warehouse called 'WH-03' but we call that 'Chicago Warehouse'. Can the part lookup tool also return warehouse names alongside the warehouse codes?"

Phase 7: Commit and publish

When everything works, commit and publish each tool.

"Commit erp_lookup_part with the message 'Part lookup by part number with manufacturer and lead time'. Then publish it."

"Commit erp_check_stock with the message 'Stock level check with low stock detection'. Then publish it."

"Commit erp_search_purchase_orders with the message 'PO search by part, status, and date range'. Then publish it."

"Commit erp_batch_check_availability with the message 'Batch availability check with parallel API calls'. Then publish it."

Each tool is now live in your workspace. Anyone with access to the workspace can use these tools from their AI client.

What you built

  • erp_lookup_part -- Looks up a part by part number and returns details including manufacturer and lead time
  • erp_check_stock -- Checks current stock levels across all warehouses with low-stock detection
  • erp_search_purchase_orders -- Searches purchase orders by part, status, and date range
  • erp_batch_check_availability -- Checks availability for multiple parts at once with a summary

Your procurement team can now query the ERP system from their AI client without filing requests to engineering. They can check stock before placing orders, track incoming deliveries, and verify availability for entire bills of materials.

Related guides