How MCP Connects AI Agents to Business Tools

How AI agents use MCP servers to reach CRMs, databases and internal systems — architecture, permission design, authentication, and a worked example.

Nexora Editorial TeamPublished Sep 11, 20263 min read

FIG. 20 · AGENT TOOL ACCESS VIA MCP

HOSTAI App / Agent

PROTOCOLMCP Servertools · resources · auth

HubSpot

Postgres

Google Drive

Billing API

Diagram of an AI agent calling an MCP server, which brokers scoped access to HubSpot, Postgres, Google Drive and a billing API.

An AI agent is only as useful as the tools it can reach. MCP gives agents a standard way to find and call those tools, while letting you control exactly what each agent can see and do. This article walks through how that connection works in a real business setup and the design decisions that keep it safe.

If MCP is new to you, start with What Is MCP?.

The architecture

Agent — the model plus its instructions, running in your application or an MCP-compatible host.
MCP client — connects the agent to one or more servers.
MCP servers — one per system or domain (CRM, database, documents, billing).
Business systems — the real APIs and databases behind each server.

When the agent starts, it asks each server what tools are available. During a conversation, it chooses a tool, the server validates the request and calls the real system, and the result returns to the agent.

Designing tools agents can use well

Agents choose tools from their names and descriptions, so design matters:

Task-shaped, not endpoint-shaped. "find_customer_by_email" beats exposing a generic "GET /contacts".
Clear descriptions with when to use and when not to.
Small, validated inputs. Reject malformed requests at the server.
Concise outputs. Return what the agent needs, not full records.

Permission design

Level

Example tools

Controls

Read

search_contacts, get_order

Scoped to relevant records

Write (low risk)

add_note, create_task

Logged

Write (consequential)

update_deal_value, issue_refund

Human or user confirmation

Never exposed

delete_account, export_all

Not available to AI

Authentication patterns

Service credentials for internal agents acting as the organisation.
Per-user OAuth when the agent acts on behalf of a specific person, so it inherits that person's permissions.
SSO and roles in larger organisations, mapping teams to allowed tools.

A worked example

A sales assistant agent for a B2B company:

CRM server: find contact, get deal history, add note, create follow-up task.
Docs server: search approved case studies and pricing sheets.
Calendar server: check rep availability, create meeting.

A rep asks: "Prep me for my 2pm with Acme and book a follow-up next week." The agent gets the contact and deal history, finds relevant documents, drafts a brief, checks availability and proposes a slot. Creating the meeting requires the rep's confirmation.

Safety considerations

Prompt injection: text returned by tools (emails, web pages, documents) can contain instructions. Treat tool output as data, and keep consequential actions behind confirmation.
Least privilege: each agent connects only to the servers it needs.
Audit logs: record every tool call with who, what and when.
Rate limits: prevent loops from hammering your systems.

Where to start

Pick one agent use case, list the tools it genuinely needs, and build one MCP server with read-only tools. Add write tools once transcripts show they're needed. For choosing between MCP and a direct integration, see MCP vs API.

Nexora Editorial TeamEngineering & StrategyGuides written and reviewed by the engineers who scope and build Nexora projects. We write about what we actually implement: automations, agents, integrations and production software.