How to use Claude with TOTVS Protheus
Short answer
Claude reaches Protheus through a Model Context Protocol server that wraps read-only queries and approved services. You can run Claude through Anthropic's API or a cloud platform such as AWS Bedrock or Google Vertex, or use an open-weight model on-prem if data cannot leave.
Teams that like Claude for long documents and careful reasoning often want it to read Protheus data: contracts attached to purchase orders, engineering notes, inspection records, and the tables behind them. The practical route is MCP, because it keeps the Protheus connection in your hands and lets Claude call it as a tool.
Where Claude runs is a separate decision. The Anthropic API, AWS Bedrock and Google Vertex AI are all options, and the right one depends on where your Protheus lives, your cloud contracts, and whether Brazilian data-residency or customer confidentiality rules allow processing outside the country or outside your network.
For Protheus, the work is mostly on the tool side: a safe way to query SA1, SC7, SD1 and the like, with branch scoping and no direct table writes.
What teams use it for
Purchase order review with attached contracts
Claude reads the PO lines from SC7 and the supplier agreement PDF, and flags clauses on delivery penalties that apply to late lines.
Quality and non-conformance summaries
Summarizes inspection records and related inbound invoices to draft a supplier corrective action request for the quality team.
Variance explanation for finance
Given a cost center query, explains movements between periods and points to the documents behind the largest changes.
Customization documentation
Reads exported AdvPL/TLPP source and entry points and produces readable documentation of what a custom routine does, for onboarding or migration planning.
Migration mapping to a newer release
Compares your SX3 custom fields to a target release and drafts a mapping list for the technical team to verify.
TOTVS Protheus integration surface
- An MCP server written in Python or TypeScript that wraps Protheus REST services or SQL views, exposing named tools to Claude.
- Standard and custom REST endpoints from the application server (FWRest, WsRestFul in AdvPL or TLPP), subject to release.
- Read access to the Protheus database via views, filtering on D_E_L_E_T_ and filial.
- Source code repositories or exported .prw and .tlpp files for code-explanation tasks, which need no live connection.
- SX data dictionary tables for field titles and types, so Claude can interpret custom columns.
How it works
- 1
Choose where Claude runs
Anthropic API for simplest access, Bedrock or Vertex if you already have enterprise agreements there, or a local model if the data must stay on site. Check regional availability for your needs.
- 2
Build the MCP server
Start with tools such as get_purchase_order, list_open_lines and get_customer, each returning compact JSON from a view with branch filters applied.
- 3
Authenticate to Protheus with a service account
Use a dedicated read-only identity, and where user-level permissions matter, pass the end user's identity so the tool can scope rows.
- 4
Add document access
Expose PO attachments or a document store through a search tool so Claude can cite clauses rather than guess.
- 5
Connect the client
Register the server with Claude Desktop or an internal app. Use stdio for a single user and an HTTP transport with auth for shared use.
- 6
Review outputs and widen scope
Have users flag wrong answers, add tests for the common queries, and only later add write proposals behind approval.
Example flows
Contract-aware late delivery check
Trigger: A buyer asks whether late PO 8841 triggers penalties.
- Claude calls get_purchase_order for the lines and promised dates.
- It searches the attached supplier agreement for delay terms.
- It computes days late per line.
- It answers with the clause text and a suggested note to the supplier.
Result: The buyer gets an answer grounded in both the ERP record and the contract, with citations to check.
Customization explainer for a migration
Trigger: A consultant uploads a folder of .prw files.
- Claude reads each file and the entry point names.
- It lists which standard routines are altered and why.
- It flags code that writes tables directly.
- It outputs a summary table for the project plan.
Result: Faster discovery before upgrading, with no live ERP access at all.
Keeping data on-prem
When data must remain inside your network, do not send it to any hosted model. Keep the same MCP server and point it at an internal client that uses an open-weight model served by vLLM or Ollama on local GPUs. Tools, schemas and tests carry over, so you can start with Claude on non-sensitive material, such as source-code explanation, and move sensitive Protheus data to the local model. Some Brazilian public-sector and defense-related customers also require that processing happen in specific regions, which an on-prem setup satisfies by design.
Security checklist
- Run the MCP server under a read-only database role and expose views, not base tables.
- Use an HTTP transport with token auth for shared servers; avoid unauthenticated local ports on shared hosts.
- Log every tool call with user, branch and parameters for audit and LGPD requests.
- Review the provider's data-handling terms and any zero-retention options before sending business data.
- Treat text inside POs and emails as untrusted, since it may contain instructions aimed at the model.
Ways to get it done
Claude with a community or in-house MCP server over Protheus REST
Effort: Two to four weeks.
Good when you have TLPP developers and can publish a clean read-only API.
Claude on Bedrock or Vertex inside your cloud tenancy
Effort: Add days for networking and approvals.
Good when enterprise cloud agreements and data-processing terms are already in place.
Private on-prem model plus the same MCP tools through Netray
Effort: A pilot is typically a few weeks.
Fits restricted data, air-gapped plants and multi-ERP landscapes.
Pitfalls
- !Pointing Claude at base tables where deleted records and other branches appear valid.
- !Sending whole attachments when only the relevant section is needed, which costs tokens and exposes more data.
- !Skipping source-language handling; Portuguese field titles and mixed-language notes need testing.
- !Using a single shared token for all users, losing the per-user branch scoping.
- !Assuming a hosted model knows your customizations. It only sees what your tools return.
Frequently asked questions
How does Claude connect to Protheus?
Through an MCP server you build or deploy. It exposes tools like order lookup, wrapping Protheus REST services or SQL views. Claude calls the tools, receives JSON, and answers. The ERP itself needs no Claude-specific component.
Can we use Claude through AWS Bedrock or Google Vertex?
Yes, Claude models are offered through those platforms in supported regions. That can keep traffic inside your cloud account and under existing agreements. Check current model and region availability, and whether Brazilian residency requirements are met.
Is Claude allowed to see our Protheus data?
Only what your tools return. Decide per dataset. Many firms allow product and order status but block pricing, payroll and personal data, and use a local model for the sensitive remainder.
Can Claude help with AdvPL and TLPP code?
Yes for reading, explaining and drafting code, including finding entry points and direct table writes. Treat generated code as a draft: review it, test it in a homologation environment, and follow your compile and release process.
What if we need everything on-prem?
Use an open-weight model on your own GPUs behind the same MCP tools. Capability is lower than top hosted models on hard reasoning, but adequate for lookups, summaries and drafting, and no data leaves your network.
Want Claude working on your TOTVS Protheus?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment