How to connect Claude to almost any business system with MCP

Claude becomes substantially more useful when it can retrieve approved context and take bounded action in the systems where work happens. The connection should not be a broad key that lets a model explore an account. It should be a small, understandable set of tools designed around a real job.

The Model Context Protocol, or MCP, provides a standard way for an AI application to discover tools, resources and prompts exposed by a server. In the protocol’s client-server architecture, a host such as Claude creates a client connection to one or more MCP servers. A local server can communicate through standard input and output. A remote server can use Streamable HTTP and an appropriate authentication flow. The protocol creates interoperability, but it does not decide which data the model should see or which actions are safe. That remains an architecture responsibility.

This guide describes the process I use to connect Claude to a business system without turning the integration into an ungoverned experiment.

Step 1: define one useful job

Begin with an outcome stated in business language. “Connect Claude to HubSpot” is not an outcome. “Prepare a renewal brief from an approved company record and its open deals” is. The second statement identifies a user, a trigger, likely data and an inspectable result.

Write the current process from start to finish. Note every system opened, field read, judgement made, action taken and exception handled. Measure the time and error rate where possible. Ask what happens when a record is incomplete, two sources disagree or the requested company does not exist.

Then split the process into three kinds of work:

1. Deterministic work follows explicit rules. A normal workflow or API function should perform it.
2. Interpretive work benefits from language understanding, classification or synthesis. This is where a model can help.
3. Consequential work changes a customer, financial, legal or public state. It often requires validation or human approval.

This separation prevents the common mistake of asking the model to reason through steps that ordinary software can execute more reliably.

Step 2: choose the connection pattern

There are four practical patterns.

Use an official remote MCP server when the system owner provides one with the tools, authentication and account controls you need. This reduces custom protocol work. Review its scopes, logging, data handling, limitations and change policy. HubSpot, for example, documents a remote MCP integration that uses OAuth and account-authorised capabilities. Availability and supported actions should always be checked against the current documentation.

Expose an existing automation as MCP tools when n8n, Make or Zapier already contains governed workflows. The AI calls a narrow tool such as prepare_campaign_brief, while the automation platform handles connectors, retries and deterministic steps. This is often faster than rebuilding every integration.

Build a custom MCP server when the system is internal, its API needs domain logic or the tool must enforce specialised permissions. The server becomes an anti-corruption layer between the model and the raw application. It translates a clear tool call into validated internal operations.

Use a direct application integration when MCP adds no meaningful reuse. A fixed form that sends one structured request to one endpoint may need an ordinary API call, not a general tool protocol. Architecture should follow the job, not fashion.

For shared cPanel hosting, do not run a persistent MCP server inside the website account. Keep the public site static and use PHP only for small form endpoints. Place remote MCP or AI execution in a managed service, an existing automation platform or suitable serverless infrastructure. The website can call that controlled backend, while the cPanel host stays lightweight.

Step 3: design narrow tools

A raw run_sql or call_any_api tool gives the model too much freedom and makes review difficult. Prefer domain tools:

• find_company_by_domain returns a small, approved company summary;
• list_open_deals accepts one company identifier and returns selected fields;
• draft_renewal_brief produces a structured draft without changing a record;
• request_owner_approval creates an approval item;
• update_renewal_note writes only after an approval token is supplied.

The name and description teach the model when to use the tool. Input schemas should require stable identifiers and constrain formats. Output schemas should distinguish data, status, warnings and next allowed actions. Return the smallest useful dataset. A tool asked for deal context should not include every contact email, internal note and attachment.

Avoid combining retrieval and mutation in one ambiguous tool. A read tool can be broadly available to authorised staff, while a write tool can require additional scope and approval. Explicit separation also improves testing.

Design errors as part of the contract. not_found, ambiguous_match, permission_denied, validation_failed and temporary_unavailable lead to different next steps. A generic exception encourages the model to guess or retry blindly.

Step 4: implement authentication and authorisation

Authentication establishes which person or application is connecting. Authorisation decides what that identity may do. Do not treat them as the same decision.

For remote servers, use the provider’s documented OAuth flow and request the minimum scopes. Keep tokens in the server or trusted client environment, never in prompts, content files or browser-visible configuration. Rotate secrets through the platform designed to hold them. Each environment should have separate credentials.

Authorisation must also be enforced inside each tool. If a user can access only one business unit in the source system, the tool should apply that boundary rather than expecting Claude to remember it. The server should derive tenant and user context from the authenticated session, not accept a caller-supplied tenant identifier as truth.

High-impact operations can require a short-lived approval record. The first call prepares a proposed change and returns a summary plus approval identifier. A human reviews it in a purpose-built interface. The final tool accepts the approval identifier, verifies that the proposal has not changed and performs the action once.

Step 5: separate resources from tools

