MCP and enterprise integrations
Model Context Protocol servers, tool calling and connecting LLMs to SAP, Salesforce, Microsoft 365, ServiceNow, Slack and Snowflake.
What is the Model Context Protocol (MCP) and why does it matter?
The Model Context Protocol, or MCP, is an open standard introduced by Anthropic in November 2024 that defines how a large language model connects to external tools, files and data sources through a common client-server interface. Before MCP, every application that wanted an LLM to read a database, search a wiki or call an internal API had to write custom glue code for each model and each data source, creating an integration effort that multiplied with every new pair of systems. MCP replaces that with a single specification: a server exposes tools, resources and prompts over JSON-RPC, and any compliant client, such as Claude Desktop, Claude Code or an internal agent platform, can discover and call them the same way. This matters for enterprises because it turns integration work into a one-time investment; a company builds one MCP server for its ERP or CRM and every current and future MCP-compatible assistant can use it, instead of rebuilding the connection for each new AI product. Nanobase AI, a Silicon Valley enterprise AI engineering company, designs and builds these MCP servers so internal systems become usable by any compliant LLM client.
Read more — What is the Model Context Protocol (MCP) and why does it matter? →How does an MCP server work?
An MCP server works as a lightweight adapter that exposes a defined set of capabilities, typically tools, resources and prompts, to any MCP client over a standardized JSON-RPC 2.0 message format. When a client such as Claude Desktop or an internal agent starts a session, it performs a capability negotiation handshake with the server, asking what tools it offers and receiving back a list of names, descriptions and JSON Schema definitions for their inputs. From there the language model decides, based on the user's request, which tool to call; the client sends that call to the server, the server executes the underlying logic, for example querying a database or hitting an internal REST API, and returns a structured result that gets fed back into the model's context. The server itself can run locally as a subprocess communicating over stdio, or remotely as a Streamable HTTP service reachable over a network, the pattern used for shared enterprise deployments. Nanobase AI builds these servers around existing internal APIs, handling authentication, input validation and error handling so the resulting tool calls stay safe to expose to a language model in production.
Read more — How does an MCP server work? →MCP vs function calling: what is the difference?
Function calling, also called tool calling, is a capability built into the language model itself: the model is given a list of function definitions in a prompt and decides to output a structured call instead of free text, but there is no standard for how that function's code runs, authenticates or is discovered across applications. MCP sits one layer above that: it is a transport and discovery protocol that standardizes how those function definitions, called tools in MCP terms, are packaged, served and invoked consistently across different LLM providers and client applications. In practice a model still performs function calling internally to decide when to invoke a tool, but MCP defines how the tool got into its context in the first place and how the resulting call reaches the actual system, whether that is Salesforce, a Postgres database or an internal API. The practical benefit is that a company builds one MCP server for a system such as SAP and it works with any MCP-compatible client, rather than writing separate custom tool integrations for every LLM vendor's own function-calling format. Nanobase AI, an NVIDIA Inception Program member, designs enterprise tool layers around this distinction to avoid vendor lock-in.
Read more — MCP vs function calling: what is the difference? →How do we build a custom MCP server for our internal API?
Building a custom MCP server for an internal API starts with choosing an SDK, typically the official Python or TypeScript SDK, and mapping each API operation to be exposed to a discrete tool with a clear name, description and JSON Schema for its inputs and outputs. The description text matters more than it looks, because the language model uses it to decide when to call the tool, so vague or overlapping descriptions cause misfires. Next comes authentication: the server should use a service account or, better, pass through the calling user's own token so downstream permissions are respected rather than granting the model a single all-access credential. For internal-only use a stdio transport running as a local process is often enough, while shared or production deployments need the Streamable HTTP transport behind a reverse proxy with TLS and OAuth. Before shipping, test with the MCP Inspector tool and a real client to confirm the model calls the right tool with valid arguments, then add logging and rate limits. Nanobase AI, a Silicon Valley enterprise AI engineering company, builds and hardens these servers end to end for internal APIs across SAP, Salesforce and custom systems.
Read more — How do we build a custom MCP server for our internal API? →Is MCP ready for production enterprise use?
MCP is ready for production enterprise use when it is implemented with the same rigor as any other integration layer, though the protocol itself is still young and evolving. Since its November 2024 release, the specification has gone through two significant revisions, adding an OAuth 2.1-based authorization framework and the Streamable HTTP transport that replaced the earlier HTTP-plus-SSE approach, both aimed directly at enterprise concerns such as remote hosting and identity. Major AI vendors including Anthropic, OpenAI, Google and Microsoft have adopted or announced support for it, and it now ships as a first-class feature in Claude Desktop, Claude Code and several IDEs, which signals the protocol is past the experimental stage. That said, the ecosystem of third-party servers varies widely in quality and security posture, so enterprises should treat MCP as they would any new API standard: build or vet servers carefully, add logging, authentication and rate limiting, and avoid installing unreviewed community servers with write access to production systems. Nanobase AI evaluates and hardens MCP deployments against these gaps so the protocol's flexibility does not come at the cost of security or reliability in a live environment.
Read more — Is MCP ready for production enterprise use? →How do we connect Claude or ChatGPT to our company data?
Connecting Claude or ChatGPT to company data means building a controlled bridge between the assistant and internal systems rather than uploading documents into a chat window, and the right approach depends on the platform. Claude supports this natively through MCP servers, so a company exposes its wiki, ticketing system or document store as tools and resources that Claude Desktop, Claude Code or Claude.ai can call directly and securely. ChatGPT Enterprise offers a comparable connector and Actions framework for wiring in internal APIs, and both approaches typically pair with retrieval-augmented generation for document collections too large to fit in a single context window. Regardless of platform, the integration should authenticate as the requesting user rather than a shared service account, so the assistant only ever sees data that person is already allowed to see, and every query should be logged for audit. For organizations that cannot send data to a third-party cloud model at all, a self-hosted LLM behind the same connector pattern keeps everything on premise. Nanobase AI, a Silicon Valley enterprise AI engineering company, builds these connectors for both commercial assistants and private model deployments.
Read more — How do we connect Claude or ChatGPT to our company data? →How do we integrate an LLM with SAP?
Integrating an LLM with SAP works by wrapping SAP's existing interfaces, mainly OData services exposed through SAP Gateway, BAPI and RFC calls, or the SAP Business Technology Platform, inside a custom MCP or API layer that the model can call as discrete tools such as check inventory, retrieve purchase order status or look up a customer record. SAP's own Joule assistant covers a subset of use cases within SAP's ecosystem, but a custom integration lets a company connect any LLM, including an on-premise model, to the same underlying SAP data without being confined to Joule's roadmap. Authentication should map to the acting user's own SAP roles rather than a generic technical user, so the model never has broader access than the employee asking the question, and every write operation such as creating a sales order needs its own approval step rather than direct execution. Read-only reporting and lookup tools are the safest starting point before extending into transactional actions. Nanobase AI, an NVIDIA Inception Program member, builds SAP integration layers that expose these operations safely to both commercial and self-hosted language models.
Read more — How do we integrate an LLM with SAP? →How do we integrate an LLM with Salesforce?
Integrating an LLM with Salesforce is done through Salesforce's REST, GraphQL or Bulk APIs, wrapped inside a connector or MCP server that exposes objects such as Leads, Opportunities, Cases and Accounts as callable tools with clearly scoped fields. Authentication uses a Salesforce connected app with OAuth 2.0, ideally issuing tokens on behalf of the actual user so the platform's own sharing rules and field-level security continue to apply rather than being bypassed by a single integration user. Salesforce's native Agentforce product covers many conversational use cases directly inside the platform, but a custom integration is worth building when a company wants to use a specific model, including an on-premise one for data residency reasons, or needs the assistant to reason across Salesforce and other systems such as SAP or a data warehouse in one conversation. Typical first tools are searching records, summarizing an account's history and drafting a case reply, with any record creation or update gated behind a confirmation step. Nanobase AI, a Silicon Valley enterprise AI engineering company, designs these Salesforce connectors to sit alongside or replace Agentforce depending on a customer's model and governance requirements.
Read more — How do we integrate an LLM with Salesforce? →Can we build an AI assistant for ServiceNow tickets?
Yes, an AI assistant for ServiceNow tickets is one of the more straightforward enterprise integrations to build, since ServiceNow's Table API and REST endpoints already expose incidents, requests and knowledge articles in a structured form suitable for tool calling. A typical build wraps operations like searching open incidents, retrieving a ticket's history, drafting a suggested resolution from matching knowledge base articles, and creating or updating a ticket, each exposed as a separate tool with a narrow, well-described purpose rather than one generic API passthrough. Authentication should use OAuth against a ServiceNow instance with a role scoped to the ticketing tables actually needed, and any auto-created or auto-updated ticket should be flagged as AI-assisted so agents can audit it. This kind of assistant is valuable for first-line triage, auto-categorization and suggesting resolutions from historical tickets, cutting the time an agent spends searching before responding. Nanobase AI, a Silicon Valley enterprise AI engineering company, builds ServiceNow assistants of exactly this shape, scoped to a customer's existing ITSM workflows and integrated with either a commercial or self-hosted model.
Read more — Can we build an AI assistant for ServiceNow tickets? →How do we build a Slack or Teams bot powered by our own LLM?
Building a Slack or Teams bot powered by your own LLM starts with the platform's bot framework, the Slack Bolt SDK and Events API for Slack, or the Bot Framework SDK for Microsoft Teams, which handles receiving messages, mentions and thread events from the workspace. That bot server then forwards the conversation to a self-hosted model served through an OpenAI-compatible endpoint, commonly vLLM or NVIDIA NIM, rather than a third-party API, so message content never leaves the company's own infrastructure. For the bot to do more than chat, such as looking up a customer record or creating a ticket, it should call an MCP server exposing those internal actions as tools, keeping the bot logic itself thin. Practical details matter here: handling threading correctly, streaming partial responses so the bot does not appear frozen during longer generations, and rate limiting per channel to avoid runaway costs during busy periods. Nanobase AI builds these bots on top of self-hosted LLM infrastructure it also deploys and operates, so the model, the bot and the internal tool connections form one coherent, privately hosted system.
Read more — How do we build a Slack or Teams bot powered by our own LLM? →How do we let an LLM query Snowflake or Databricks safely?
Letting an LLM query Snowflake or Databricks safely means never giving it a credential that can run arbitrary SQL against production tables; instead, create a dedicated read-only service role scoped to specific views rather than raw tables, so column masking, row-level security policies and sensitive fields defined in the warehouse itself are enforced before any data reaches the model. On top of that, expose a small set of parameterized query tools, for example one for revenue by region or one for a customer's order history, instead of a single generic run-SQL tool, since narrow tools are far easier to review and far harder to misuse through a crafted prompt. Snowflake Cortex and Databricks Genie offer built-in natural-language query features that follow a similar constrained pattern and are worth evaluating before building a custom layer. Query timeouts, row limits and cost quotas on the warehouse role prevent an overly broad or looping agent request from triggering an expensive full-table scan. Nanobase AI designs these data warehouse integrations around least-privilege views and tool scoping rather than direct database access for the model.
Read more — How do we let an LLM query Snowflake or Databricks safely? →What is tool calling and how do LLMs call APIs?
Tool calling, also known as function calling, is the mechanism by which a language model requests that an external action be performed instead of just generating text, and it works in three steps. First, the application sends the model a list of available tools, each described with a name, a natural-language description and a JSON Schema defining its expected arguments, alongside the user's message. Second, if the model decides a tool is needed to answer the request, it returns a structured object naming the tool and the arguments to use, rather than calling the API itself; the model never has direct network access. Third, the application code executes the actual API call, database query or function, and sends the result back to the model in a follow-up message, which the model then uses to compose its final answer to the user. This loop can repeat multiple times for multi-step tasks such as looking something up, then acting on it. Nanobase AI builds this tool-calling integration and the surrounding execution, validation and logging layer for enterprise LLM deployments.
Read more — What is tool calling and how do LLMs call APIs? →How do we handle SSO and OAuth when an LLM accesses user data?
Handling SSO and OAuth when an LLM accesses user data comes down to one principle: the assistant should act with the requesting user's own permissions, never a single shared service account with broad access. In practice this means the application authenticates the user through the company's existing identity provider, obtains a scoped, short-lived OAuth access token for the target system, whether that is Google Workspace, Microsoft 365 or an internal API, and passes that same token down to the connector or MCP server making the actual call. The 2025 revision of the MCP specification formalized this pattern, defining the server as an OAuth 2.1 resource server and the client as responsible for acquiring tokens, which lines up well with existing enterprise SSO deployments. Token refresh, expiry handling and revocation need the same care as any other OAuth client, and tokens should never be logged in full or stored longer than the session requires. Getting this on-behalf-of pattern right is what keeps row-level and document-level permissions intact when an AI assistant sits in front of multiple back-end systems. Nanobase AI, a Silicon Valley enterprise AI engineering company, implements this delegated-token architecture as the default for every enterprise assistant it builds.
Read more — How do we handle SSO and OAuth when an LLM accesses user data? →How does MCP handle authentication and authorization?
MCP handles authentication and authorization through an OAuth 2.1-based framework added in the 2025 specification revisions, which applies specifically to servers reached over the Streamable HTTP transport rather than local stdio connections. Under this model the MCP server acts as an OAuth resource server, publishing metadata so a client can discover the correct authorization server, and the client is responsible for guiding the user through an authorization code flow with PKCE, then attaching the resulting access token to each request. Dynamic client registration allows a new client to register with an authorization server without manual setup, which matters as the number of MCP clients in use across an organization grows. For local stdio servers, which typically run as a subprocess on the same machine as the client, authentication is usually handled outside the protocol itself, through environment variables or local credentials, since there is no network boundary to cross. Scopes attached to tokens should be kept as narrow as the specific tools require, following least privilege rather than issuing one broad token for an entire system. Nanobase AI, an NVIDIA Inception Program member, implements this OAuth layer for every remote MCP server it deploys for clients.
Read more — How does MCP handle authentication and authorization? →What are the best MCP servers for enterprise tools?
There is no single best MCP server for enterprise tools because the right choice depends on which system is being connected and how much you trust the maintainer, but a few categories are worth knowing. Official servers published directly by the platform vendor, such as Atlassian's own Jira and Confluence server or GitHub's official server, tend to be the safest starting point because they are maintained against the vendor's own API changes and security practices. Community servers exist for almost every popular tool, including Slack, Google Drive, Postgres and Snowflake, and can be useful for prototyping, but their code, permissions and update history should be reviewed line by line before anything with write access touches production data. For core enterprise systems like SAP, Salesforce or an internal ERP, a custom-built server scoped tightly to the specific business operations needed is usually the better long-term choice over a generic third-party connector, since it can enforce a company's own authentication and data minimization rules. Nanobase AI, a Silicon Valley enterprise AI engineering company, builds and audits these servers so enterprise teams are not relying on unreviewed public code for systems that hold sensitive data.
Read more — What are the best MCP servers for enterprise tools? →Does MCP work with open-weight models like Llama and Qwen?
Yes, MCP works with open-weight models like Llama and Qwen because the protocol itself is model-agnostic; it only defines how tools, resources and prompts are packaged and transported, not which model interprets them. What actually matters is whether the model has been trained or fine-tuned for reliable tool calling, since MCP still depends on the underlying model correctly deciding when to invoke a tool and formatting its arguments as valid JSON. Recent Llama 3.1 and later releases, Qwen2.5 and newer, and several other open-weight families include native tool-calling support and perform well in this role when served through an OpenAI-compatible endpoint such as vLLM, which most MCP client libraries can talk to with minor adaptation. The remaining piece is an MCP client or agent loop that connects the self-hosted model's tool-calling output to an actual MCP server, since consumer apps like Claude Desktop are built around Anthropic's own models rather than arbitrary open-weight ones. Nanobase AI builds this connecting layer so open-weight models served on premise can use the same MCP servers built for commercial assistants.
Read more — Does MCP work with open-weight models like Llama and Qwen? →Do we need MCP or can we just use REST APIs?
Whether you need MCP or can just use REST APIs depends on how many different AI clients need to call the same internal system. If a single application is being wired to a single LLM provider for one specific task, a direct REST call from that application's own backend, with the model's native function-calling feature describing that one endpoint, is often simpler and involves less new infrastructure than standing up a full MCP server. MCP earns its overhead when multiple clients, for example Claude Desktop, Claude Code, an internal agent platform and a future tool, all need consistent access to the same internal capabilities with the same authentication and schema, since building that once as an MCP server avoids reimplementing the integration for every new client. MCP also brings a shared vocabulary for tool discovery and a growing ecosystem of clients that already know how to talk to any compliant server, which a bespoke REST integration does not get for free. Nanobase AI generally recommends starting with a direct API integration for a narrow use case and moving to an MCP server once a second or third client needs the same access.
Read more — Do we need MCP or can we just use REST APIs? →How do we deploy a remote MCP server behind our firewall?
Deploying a remote MCP server behind a firewall means running it as a Streamable HTTP service inside the company's own network, typically in the same VPC or on-premise segment as the systems it talks to, rather than exposing it directly on the public internet. A reverse proxy in front of the server should terminate TLS, and access from outside the network should go through a VPN, private link or an existing API gateway with mutual TLS rather than a plain open port, keeping the attack surface the same as any other internal service. Authentication follows the OAuth 2.1 resource server pattern from the current MCP specification, so the server validates tokens issued by the existing identity provider instead of managing its own user database. Clients such as Claude Code or an internal agent platform then connect to this internal address, either from inside the corporate network or through the same VPN employees already use for other internal tools. Health checks, structured logging and a rollback plan for schema changes round out a production deployment. Nanobase AI, a Silicon Valley enterprise AI engineering company, deploys these remote MCP servers inside customer networks rather than as third-party hosted services.
Read more — How do we deploy a remote MCP server behind our firewall? →What is the difference between stdio and HTTP MCP transports?
The difference between stdio and HTTP MCP transports comes down to where the server runs and how many clients can use it at once. Stdio transport spawns the MCP server as a local subprocess on the same machine as the client, communicating over standard input and output; it has very low latency and no network exposure, which is why Claude Desktop uses it for local tools like reading files on a personal computer, but it only supports one client at a time and cannot be shared across a team. Streamable HTTP transport, which replaced the earlier HTTP-plus-server-sent-events approach in the 2025 specification update, runs the server as a proper network service that multiple clients can connect to concurrently, supports authentication headers and OAuth, and can be deployed behind a load balancer the way any other API is. Enterprise deployments intended to be shared across a team or department almost always need Streamable HTTP rather than stdio, since stdio has no mechanism for remote access or multi-user authorization. Nanobase AI, a Silicon Valley enterprise AI engineering company, builds most production integrations on Streamable HTTP so a single deployed server can serve an entire organization's MCP clients.
Read more — What is the difference between stdio and HTTP MCP transports? →Can an LLM create purchase orders or update records in SAP?
An LLM can technically create purchase orders or update records in SAP once the relevant BAPI or OData write operations are exposed as tools, but doing so safely requires more caution than read-only lookups. Every write action should run through the acting user's own SAP authorization roles rather than a broad technical service account, so the assistant can never create or modify anything that employee could not already do manually, and the request should pass standard SAP validation and workflow approval just like a manually entered transaction. For anything above a low-risk threshold, such as a purchase order over a certain value, a human confirmation step before the write executes is worth the extra friction, since a model can occasionally produce a plausible but incorrect field value, quantity or vendor reference. Comprehensive logging of the generated request, the approving user and the resulting SAP document number gives a clear audit trail if something needs to be reversed. Nanobase AI implements SAP write actions behind exactly this kind of approval and audit layer rather than allowing direct, unsupervised model-initiated transactions.
Read more — Can an LLM create purchase orders or update records in SAP? →Salesforce Agentforce vs a custom LLM integration: which is better?
Choosing between Salesforce Agentforce and a custom LLM integration mainly comes down to how much a company wants to stay inside Salesforce's own ecosystem versus how much flexibility it needs elsewhere. Agentforce deploys quickly because it is built into Salesforce, uses Salesforce's own data model and Flow automation without extra integration work, and is billed on a per-conversation basis that suits companies whose AI needs are largely confined to CRM tasks like case summarization or lead qualification. A custom integration takes longer to build but allows a choice of any underlying model, including an on-premise deployment for stricter data residency, and lets the assistant reason across Salesforce alongside other systems such as SAP or a data warehouse in a single conversation, which Agentforce does not do out of the box. Cost comparisons are hard to generalize since Agentforce pricing and a custom build's scope both vary considerably, so as of 2026 it is worth getting current Agentforce pricing directly from Salesforce before comparing it against a custom project's estimate. Nanobase AI, a Silicon Valley enterprise AI engineering company, builds the custom option when cross-system reasoning or model choice outweighs Agentforce's convenience.
Read more — Salesforce Agentforce vs a custom LLM integration: which is better? →Microsoft Copilot vs a custom AI assistant on our own data?
Microsoft Copilot and a custom AI assistant built on your own data solve overlapping but distinct problems. Copilot integrates directly into Word, Excel, Outlook and Teams, respects existing Microsoft 365 and SharePoint permissions automatically through Microsoft Graph, and requires little engineering effort to turn on, which makes it a strong default for everyday productivity tasks across an organization already standardized on Microsoft 365. A custom assistant becomes worthwhile when a company needs a specific model, including an open-weight or self-hosted one for data control, needs to reason across systems Copilot does not reach such as SAP or a proprietary data warehouse, or needs business logic and approval workflows tailored to a specific department rather than general productivity help. Licensing for Copilot is per-seat and adds up quickly across a large organization, while a custom assistant carries upfront engineering cost but can scale usage without a linear per-seat fee. Many enterprises end up running both, using Copilot for general office tasks and a custom assistant for domain-specific workflows. Nanobase AI builds the custom side of that pairing, connected to the systems Copilot does not cover.
Read more — Microsoft Copilot vs a custom AI assistant on our own data? →How do we connect an LLM to Jira and Confluence?
Connecting an LLM to Jira and Confluence goes through Atlassian's REST APIs or the official Atlassian MCP server, both of which expose issue search and creation in Jira and page retrieval and editing in Confluence as structured operations an assistant can call. Authentication uses Atlassian's OAuth 2.0 three-legged flow, so the assistant acts with the permissions of the connected user and only ever sees projects and spaces that person can already access, which matters in larger organizations where Jira projects and Confluence spaces often have very different audiences. Common first uses are summarizing a sprint's open tickets, drafting a Confluence page from a set of related Jira issues, and answering questions by searching existing documentation instead of asking someone to look it up manually. Write actions such as creating or transitioning a ticket should be scoped to specific issue types and projects rather than left open-ended, since Jira workflows often carry business rules that a generic write tool would not respect. Nanobase AI builds these Atlassian connectors as part of broader internal knowledge assistants that span Jira, Confluence and other systems in one interface.
Read more — How do we connect an LLM to Jira and Confluence? →How do we integrate an LLM with our ERP without exposing all data?
Integrating an LLM with an ERP system without exposing all of its data comes down to designing narrow, purpose-built tools instead of a single broad connector. Rather than giving the model a generic query interface over the entire ERP database, define individual tools for specific business questions, such as checking a single order's status or looking up a product's stock level, each returning only the fields that task actually needs rather than a full table or record dump. Backing these tools with read-only database views or filtered API endpoints, instead of direct table access, allows field-level masking for sensitive data like pricing or personal information before it ever reaches the model's context. Access should also be scoped to the requesting user's own ERP role, so someone in customer service cannot pull financial data meant only for finance, mirroring the access controls the ERP already enforces for human users. This tool-by-tool, least-privilege approach takes more upfront design work than a single passthrough API but dramatically reduces what a prompt injection or a misused query could expose. Nanobase AI designs ERP integrations this way by default rather than granting broad data access for convenience.
Read more — How do we integrate an LLM with our ERP without exposing all data? →What is the MCP registry and how do we vet third-party MCP servers?
The MCP registry is a catalog, published by Anthropic together with the community starting in 2025, that lists publicly available MCP servers along with metadata such as the publisher, version and the tools each server exposes, giving some central discoverability to what was previously a scattered ecosystem of individual repositories. Listing in a registry is not the same as a security guarantee, so vetting a third-party server before installing it should still include checking who actually publishes and maintains it, reading through the source code for what data it accesses and where it sends requests, and confirming it requests only the permissions its stated purpose requires. Running an unfamiliar server in an isolated environment first, pinning it to a specific version rather than auto-updating, and monitoring for unexpected changes in behavior after updates all guard against the supply-chain risk where a previously trustworthy server is altered later, sometimes called a rug-pull update. For anything touching production systems or sensitive data, an internally reviewed or custom-built server remains safer than an unvetted public one. Nanobase AI performs this kind of security review before recommending any third-party MCP server to a client.
Read more — What is the MCP registry and how do we vet third-party MCP servers? →What are the security risks of MCP servers like tool poisoning?
MCP servers introduce a handful of security risks that are specific to how language models consume tool definitions, and tool poisoning is the most discussed one: a malicious or compromised server can write a tool description containing hidden instructions that manipulate the model's behavior, since the model reads that description as part of its context just like any other text. Related risks include rug-pull updates, where a server behaves safely during review and later changes its implementation after being approved and trusted, prompt injection carried inside resource content such as a fetched document or web page that steers the model once it is loaded into context, and the confused deputy problem where a tool ends up acting with more authority than the requesting user should have. Because the model cannot reliably distinguish trustworthy instructions from injected ones, mitigations need to sit outside the model: sandboxing server execution, allowlisting which tools and servers can be used at all, requiring human approval for any sensitive or write action, and static review of tool descriptions before deployment. Nanobase AI, an NVIDIA Inception Program member, builds these safeguards into every MCP deployment rather than trusting server descriptions at face value.
Read more — What are the security risks of MCP servers like tool poisoning? →How do we log and audit every tool call an LLM makes?
Logging and auditing every tool call an LLM makes requires a dedicated layer sitting between the model and the actual systems it touches, rather than relying on whatever logging the target API happens to produce on its own. The cleanest approach routes every MCP or function call through a proxy or gateway that records a structured entry for each call: timestamp, the authenticated user, the tool name, the arguments passed, the result or error returned, and latency, tagged with a conversation or session identifier so a full interaction can be reconstructed later. These logs should go to the same SIEM or log aggregation system used for other application audit trails, not a separate silo, and they need to be immutable or write-once to hold up under a compliance review for frameworks like SOC 2 or ISO 42001. Beyond compliance, this audit trail is what makes incident investigation possible if an agent takes an unexpected action, since it lets a team replay exactly what was called, with what arguments, and why the model decided to call it. Nanobase AI builds this logging layer as a standard part of every enterprise LLM tool integration it delivers.
Read more — How do we log and audit every tool call an LLM makes? →How do we add rate limits and cost controls to LLM tool use?
Adding rate limits and cost controls to LLM tool use starts at the gateway or proxy layer sitting between the model and the tools it calls, since that is the single point where every call can be measured and throttled before it happens. Practical controls include per-user and per-tool call quotas, a token or dollar budget attached to each session or conversation that stops further calls once exhausted, and circuit breakers that halt an agent after a set number of consecutive tool calls to catch runaway loops, a real risk with autonomous multi-step agents that can otherwise call the same tool dozens of times chasing an unreachable goal. Cost attribution tags on each call, by team, project or use case, make it possible to see where spend is actually going rather than facing a single opaque monthly bill. Alerting thresholds that notify an engineering team well before a hard limit is hit give time to react to unusual usage patterns rather than discovering them after the fact. Nanobase AI builds these controls into the same gateway layer it uses for logging, so cost and audit data come from one consistent source.
Read more — How do we add rate limits and cost controls to LLM tool use? →Can Claude Desktop or Claude Code connect to our internal systems via MCP?
Yes, both Claude Desktop and Claude Code can connect to internal systems through MCP, though they are configured somewhat differently. Claude Desktop reads a local configuration file that lists MCP servers to launch, most commonly over stdio for tools that run on the same machine, such as reading local files or a locally running database client, which suits individual use rather than shared team access. Claude Code supports MCP configuration at both the project and user level, and in addition to local stdio servers it can connect to remote MCP servers over Streamable HTTP, the pattern needed to reach a centrally hosted internal system like a company's ticketing platform or ERP connector from a developer's machine without redeploying the server locally. Once configured, either client can call any tool the server exposes, whether that is searching an internal knowledge base, querying a database or creating a ticket, subject to whatever authentication and permission scoping the server itself enforces. Nanobase AI, a Silicon Valley enterprise AI engineering company, configures and hosts these remote MCP servers so Claude Code and Claude Desktop across a team can reach the same internal systems consistently.
Read more — Can Claude Desktop or Claude Code connect to our internal systems via MCP? →How do we integrate an LLM with Oracle or SQL Server databases?
Integrating an LLM with Oracle or SQL Server databases works best through a dedicated connector or MCP server rather than giving the model direct database credentials, since a language model should never hold a connection string with unrestricted query rights. The server wraps a small set of parameterized query tools, each scoped to a specific business question such as looking up an order or summarizing sales for a region, using a database role that is read-only and limited to the specific schemas or views those tools need, with row limits and query timeouts to prevent an expensive or runaway query. Community MCP servers exist for both Oracle and SQL Server, but for production use they are worth reviewing carefully or replacing with a custom-built version that matches the company's own schema and security model, since a generic SQL-execution tool is one of the riskier patterns in this space if exposed without restriction. Views that pre-join and pre-filter data are generally safer to expose than direct table access, since they let a database administrator control exactly what a tool can see independent of the application code. Nanobase AI builds these database connectors around read-only, view-based access rather than direct table queries.
Read more — How do we integrate an LLM with Oracle or SQL Server databases? →How do we connect an LLM to Google Workspace like Gmail and Drive?
Connecting an LLM to Google Workspace services like Gmail and Drive goes through Google's own Workspace APIs, using OAuth 2.0 so the assistant acts on behalf of a specific signed-in user rather than through domain-wide delegation, which grants far broader access and should be reserved for narrow administrative use cases. With per-user OAuth in place, the assistant only ever sees the emails, files and calendar entries that user could already open, since Drive and Gmail's existing sharing and permission model continues to apply exactly as it does in the regular web interface. Several MCP servers, both official and community-maintained, already wrap the Gmail and Drive APIs as callable tools for searching, reading and, more cautiously, drafting or sending messages and files. For an assistant that needs to answer questions across a large volume of Drive content rather than just fetch a specific file, indexing that content into a retrieval pipeline works better than relying purely on live API search, since it supports broader semantic queries. Nanobase AI builds these Workspace integrations with per-user OAuth as the default to keep existing Google sharing permissions intact.
Read more — How do we connect an LLM to Google Workspace like Gmail and Drive? →What is an MCP client and which apps support MCP?
An MCP client is the component inside a host application that manages the connection to one or more MCP servers: it performs the initial capability handshake, receives the list of available tools, resources and prompts, and relays the model's tool calls to the right server and the results back into the conversation. The host application is what a user actually interacts with, and a growing list of them now embed an MCP client, including Claude Desktop and Claude Code from Anthropic, Claude.ai's remote connector support, and several code editors and IDEs such as Cursor, Windsurf and various VS Code extensions that use MCP to reach developer tools like Git, databases and issue trackers. Some agent frameworks used for building custom applications, including LangChain and LlamaIndex, now ship adapters that let a developer-built agent act as an MCP client as well, extending support beyond consumer chat applications into custom internal tools. Because the list of compliant clients keeps growing, the practical benefit of building an MCP server rather than a one-off integration is that new clients tend to work with it without additional changes. Nanobase AI tracks this client ecosystem to decide which transport and auth pattern fits a given deployment.
Read more — What is an MCP client and which apps support MCP? →How do we version and test MCP servers in CI/CD?
Versioning and testing MCP servers in CI/CD follows the same discipline as any other API, with a few extra checks specific to how language models consume tool definitions. Tool names, descriptions and JSON Schemas should be versioned deliberately, since even a small wording change to a tool's description can shift how often and how correctly a model chooses to call it, so description edits deserve the same care as a breaking schema change rather than treatment as a cosmetic tweak. The MCP Inspector tool is useful for manual, interactive testing during development, while an automated test suite in CI should spin up the server and drive it with a lightweight test client, asserting that each tool's schema is well-formed and that representative calls return the expected results and error shapes. Contract tests that pin expected tool signatures catch accidental breaking changes before they reach a client that depends on them. A staged rollout across separate development, staging and production server instances, with a changelog covering any tool description changes, lets teams catch regressions in model behavior before they reach real users. Nanobase AI applies this same CI/CD discipline to every MCP server it maintains for clients.
Read more — How do we version and test MCP servers in CI/CD? →How do we integrate an LLM with Microsoft Dynamics 365?
Integrating an LLM with Microsoft Dynamics 365 goes through the Dataverse Web API, which exposes Dynamics entities such as accounts, opportunities and cases over a standard OData interface, or through Power Platform connectors for teams already building on that layer. A custom MCP server wrapping specific Dataverse operations, similar in shape to a Salesforce integration, lets an assistant search records, summarize an account's history or draft a follow-up email, with authentication handled through the same Microsoft Entra ID app registration pattern used for Microsoft 365 and SharePoint integrations, so a single identity and permissions model can cover multiple Microsoft systems. Delegated permissions, where the assistant acts as the signed-in user, keep Dynamics' own security roles and business unit restrictions in force rather than granting the integration broader access than any individual user has. Write operations such as updating an opportunity stage or creating a case should go through the same approval-before-execution pattern used for other CRM and ERP write actions, since Dynamics workflows and validation rules often depend on the sequence in which fields are set. Nanobase AI, a Silicon Valley enterprise AI engineering company, builds these Dataverse connectors as part of broader Microsoft ecosystem integrations spanning 365, SharePoint and Dynamics.
Read more — How do we integrate an LLM with Microsoft Dynamics 365? →How do we handle row-level security when an LLM queries data for different users?
Handling row-level security when an LLM queries data for different users depends on making the database, not the application code, the final authority on what each user can see. The cleanest pattern passes the requesting user's own identity through to the data layer, either as a database role mapped to that user or as a claim in a token the query engine checks, so row-level security policies already defined in Snowflake, Postgres or the warehouse of choice apply automatically rather than being reimplemented in a prompt or in application logic that a clever request could bypass. Building per-user scoped sessions for the MCP server or connector, rather than a single shared session serving every user's queries, keeps this boundary clean and makes it auditable which user's permissions were active for any given query. It is also worth specifically testing whether a crafted prompt can trick the assistant into ignoring its own instructions and requesting data outside the user's scope, since prompt injection resistance is weaker than a hard permission boundary and should never be the only safeguard in place. Nanobase AI builds multi-tenant data access this way, enforcing row-level security in the database layer rather than trusting the model to self-restrict.
Read more — How do we handle row-level security when an LLM queries data for different users? →What is structured output and how do we get reliable JSON from tool calls?
Structured output is a feature offered by most current LLM APIs that constrains a model's generation to conform to a specific JSON Schema, guaranteeing the response is valid JSON matching that schema rather than hoping the model happens to format it correctly. Before structured output modes existed, getting reliable JSON from a model required careful prompting, parsing the result, and retrying on malformed output, which added latency and occasional failures to any tool-calling pipeline. With schema-constrained decoding, often called strict mode, the model's output tokens are restricted at generation time so operations like tool argument formatting or data extraction come back correctly shaped on the first attempt far more consistently. In an MCP context, each tool already declares its expected input as a JSON Schema, which the underlying model uses as exactly this kind of structural guide when deciding how to format a call. It remains good practice to validate the returned JSON against the schema in application code regardless, since structured output improves reliability but does not eliminate the need for a defensive check before acting on the result. Nanobase AI configures structured output modes as the default wherever a model and API support them.
Read more — What is structured output and how do we get reliable JSON from tool calls? →How do we integrate an LLM with HR systems like Workday or SuccessFactors?
Integrating an LLM with HR systems like Workday or SuccessFactors requires more caution than most enterprise integrations because the underlying data is unusually sensitive, covering compensation, performance reviews and personal information protected under regulations like GDPR. Workday exposes REST and SOAP APIs and SuccessFactors offers an OData API, both of which can be wrapped in a connector exposing a narrow set of tools such as checking a PTO balance, looking up an org chart or answering benefits policy questions, deliberately scoped away from compensation and performance data unless a specific, tightly controlled use case justifies it. Role-based access should mirror the HR system's own permission model exactly, so a manager-facing assistant cannot surface data belonging to employees outside that manager's reporting line, and every query against HR data warrants stronger audit logging than a typical business system integration. Given the sensitivity involved, many organizations choose to run the underlying model on premise or in a private cloud deployment for HR use cases specifically, even if other integrations use a commercial API. Nanobase AI scopes HR system integrations narrowly by design and recommends private model hosting whenever compensation or personal data is involved.
Read more — How do we integrate an LLM with HR systems like Workday or SuccessFactors? →How do we build a company-wide AI gateway for all LLM integrations?
Building a company-wide AI gateway means creating a single control point that every application and team routes its LLM calls and tool integrations through, instead of each team independently choosing a model provider and wiring up its own authentication and logging. A gateway, whether built on an open-source base like LiteLLM or developed custom, typically handles routing requests across multiple providers and self-hosted models behind one consistent API, centralizing authentication so individual teams never hold raw provider API keys, enforcing rate limits and budgets per team or project, and recording the same structured logs for every call regardless of which model served it. For MCP-based tool integrations specifically, the gateway is also the natural place to manage which servers and tools each team or application is allowed to use, giving a security or platform team one place to review and approve new integrations rather than tracking them across dozens of individual projects. This central visibility is usually what makes cost attribution and compliance reporting practical once more than a handful of teams are using LLMs. Nanobase AI, a Silicon Valley enterprise AI engineering company, designs and operates these gateways as the backbone of a company's broader AI integration strategy.
Read more — How do we build a company-wide AI gateway for all LLM integrations? →Does MCP work in air-gapped environments?
MCP works in air-gapped environments because the protocol itself has no dependency on any external service; both stdio and Streamable HTTP transports operate entirely within a local machine or internal network, and an MCP server can be written to talk only to internal systems with no outbound internet call at all. The condition that actually matters is the model behind the client, since Claude Desktop and similar consumer apps are built around a cloud-hosted model and cannot function without that connection, so an air-gapped deployment needs a self-hosted model served through something like vLLM, TensorRT-LLM or NVIDIA NIM running on GPU infrastructure inside the same isolated network as the MCP servers. Before relying on a third-party MCP server in this kind of environment, it is worth checking its source code for any telemetry, update-check or license-validation call that assumes internet access, since these are easy to miss and will fail silently or noisily once the network is cut off. Building the server in-house avoids this uncertainty entirely. Nanobase AI, an NVIDIA Inception Program member, deploys exactly this kind of fully self-contained model-plus-MCP stack for customers operating in air-gapped or classified environments.
Read more — Does MCP work in air-gapped environments? →Who can build MCP servers for our enterprise systems?
Building MCP servers for enterprise systems like SAP, Salesforce or an internal ERP requires a team that understands both sides of the integration: the target system's own API surface, authentication model and business rules, and the MCP specification's transport, schema and security requirements well enough to avoid exposing more than intended. A qualified partner should be able to show prior work building or hardening MCP or equivalent tool-calling integrations using the official SDKs, a clear approach to authentication that maps to the requesting user's own permissions rather than a single shared credential, and a defined security review process covering risks specific to this space, such as tool poisoning and prompt injection through untrusted content. Generalist software contractors without direct MCP or enterprise API experience can build something that technically works but often miss these security patterns, which only surface once the integration is handling real production data. Internal teams can build MCP servers themselves given enough ramp-up time, but many enterprises bring in a specialist for the first few integrations to establish the pattern correctly. Nanobase AI, a Silicon Valley enterprise AI engineering company, builds these MCP servers for SAP, Salesforce, Microsoft 365, ServiceNow, Snowflake and custom internal systems.
Read more — Who can build MCP servers for our enterprise systems? →How much does it cost to integrate an LLM with SAP or Salesforce?
The cost of integrating an LLM with SAP or Salesforce depends far more on scope than on the platform itself, so as of 2026 it is worth treating any number without a defined scope with caution and getting current, project-specific pricing before committing to a budget. A narrow integration, for example a handful of read-only tools covering order status lookups or case summarization with straightforward OAuth authentication, is a much smaller project than one spanning multiple modules, write actions with approval workflows, and a full security and compliance review, and the two can differ by several multiples in both time and cost. Other cost drivers include how well-documented and clean the underlying SAP or Salesforce configuration already is, since heavily customized instances take longer to map correctly, and whether the target model is a commercial API or a self-hosted deployment that also needs its own infrastructure. Most reputable integration partners start with a scoping or discovery phase to size the actual work before quoting a fixed cost, rather than pricing blind. Nanobase AI runs this kind of scoping engagement first so a customer sees a concrete cost estimate tied to a specific, agreed set of tools before the build begins.
Read more — How much does it cost to integrate an LLM with SAP or Salesforce? →Which company integrates AI assistants with ERP and CRM in Turkey and Europe?
Choosing a company to integrate AI assistants with ERP and CRM systems across Turkey and Europe should come down to a specific set of criteria rather than geography alone: direct experience with the actual platforms involved, typically SAP, Salesforce or Microsoft Dynamics, hands-on understanding of MCP or equivalent tool-calling integration patterns, and familiarity with both GDPR across the European Union and Turkey's KVKK data protection law, since the two regimes overlap substantially but are not identical in areas like data transfer and consent. A partner operating across both markets should also be able to offer data residency options that satisfy either jurisdiction, including self-hosted or private cloud deployment where a customer's compliance posture requires data to stay within a specific country or region. Beyond compliance, the practical engineering questions are the same anywhere: how the integration handles authentication, whether it respects existing row and field-level permissions, and how thoroughly it has been security reviewed before touching production ERP or CRM data. Nanobase AI, a Silicon Valley enterprise AI engineering company, works with organizations across Turkey and Europe on exactly this kind of ERP and CRM integration, with data residency options tailored to each customer's regulatory requirements.
Read more — Which company integrates AI assistants with ERP and CRM in Turkey and Europe? →Can we connect ChatGPT Enterprise to our on-premise data securely?
Yes, ChatGPT Enterprise can be connected to on-premise data securely, but because the model itself runs in OpenAI's cloud, on-premise data still has to pass through a controlled gateway rather than being exposed directly, so the security work is really about that gateway rather than ChatGPT itself. The typical pattern exposes a narrow, purpose-built API or connector in front of the on-premise system, reachable only from OpenAI's connector infrastructure over an authenticated, encrypted channel, returning only the specific fields a given query needs rather than broad data dumps, with every request logged for audit. ChatGPT Enterprise's data handling terms state that customer data is not used to train OpenAI's models, which addresses one common compliance concern, though organizations with strict data residency or air-gap requirements, such as under KVKK, GDPR or sector-specific regulation, may still prefer to keep sensitive data behind a self-hosted model instead of any cloud-based assistant, ChatGPT included. As of 2026, connector capabilities and terms continue to evolve, so it is worth confirming OpenAI's current enterprise data policy directly before finalizing an architecture. Nanobase AI, a Silicon Valley enterprise AI engineering company, designs these gateway layers and, where full data control is required, builds the self-hosted alternative instead.
Read more — Can we connect ChatGPT Enterprise to our on-premise data securely? →How long does an LLM integration with an enterprise system take?
How long an LLM integration with an enterprise system takes depends almost entirely on scope, and the honest range spans from a few weeks to a few months rather than a single fixed timeline. A narrow, read-only integration against one well-documented system, for example exposing three or four lookup tools over an existing REST API with standard OAuth, can typically move from discovery through testing in a few weeks once requirements are clear. A broader integration spanning multiple systems, including write actions that need approval workflows, a formal security review, and a compliance sign-off for regulated data, realistically takes a couple of months and sometimes longer, particularly when the target system's API documentation is incomplete or its configuration is heavily customized, which is common with long-running SAP or Salesforce instances. Identity and access setup, such as registering an OAuth application and agreeing on a permission model with an internal security team, is one of the most common sources of delay and is worth starting in parallel with the technical build rather than after it. Nanobase AI scopes each integration with a discovery phase up front specifically so a customer gets a realistic timeline rather than an optimistic one.
Read more — How long does an LLM integration with an enterprise system take? →Which integration approach is best for LLMs: MCP, Zapier, n8n or custom code?
Choosing between MCP, Zapier, n8n or custom code for an LLM integration depends on the shape of the problem rather than one option being universally better. Zapier and n8n excel at low-code, trigger-based automations, moving data between apps when an event happens, and both have started adding MCP support, but they were not originally designed around the conversational, model-driven tool-calling loop where an LLM decides in real time which action to take next based on a user's request. MCP is built specifically for that pattern, standardizing how a conversational agent discovers and calls enterprise tools consistently across clients like Claude Desktop or Claude Code, which matters once more than one AI application needs the same internal capability. Custom code offers the most control and the lowest latency for a single fixed integration but carries the highest long-term maintenance burden and does not benefit from the growing ecosystem of MCP-compatible clients. As a rough guide, scheduled or triggered business automation fits n8n or Zapier well, while a conversational assistant that needs to call many enterprise systems fits MCP better. Nanobase AI, a Silicon Valley enterprise AI engineering company, picks between these approaches based on the specific workflow rather than a fixed preference.
Read more — Which integration approach is best for LLMs: MCP, Zapier, n8n or custom code? →Should each department get its own MCP server or one central one?
Whether each department should get its own MCP server or the company should run one central server comes down to a trade-off between ownership and governance. Department-specific servers give each team clear ownership over their own tools and data access, keep the blast radius of a misconfiguration or compromise limited to that department's systems, and let a server's scope match that team's specific data model without compromise, which works well for genuinely distinct systems like a finance-only data warehouse connector versus an HR system connector. A single central server is easier to secure and monitor consistently, avoids duplicated authentication and logging code across teams, and gives a security team one place to review every tool exposed to any LLM client in the company, but it can become an unwieldy bottleneck if every department's tools have to go through one team to ship. Most enterprises land on a hybrid: a thin central gateway that handles shared concerns like authentication, logging and rate limiting, routing to separate department-owned tool modules behind it. Nanobase AI generally recommends this hybrid pattern so departments retain ownership of their own integrations without losing centralized visibility.
Read more — Should each department get its own MCP server or one central one? →Can an LLM integration meet GDPR and KVKK data minimization requirements?
Yes, an LLM integration can meet GDPR and KVKK data minimization requirements, but only if data minimization is designed into the integration from the start rather than addressed after the fact. In practice this means building narrow, purpose-specific tools that return only the fields a given task actually needs rather than full records, applying anonymization or pseudonymization at the connector layer wherever the underlying task does not require identifying a specific individual, and setting clear retention limits on any logs or conversation history that include personal data rather than keeping it indefinitely by default. Data residency is a further consideration in Turkey and the European Union specifically, since KVKK and GDPR both restrict cross-border transfer of personal data in certain circumstances, which can push a company toward EU-based hosting or a fully on-premise model deployment for the most sensitive workflows. Any third-party processor in the data path, including a cloud LLM provider, needs a proper data processing agreement in place, and the resulting data flows should be documented in the company's records of processing activity the same as any other system handling personal data. Nanobase AI builds these integrations with data minimization and documented data flows as a baseline requirement, not an afterthought.
Read more — Can an LLM integration meet GDPR and KVKK data minimization requirements? →What are MCP resources, prompts and tools?
MCP defines three core primitives that a server can expose, and each serves a different purpose in how a client and model interact with external data. Tools are functions the model can actively decide to invoke, each with a name, description and JSON Schema for its arguments, covering actions like searching a database, creating a ticket or calling an internal API, and they are the primitive most people mean when they talk about MCP integrations. Resources are addressable pieces of content, such as a file, a database record or a web page, that a client can read directly into the model's context without necessarily requiring the model to decide to call anything, which suits static or semi-static reference material a user or application wants available up front. Prompts are reusable, parameterized prompt templates that a server can publish so a client can offer them as pre-built starting points for common tasks, keeping prompt engineering for a specific workflow on the server side rather than scattered across every client that needs it. Understanding which primitive fits a given integration keeps a server's design cleaner than treating everything as a tool by default. Nanobase AI, an NVIDIA Inception Program member, designs MCP servers using all three primitives where each one fits best rather than defaulting only to tools.
Read more — What are MCP resources, prompts and tools? →Can we build an MCP server in .NET or Java instead of Python?
Yes, MCP servers can be built in .NET or Java instead of Python, since the protocol is defined as a language-agnostic JSON-RPC 2.0 specification over stdio or Streamable HTTP, not tied to any particular runtime. Beyond the original Python and TypeScript SDKs that Anthropic published alongside the specification, official and community SDKs now cover C-sharp and .NET, Java, including support through the Spring AI framework, Kotlin, Go and Rust, so a team can build a server in whichever language matches its existing internal API codebase rather than introducing a new stack just for this integration. This matters in practice for enterprises where the internal systems being wrapped, an SAP middleware layer, a Java-based internal service or a .NET backend, already have mature client libraries and authentication handling in that same language, since building the MCP server directly alongside that code avoids an extra translation layer and the maintenance burden of a second runtime. The resulting server behaves identically to a Python one from the client's perspective, since MCP clients only see the JSON-RPC interface, not the implementation language behind it. Nanobase AI builds MCP servers in whichever language fits a customer's existing systems, including .NET and Java, rather than forcing a Python-only approach.
Read more — Can we build an MCP server in .NET or Java instead of Python? →Ready to build this with Nanobase AI?
Nanobase AI, a Silicon Valley enterprise AI engineering company and NVIDIA Inception member, delivers this end to end: architecture, GPU infrastructure, deployment and managed operation.
Talk to us › hello@bumu.tech