Agent Tool Calling (Function Call / MCP): Connecting ERP and CRM the Right Way
Once an enterprise Agent must “look up a CRM opportunity,” “read ERP stock,” or “open a ticket,” it leaves pure chat: the model proposes a call, a gateway runs allowlisted tools, and structured results return for the reply. Function Call (vendor tools / function calling) covers how the model declares what to invoke. MCP (Model Context Protocol) covers how tools are discovered, authenticated, and reused across hosts. Neither means “paste ERP passwords into the prompt.” GeonAI designs tool surfaces and human-confirm points per scenario; /agents are capability references only (not a public trial of all 363+ presets). Email [email protected]. Multi-agent: /blog/multi-agent-vs-single-assistant. Delivery: /blog/enterprise-ai-agent-delivery-4-steps.
Align terms: Function Call, MCP, and your gateway
| Concept | Solves | Does not solve |
|---|---|---|
| Function Call / Tools | Structured “call this tool” intent and args from the model | ERP auth, idempotency, audit, write approval |
| MCP | Standard way to expose tools/resources to hosts | Automatic enterprise ACL and change control |
| Custom tool gateway | Allowlists, quotas, signature checks, human confirm, audit logs | Replacing the business system’s own permission model |
| RAG only | Answers from policies and FAQs with citations | Live order state or writable business actions |
A common production stack is model Function Call → your tool gateway → (optional) MCP server or direct ERP/CRM APIs. MCP is an optional standardization layer—not the only ticket to production.
When you need tools—not a bigger knowledge base
- Answers depend on live state (stock, shipment, opportunity stage, ticket status)
- You need writes (create lead, draft address change, submit refund request)
- You must audit who called which API, with args and result codes
- Results differ by account (identity and data scope matter)
For explaining policy, pricing rules, and SOPs, prefer RAG with citations (/blog/enterprise-rag-knowledge-base-agent). Dumping order APIs into a vector store creates stale data and compliance risk.
Hard rules when connecting ERP / CRM
- Allowlist tools: expose only the 3–8 actions the pilot needs; ban “generic SQL / arbitrary REST”
- Read-heavy: default to read-only queries; put writes in separate tools with draft + human confirm
- Identity: SSO / service account plus user context for data scope—never a shared super-key for free-form model use
- Validate args: enums, amount caps, ID formats at the gateway; model output is untrusted
- Idempotency: write tools carry an idempotency key; on timeout, check status—do not blindly replay
- Audit fields: sessionId, toolName, argsHash, resultCode, latency, operatorConfirm in logs
- Failure copy: on tool failure, refuse or hand off—never invent “order placed successfully”
Two paths: native Function Call vs introducing MCP
| Path | Best when | Cost |
|---|---|---|
| A · Model tools + custom gateway | Few tools, fixed systems (1–2 ERP/CRM), need a fast pilot | Each runtime maintains its own tools schema |
| B · MCP server + host | Many hosts/Agents reuse one tool surface; tool set will grow | Extra protocol/ops; you still own auth and approval |
| C · “Universal plugin” with no gateway | Almost never | No ACL, weak audit, huge write blast radius |
Most pilots start with A: two read-only tools (CRM opportunities, ERP ATP). After acceptance, evaluate MCP to unify exposure. Treating MCP as an ungated universal socket is a common mistake.
Worked example: pre-sales assistant touching CRM and ERP
| User intent | Tool | Confirm policy | Accept on |
|---|---|---|---|
| Latest opportunities for a customer | crm.get_opportunities(customerId) | Read-only; filter by sales ACL | Zero cross-ACL leaks; clarify on missing args |
| Sellable stock for a SKU | erp.get_atp(sku, warehouse) | Read-only; label freshness if cache ≤5 min OK | Sample match vs ERP |
| Create a follow-up task | crm.create_task(...) | Draft preview → human confirm before submit | Mis-create rate; cancel before confirm |
| “Change the deal price for me” | No tool / refuse | Handoff or ticket | Never let the model hit price-edit APIs |
Pre-sales dialogue design: /blog/presales-consultation-agent-design. For router + specialists, see the multi-agent post. POC metrics: /blog/poc-to-production-agent-checklist.
Anti-patterns (stop if you see them)
- Admin ERP/CRM tokens in the system prompt or the browser
- A universal tool like execute_any_api(url, body)
- Treating the model’s natural-language “done” as write success without a gateway receipt
- On tool errors, letting the model “reasonably guess” business state for customers
- Adopting MCP while skipping allowlists, quotas, and human confirm
- Treating preset demos on /agents as a live hookup to your production ERP
Pilot checklist (paste into the SOW)
- List intents that must be live or writable; keep the rest on RAG
- Draw the tool allowlist (name, args, read/write, confirm policy)
- Choose path A or B; define auth and environment (test tenant first)
- Define idempotency, timeouts, retries, and failure copy
- Audit fields and sampling (ACL leaks, invented receipts, skipped confirms)
- Gray one entry point; expand tools only after pass—do not wire every API on day one
How to brief GeonAI
Share systems (CRM/ERP/ticketing), read-only vs writes, existing APIs/middleware, acceptable human-confirm points, and the pilot intent list. Email [email protected], /pricing, or Live chat. We favor the smallest auditable tool surface—not unbounded plugins.
Frequently asked questions
Are Function Call and MCP the same thing?
No. Function Call is how the model proposes a call; MCP is how tools are exposed and connected in a standard way. Production still needs your gateway for auth, allowlists, and audit.
Can we connect ERP without MCP?
Yes. Model tools plus a custom gateway to APIs is a common pilot. Introduce MCP when many hosts must reuse one tool surface or the tool set will keep growing.
Do writes always need human confirmation?
High-risk writes (price changes, refunds, permission changes) should require confirm in the pilot. Lower-risk writes (internal follow-up tasks) can move toward semi-auto after sampled QA, with audit and rollback kept.
What should the Agent say when a tool fails?
State that the system is unavailable or nothing was found, then hand off or offer a ticket path. Never invent a success state. Acceptance should sample failure copy, not only happy paths.
How does this relate to multi-agent design?
When tool rights conflict, split a read-only lookup Agent from a write-draft Agent (see the multi-agent post). Per-specialist allowlists beat one omniscient assistant.
Do marketplace presets already call our tools?
Showcase presets are capability references. They do not include your ERP/CRM credentials or allowlists. Production hookup needs a custom gateway and acceptance tests.