Connect the agent to your tools with MCP

An agent that cannot reach your tools turns you into its clipboard: you export the CRM view, paste it in, copy the answer back. MCP removes that step. It is an open protocol that lets an AI client, such as Claude, Claude Code, ChatGPT or any other compatible client, call tools exposed by a server: search the CRM, read a spreadsheet, query a database, call an API. My rule for connecting one is simple. Connect only the systems the task touches, start read-only, and test every connection on a record you already know before the agent works on anything real.

What MCP changes in practice

Three parts are involved. The client is where the agent runs. The server is a small program that sits in front of one system and exposes a list of tools, each with a name, a description and the parameters it accepts. The model reads those descriptions and decides which tool to call, with which arguments, and what to do with the result.

Without MCP	With MCP
You export a CSV and paste it into the conversation	The agent queries the source when it needs to
The data is a snapshot from whenever you copied it	The data is read at the moment of the task
The agent writes a summary you then retype in the CRM	The agent proposes the update and, once you allow it, writes it
Nobody can tell which rows the agent actually saw	Each tool call is visible in the session, with its arguments

The last line matters more than it looks. When an answer is wrong, you can see whether the agent called the wrong tool, passed the wrong filter or misread a correct result. With copy and paste you only see the wrong answer. The protocol site explains the architecture if you want the detail.

List the tools your process touches

Do not connect everything you own. Go back to the process you wrote down in the chapter on starting from an existing process and, for each step, note which system it touches and whether it reads or writes.

Step	System	Read or write	Connector	Risk if wrong
Find accounts that match the ICP	Data provider	Read	Vendor MCP server	Wasted credits
Check whether the account is already a customer	CRM	Read	Vendor MCP server	Prospecting a customer
Log the qualification	Shared spreadsheet	Write	Spreadsheet MCP server	Overwritten rows
Pull last quarter’s deals	Database	Read	Database MCP server, read-only user	Slow queries on production
Create the task for the sales rep	CRM	Write	Vendor MCP server	Duplicate tasks

Say you sell payroll software to French SMEs and want an agent to qualify inbound sign-ups. That table tells you it needs three servers, two of them read-only, and exactly one write that can do damage. The empty cells are useful too: a step with no connector is either a candidate for your own MCP server or a step that stays manual for now.

Read first, write later

Every connection gets the narrowest access that lets the task run. In practice:

• Create a dedicated account or API key for the agent, never your own admin credentials. When something goes wrong you want to revoke one key, not your access.
• Give it a read-only scope for the first weeks. For a database, that means a database user that can only SELECT, on the tables the task needs.
• Add write access one action at a time, once the reads have been right on a few dozen real cases.
• Keep the agent’s client set to ask before each write call until you trust that specific action.

Secrets stay out of the instructions file and out of the conversation. They live in environment variables or in the client’s credential store. The broader rules on keys, personal data and what an agent never does alone are in the security chapter.

Configure the connection

Each client has its own place to declare servers. In Claude Code, a project can share its servers with the team through a .mcp.json file at the root of the repository, and it expands environment variables, so the file can be committed without the keys in it. A remote server is declared by its URL, a local one by the command that starts it.

{
  "mcpServers": {
    "crm": {
      "type": "http",
      "url": "https://mcp.your-crm.example/mcp"
    },
    "analytics_db": {
      "command": "npx",
      "args": ["-y", "your-database-mcp-server"],
      "env": {
        "DATABASE_URL": "${ANALYTICS_READONLY_URL}"
      }
    }
  }
}

The server names and package here are placeholders: use the ones your vendor documents. Claude Code’s MCP documentation covers the scopes (just you, the project, all your projects) and the claude mcp add command if you prefer the terminal. In a chat client such as Claude or ChatGPT, the same thing happens through a connectors screen: you paste the server URL and sign in to the tool.

One habit saves a lot of confusion. Name each server after the system it fronts (crm, analytics_db, sheets_pipeline) and write one line in the agent’s instructions saying what each one is for. Two servers that both expose a search tool will otherwise get mixed up.

Test each connection before the task

A connection that is listed is not a connection that works. Before the agent does real work, run this check for every server and write down the result.

Check	How	Passes when
The server is up	Ask the client for its server status	Connected, tools listed
The tools are the ones you expect	Read the tool list and descriptions	No surprise write tools
A read returns the truth	Ask for a record you know by heart	Same values as in the tool’s own interface
Volume is complete	Ask for a count you can verify	Count matches the source
A forbidden action fails	Ask for a write on a read-only server	The server refuses, the agent reports it
Errors are readable	Ask for a record that does not exist	A clear “not found”, not an invented record

The fourth line is the one people skip. An agent will happily report success on 200 rows when the source has 1,400, because a tool returned the first page and nothing told it there were more. The fifth line checks your permissions, not the agent’s good manners. When a scheduled routine depends on these servers, the same checks become its first step, before it does anything else.

An example: Derrick’s MCP server

I co-founded Derrick, a B2B data enrichment and prospecting tool, and I built its MCP server myself. It lets Claude, ChatGPT or any MCP client call Derrick’s data features from a conversation, from the Plus plan at €47.50 a month. A typical use is exploratory: “find companies similar to these three customers, then the head of sales at each”, on a few dozen rows, to test a targeting idea before building the full list.

It is also a good illustration of choosing the surface by the job. For a list of thousands of rows you want to filter and inspect, the web app or a spreadsheet is the better place. For enrichment inside a product or a scheduled workflow, the API is. MCP is for the work where a person and an agent think together. Building a TAM with agents shows a full run on that split.

When MCP is the wrong choice

MCP gives the model the choice of which tool to call. That is what you want when the steps depend on what the agent finds, and what you do not want when the steps never change. A nightly sync of 10,000 rows from the CRM to the warehouse is a script or a Make or n8n scenario: same input, same output, no model needed, no tokens spent. Keep MCP for the steps where judgement is the point.

Your next step: take the table of steps for your process, fill in the system, read or write, and connector for each, then connect the read-only servers first and run the six checks on each one. Keep the results; you will need them again when the agent starts running on a schedule.