MCP Servers Explained: How to Connect AI to Your Business Tools

what an MCP server actually is#

the problem it solves: AI agents that can reason but cannot act#

An AI agent that can reason but can't read your actual data is useful for generic tasks and not much else. Give it access to your CRM, your database, your internal APIs, and suddenly it's useful for work that actually matters to you.

Before MCP existed, connecting an AI agent to a business tool meant building a custom integration for each one: parse the API docs, write the connector, handle authentication, format the output so the model could reason over it. Multiply that by every tool in your stack and you have a serious maintenance problem. Most teams building AI workflows know this feeling.

MCP (Model Context Protocol) replaces that per-tool integration work with a standard. Build one MCP server per tool, and any MCP-compatible agent can use it.

the one-sentence definition#

An MCP server is a program that exposes your business tools (CRMs, databases, ERPs, internal APIs) to AI agents using a standardized protocol, so the AI can read data from them and trigger actions through them without custom per-tool integration code.

from Anthropic's protocol to open infrastructure#

Anthropic introduced MCP in November 2024. By December 9, 2025, they had donated it to the Agentic AI Foundation (AAIF) under the Linux Foundation, co-founded with OpenAI and Block, with AWS, Google, Microsoft, Cloudflare, and Bloomberg as platinum members (Linux Foundation, December 2025).

That's a meaningful shift. A protocol controlled by one AI lab is a bet on that lab. A protocol governed by a Linux Foundation entity with that membership list is more likely to still matter in five years. Whether the governance structure lives up to its promise is another question, but the cross-industry backing is real. As of December 2025, the ecosystem has over 10,000 published servers and 97 million monthly SDK downloads across Python and TypeScript (Anthropic / Linux Foundation, December 2025). Claude Agent SDK, OpenAI Agents SDK, Google ADK, and LangGraph all support it.

tools, resources, and prompts#

Every MCP server exposes some combination of three primitive types.

tools: actions the AI can trigger#

Tools are callable functions. The AI sends a request with parameters, the server executes it, and returns the result.

Examples:

• create_contact(name, email, company) -- creates a record in your CRM
• run_query(sql) -- executes a SQL query and returns results
• send_message(channel, text) -- posts to a Slack channel
• create_issue(title, body, labels) -- opens an issue in your project tracker

Tools are how the agent acts. Without them, the agent can only think.

resources: data the AI can read#

Resources expose data the AI can pull into its context and reason over. Unlike tools, they don't execute an action; they provide information.

Examples:

• Product documentation, so the AI can reference it when writing code
• Customer account data, for a support agent to read before responding
• A database schema, so the AI knows the structure before writing queries
• Internal wikis or meeting notes, for research workflows

If tools are how the agent acts, resources are how it learns what's true before deciding what to do.

prompts: templates for specific workflows#

Prompts are predefined templates that guide the AI through a particular task. They're the least talked-about of the three, but useful for making repeated workflows predictable. An MCP server for a support tool might include a handle_refund_request template that specifies what data to check, what policy to apply, and how to format the response.

how the interaction actually works#

The loop between an agent and an MCP server is worth understanding in detail, because it's where most of the interesting questions come up in practice.

