Celigo supports two distinct patterns for bringing AI into an integration stack, and they solve different problems. An AI Agent step is embedded inside a flow — the model receives a structured payload at one point in a pipeline and returns structured output the rest of the flow acts on. MCP Server is different: it's a standing, governed query layer that lets an external AI assistant pull real-time data from connected systems on demand, without ever holding API credentials. This article is about the second pattern — what it replaces, how it's actually configured, and a real deployment. For the full capability overview, see our Celigo AI Agents & MCP Server page.
Celigo MCP Server — At a Glance
- What it is: a Celigo-managed interface exposing connected systems (NetSuite, Salesforce, others) to AI assistants via the Model Context Protocol
- What it replaces: giving an AI model direct API credentials — which puts those credentials in the model context, prompts, and logs
- How auth works: the AI assistant authenticates via a scoped token managed by Celigo; the model never sees a NetSuite/Salesforce credential
- What gets logged: every query — timestamp, model identifier, input parameters, and a response hash — visible from the same Celigo dashboard used for other integrations
- Compatible clients: any MCP-compatible AI assistant — a Claude Project, an internal custom tool, another MCP client
- Real deployment: a mid-market client's internal AI assistant went from a 24-hour manual NetSuite reporting cycle to real-time answers via 4 defined query types
Why not just give the AI model direct API credentials?
It's the obvious shortcut, and it's also where most ungoverned AI-to-ERP setups go wrong. Four concrete problems show up in practice:
- Credential exposure. Direct API credentials end up living in the model context, in prompts, and in logs. A single leaked prompt — copy-pasted somewhere it shouldn't be, logged by a third-party tool, exposed in a debugging session — means live NetSuite or Salesforce access is exposed too.
- No audit trail. Direct API calls from an AI model are invisible to an ops team. Nobody can answer "what did the AI query, and when" until something has already gone wrong and someone goes looking.
- No structured error handling. When a direct API call fails, there's no governance layer catching it — the model may retry with a bad payload, infer a workaround that corrupts data, or silently return nothing.
- Fragmented ownership. A direct AI-to-API integration lives outside the integration platform entirely — built and monitored by whoever wrote the prompt, not the team that owns the rest of the integration stack. When it breaks, nobody knows where to look first.
How Celigo's MCP layer actually works
The MCP Server configuration exposes a defined set of queries against connected systems — each with defined inputs, outputs, and access scope. This scoping matters: the AI assistant can query exactly what's been defined, nothing more, which is a meaningfully different security posture than handing over broad API access and hoping the prompt stays well-behaved.
Authentication happens via a scoped token, not a shared credential. Every query — from any connected AI client, whether that's a Claude Project, a custom internal LLM application, or another MCP-compatible tool — is logged with a timestamp, the model identifier, the input parameters, and a hash of the response. That log lives in the same Celigo dashboard used to monitor every other integration, not in a separate, unmonitored system.
Rate limiting is handled at the same layer, so a misbehaving or overly aggressive AI client can't accidentally hammer NetSuite or Salesforce the way an unmanaged direct-API integration could.
A real deployment: real-time NetSuite access without credential exposure
A mid-market client needed their internal AI assistant to answer operational questions in real time — current inventory levels, open order status, recent customer activity. The existing process was a 24-hour reporting cycle: someone ran a NetSuite report, exported it, and shared it. Questions that should take seconds took a day.
Entech configured a Celigo MCP Server exposing four NetSuite query types: inventory lookup by SKU, order status by order number, customer activity by account ID, and an open AP/AR summary. The AI assistant — a custom internal tool built on Claude — authenticates via a scoped token managed by Celigo. No NetSuite credentials appear in the model context, the system prompt, or any log.
Every query is captured by the MCP layer: timestamp, input parameters, which model made the request, and a hash of the response. The client's ops team audits every AI-initiated query from the same Celigo dashboard where they monitor the rest of their integrations — not a separate tool, not a separate process.
Implementing this: what actually matters
Define the decision boundary before writing any flow. What is the AI model allowed to query, decide, or modify? Document it as an explicit constraint spec, not a loose design guideline — this is the scoping work that makes the "governed" part of governed AI access real rather than aspirational.
Treat the prompt as part of the integration spec. The system prompt gets versioned, reviewed, and tested the same way a field mapping would be — not written once and forgotten.
Validate every AI response before it writes anywhere. Structure, range, and business-logic checks run before any AI output reaches a system of record — this is true for both MCP Server queries and embedded AI Agent steps.
Instrument from day one, not after scaling. Logging, monitoring, and alerting need to exist before an AI-driven flow handles real volume. Retroactively instrumenting a high-volume flow after the fact is expensive and usually happens only after an incident forces the question.
Frequently Asked Questions
- What is Celigo's MCP Server?
- A Celigo-managed interface that exposes your connected systems — NetSuite, Salesforce, and others — to AI assistants via the Model Context Protocol. It handles token authentication, rate limiting, input scoping, and full query logging, so an AI assistant can query live data without ever holding your API credentials.
- What's the difference between an AI Agent step and MCP Server in Celigo?
- An AI Agent step is embedded inside a Celigo integration flow — the model receives a structured payload as one step in a pipeline and returns structured output the rest of the flow acts on. MCP Server is a standing query layer that lets an external AI assistant pull real-time data from your systems on demand, outside of any specific flow.
- Why not just give an AI model direct API credentials to NetSuite?
- Four concrete risks: credentials living in the model context, prompts, and logs; no audit trail of what was queried or when; no structured error handling when a call fails; and the integration living outside your platform, maintained by whoever wrote the prompt rather than your integration team.
- Can Celigo's MCP Server work with Claude, ChatGPT, and other AI tools?
- Yes. The MCP layer authenticates any compatible AI assistant via a scoped token — a Claude Project, a custom LLM application, or another MCP-compatible client. The embedded AI Agent step separately supports OpenAI, Anthropic Claude, and Google Gemini as configurable model providers per flow.
- What does a real Celigo MCP Server deployment look like?
- One example: a mid-market client's internal AI assistant needed to answer operational questions that previously took a full day via manual NetSuite reports. Entech configured a Celigo MCP Server exposing four query types (inventory lookup, order status, customer activity, AP/AR summary) to a Claude-based internal tool, with zero NetSuite credentials reaching the model context and every query logged for audit.
Entech Solutions has implemented both the embedded AI Agent and MCP Server patterns across multiple clients — AI outreach orchestration, resume screening, opportunity scoring, and real-time ERP query access. If you're evaluating either approach, get in touch and we'll tell you honestly where the complexity actually is. For the bigger design question, where an agent's decision logic should live relative to the ERP, see System of Record vs System of Action.