MCP resources can provide context such as documentation, approved policies or a specific record view. Tools perform actions or dynamic retrieval. Use resources for material the user or application may deliberately include, and tools for operations with parameters and permissions.

Do not put an entire knowledge base into every conversation. Create searchable or addressable resources and retrieve only the relevant pieces. Attach source identifiers and update dates so the generated result can show where an important statement came from.

Prompt templates can standardise recurring interactions, but they should not hide business rules that belong in code. A prompt can explain how to structure a renewal brief. The server should enforce which records are accessible and whether a note may be written.

Step 6: build the Claude-side experience

The interface may be Claude itself, a Claude-powered internal application or a focused web screen. Choose based on the work.

A conversational interface works well when users arrive with varied questions and need to explore. A structured application works better when inputs, approvals and outcomes are repeatable. It can still use Claude for interpretation while showing evidence, tool activity and proposed changes in predictable places.

Give the model a concise role and process. Describe when it should ask a question, which tools are read-only, which action requires approval and how uncertainty must be expressed. Do not fill the system instruction with thousands of fragile business rules. Keep deterministic policy in tool code and retrieve current guidance as a resource.

Limit the enabled tools to the job. A server may expose fifty capabilities, but a renewal workflow may need four. Fewer tools reduce selection confusion, prompt size and accidental action.

Step 7: create an evaluation set

Before connecting production data, collect representative test cases. Include normal records, missing fields, duplicate companies, restricted accounts, expired deals, inconsistent currencies, long notes and malicious instructions embedded in source content.

For each case, define the expected tool sequence, prohibited actions, required facts and acceptable output characteristics. Some checks are exact: the restricted record must never be returned. Others need a rubric: the brief should identify renewal risk without inventing a probability.

Run the set after changes to model, prompt, tool description, schema or source API. Record the version and results. A successful demonstration is not an evaluation. The difficult and adversarial cases determine whether the system is ready.

Prompt injection must be tested at tool boundaries. Text retrieved from a CRM note or document is untrusted data, even when it tells the model to ignore instructions or call another tool. Label it as data, minimise available actions and enforce policy outside the model.

Step 8: add observability and cost controls

Log the authenticated actor, session or trace identifier, tool name, redacted input summary, status, latency and approval state. Do not log access tokens or full sensitive payloads. Connect calls into one trace so an operator can see how a result was produced.

Set timeouts and bounded retries. Mutating tools should be idempotent so a repeated call does not create duplicate notes or tasks. Use per-user and per-tool rate limits. Apply daily cost or action caps where unexpected loops would matter.

Monitor business measures too: time to complete the job, correction rate, approval rate, exception rate and downstream outcome. Tool-call success does not prove that the system created a useful renewal brief.

Step 9: release in stages

Start in read-only mode with a small group. Compare generated results with the existing manual process. Let users report missing context and wrong tool selection. Then enable draft creation, followed by approved writes for selected actions.

Keep a kill switch that disables mutations without taking retrieval offline. Document a manual fallback. If the MCP provider, model or source API is unavailable, the business process should degrade clearly rather than disappear.

Review permissions, logs and evaluation samples after the first week and on a regular cadence. Remove tools nobody uses. Narrow tools that return excessive data. Update descriptions when users employ a capability differently from the original design.

Example architecture: an account research assistant

Imagine a growth team preparing for a meeting. The user selects a company in an internal application. Claude receives a stable company identifier, then calls a read-only CRM tool for approved account and deal fields. A second tool retrieves recent analytics summaries keyed to the domain. A third searches an approved content library for relevant case studies.

Claude returns a structured brief with facts, source labels, open questions and suggested discussion points. It cannot send an email or update the deal. If the owner accepts the brief, a separate deterministic workflow stores the approved document and records its version. This system removes navigation and synthesis work while keeping commercial communication and CRM mutation under human control.

The surprising speed comes from orchestration: several systems are queried in seconds, the result follows one structure and missing evidence is visible. Reliability comes from the less dramatic parts: stable identifiers, small scopes, schemas, timeouts, test cases and approval.

Final checklist

Before calling the integration complete, confirm the following:

• the job and success measure are documented;
• each tool has one clear purpose, bounded inputs and minimal output;
• authentication and record-level authorisation are enforced server-side;
• secrets never enter prompts or the public website bundle;
• source content is treated as untrusted data;
• writes are idempotent and consequential actions require approval;
• logs are useful without containing unnecessary sensitive content;
• normal, failure and adversarial cases are in a repeatable evaluation set;
• the system has rate limits, timeouts, a kill switch and a manual fallback;
• an owner reviews quality and permissions after release.

MCP makes the connection pattern reusable. The quality of the final AI system still depends on the thinking around the protocol. Start with one job, expose less than the raw system offers, make every action observable and expand only after the evidence supports it.