When the host application starts (Claude Code, a custom agent framework, whatever you're using), it connects to the configured MCP servers. The server immediately sends back a capability manifest: here are my tools, here are my resources, here are my prompt templates. The agent reads this and knows what it can do.

From there, when the agent is working through a task and needs data or needs to act, it reasons over the manifest and picks the right tool or resource. This isn't hardcoded logic; the agent's LLM backbone reads the tool descriptions and decides what to call. It sends a request with parameters, the server executes against the underlying system (the database, the API, the file), and returns a structured response the model can work with.

That loop can run many times in a single task. A research workflow might call a search tool, read results, call a notes tool, check existing notes, decide what to add, and write the update -- all before the user sees anything. Where this gets messy in practice is when tools fail, return unexpected data, or when the agent calls the wrong thing and needs to backtrack. MCP doesn't solve those problems; it just means you're dealing with them through a standard interface rather than a bespoke one.

real examples: MCP connecting AI to business tools#

CRM integration: Salesforce and HubSpot#

HubSpot launched its production MCP integration in June 2025, letting AI clients query live CRM data in natural language. Salesforce followed with hosted MCP servers in beta by October 2025 (HubSpot / Salesforce, 2025).

With one of these connected, an AI agent can look up a contact's full account history before a call, create or update records from meeting notes, pull deal pipeline data into a weekly report, or search for accounts matching specific criteria without the user constructing filters manually.

The part worth noting: the AI doesn't need to know the CRM's API in advance. It reads the manifest at connection time, figures out what's available, and formats the calls itself. You describe what you want; it figures out how to ask for it.

ERP integration: Dynamics 365#

Microsoft introduced a Dynamics 365 MCP server at Build 2025, giving AI agents access to journal entries, transaction validation, and KPIs across Finance, Supply Chain, and HR modules without custom integration code (Microsoft, November 2025).

For finance teams, this is the interesting case: an agent that can pull KPIs, generate variance explanations, and flag anomalies in financial data -- without someone running SQL queries or clicking through the Dynamics UI to extract numbers first.

database integration#

Database MCP servers are probably the most widely deployed right now, and the use case is direct. One mid-sized e-commerce company connected MCP to their PostgreSQL database and cut reporting time from two days to two minutes (DEV Community / Unified.to, 2025).

The basic setup exposes a run_query tool plus schema-exploration tools like list_tables and describe_table. The agent can answer questions in plain language, generate SQL against the actual schema, and produce formatted reports. The schema tools matter more than they sound: an agent that can inspect the real schema writes much better queries than one working from documentation that may be months out of date.

AAA Washington deployed an Agentforce agent on Salesforce MCP servers, cutting average call handle time by 40% while resolving 85% of inquiries without human involvement (Salesforce, 2025).

internal tools with no off-the-shelf server#

The most useful tools in any given company are usually the ones nobody has built a public connector for: a proprietary order management system, an internally built ticketing tool, a custom analytics platform. These require custom MCP servers, and there's no way around it.

The build is still less work than a bespoke AI integration, because the protocol handles discovery, transport, and response formatting. You write the business logic: what tools to expose, what data to surface, what the agent is allowed to modify. The protocol does the rest. That said, "less work than before" and "easy" are not the same thing, especially once you add authentication and access scoping.

MCP vs. a standard API integration#

Three real differences, not three invented categories.

The first is discovery. A standard integration requires hardcoded logic telling the AI what tools exist and how to use them. Change the API and you update the integration code. With MCP, the server advertises its capabilities dynamically at connection time. Add a new tool to the server and the agent knows about it next time it connects.

The second is output formatting. API responses are designed for applications. Raw CRM JSON is accurate but not organized for a model trying to reason about it. MCP servers can format responses explicitly for AI consumption: structured, labeled, with context about what the data means. The difference shows up in how reliably the model reasons over the result.

The third is maintenance. Every custom integration is its own debt. It needs updates when the API changes, when the auth method changes, when the agent framework updates. MCP servers separate the tool implementation from the agent. Update the server when the underlying API changes; update the agent framework when the AI platform changes. They evolve on their own schedule.

when a pre-built server is enough, and when it isn't#

For standard SaaS tools (Salesforce, HubSpot, GitHub, Slack, Google Workspace, Jira, Linear, Postgres, MySQL) there are community or vendor-built servers available. The official @modelcontextprotocol/ packages from Anthropic cover a lot of common integrations. Check the registry before building.

Custom builds are necessary for anything your company built internally, any heavily customized SaaS deployment, or any data system with a proprietary schema. A generic Salesforce connector knows about standard objects and fields. If your Salesforce instance has 40 custom fields, custom objects, and process-specific record types, the generic server won't know any of that exists.

what production actually requires#

Getting an MCP server working in a demo takes a few hours. Getting one running reliably in production, with real users and real consequences if it misbehaves, is a different project.

Authentication is more involved than it looks. You need credential rotation, OAuth flows for per-user auth, and graceful handling of token expiration. Access scoping is easy to get wrong: by default you don't want your agent to have write access to everything in your CRM, and the scope you grant needs to be documented clearly so you know what each workflow can actually modify.

Error handling is where most custom builds fall apart. What happens when the API returns a 500? When it times out? When the response format changes slightly? The agent needs to handle these without looping, failing silently, or taking a wrong action on stale data.

Security is worth taking seriously. Researchers identified active risks in April 2025: prompt injection via tool descriptions, over-permissive scopes, and lookalike tool substitution attacks (Zuplo MCP Security Report, 2025). These are mostly concerns for custom builds with access to sensitive data, not for standard off-the-shelf servers. But if you're building an MCP server that touches customer data or can modify financial records, you need to think through the threat model.

Silverthread Labs builds production MCP servers for teams connecting AI agents to internal tools. If you have a system that needs to be in scope for your AI workflows and no public server covers it, reach out through the audit page to talk through what the build would involve.

Frequently Asked Questions#

What is an MCP server and what does it do?

An MCP server is a program that exposes your business tools to AI agents using a standardized protocol. It gives the AI a consistent way to discover what a tool can do, call its functions, and read its data, without requiring custom integration code for each tool. The agent connects to the server at startup, reads its capability manifest, and can then use its tools and resources during task execution.

How do MCP servers connect AI to a CRM or database?

An MCP server wraps your CRM or database with the MCP protocol. It exposes specific operations as tools (e.g., query_contacts, create_deal) and data as resources (e.g., the account record for a specific company). When the AI agent needs CRM data or needs to create a record, it calls the appropriate tool through the MCP server, which handles the actual API call or SQL query and returns a structured result.

What is the difference between MCP and a regular API integration?

A standard API integration requires hardcoded logic that tells the AI exactly what's available and how to call it. MCP servers advertise their capabilities at connection time, format responses for AI consumption, and can be updated independently from the agent framework. The practical benefits are less maintenance work and more reliable model reasoning over the returned data.

Which business tools support Model Context Protocol?

As of early 2026: Salesforce, HubSpot, Microsoft Dynamics 365, GitHub, Slack, Google Workspace, Jira, Linear, PostgreSQL, MySQL, MongoDB, and many others via community-built servers. The @modelcontextprotocol/ package registry and the community ecosystem cover hundreds of integrations. Tools without a public server require custom builds.

Do I need a custom MCP server or can I use a pre-built one?

For popular SaaS tools in standard configurations, a pre-built server is usually fine to start with. For internal tools, heavily customized SaaS deployments, or workflows that need specific data handling or access scoping beyond what a generic server provides, you need a custom build. The practical test: does the pre-built server actually expose the data and actions your workflow needs, or does it expose a standard subset that misses what you care about?