Connect Claude to your business data: instructions for use

“Can we connect Claude to our customer base? » The question has come up among most sales and data teams for two years. The answer is yes, and the project is much shorter than you imagine — on one condition: having your own data index. The MCP (Model Context Protocol) protocol has standardized the entire piping section. What remains to be designed is what we put at the end of the pipe.

The principle: three bricks, not one more

MCP works like a universal socket. On one side, a client — Claude Desktop, Claude Code, or any compatible application. On the other, an MCP server which exposes tools : search for a company, enrich a contact, list job offers. In the middle, the model alone decides when to call which tool, depending on the question asked.

The architecture is therefore made up of three bricks: the model, the MCP server, and the data index behind it. Note what this list doesn't contain: an app. The interface — chat, CRM, spreadsheet — becomes a secondary, interchangeable layer. It is the database that carries the value.

Prerequisites: an index, not a CSV export

The most common mistake is to directly expose the production base, or worse, a frozen export dating from the last quarter. An agent who reasons on outdated data produces false answers with perfect aplomb.

An index usable by an agent combines four properties:

• Stable identifiers : SIREN, web domain, internal identifier — something that allows entities to be linked together without ambiguity.
• Deduplication done upstream : the agent must never have to decide between three slightly different “Acme SAS” files.
• A timestamp of freshness on each sensitive area (workforce, fundraising, company status).
• A documented diagram : each field has an explicit name and a definition. A model reads the documentation; he doesn't guess what "rev_2" means.

Useful order of magnitude: a relevant business index for prospecting in France, there are a few hundred thousand entities that are truly active and kept up to date — not ten million lines, half of which are deregistered companies.

The four stages of connection

1. Set three to five tools, not forty. A multi-criteria search tool, an identifier enrichment tool, possibly a paginated listing tool. Each additional tool dilutes the model's ability to choose the right one.

2. Write descriptions as documentation. The description of an MCP tool is read by the model on each call. Specify the units, possible filter values, pagination limits. A vague description costs dozens of missed calls per day.

3. Connect the client. On Claude's side, this boils down to declaring the server URL in the configuration. Allow one hour, including authentication, if the server complies with the standard.

4. Test with real business questions. Not “list the companies”, but “which Lyon scale-ups with 50 to 200 employees opened sales positions this quarter?” ". It is this type of query that reveals holes in the diagram.

The classic traps

• Return 200 KB responses : the model context saturates, the quality collapses. Paginate, truncate, summarize on the server side.
• Two fields for the same concept (“employees” and “headcount”): the model will choose one at random.
• No indication of freshness : the agent will present data from 2024 as a current fact.
• Expose writing by default : start as read-only, always.

And in the CRM?

The cat is just the window. The real gain appears when the same index feeds the CRM: company files automatically enriched, accounts created with the right identifiers, growth signals reported where the teams are already working. The MCP server and the CRM connector are just two faucets plugged into the same source.

This is precisely the bet of sourcing.sh: rather than another application, an index - around 200,000 companies, 123,000 profiles, 1.4 million job offers - continuously fed by agents, and delivered fresh to where you work: your CRM, your ATS, Claude via MCP, or your own code via API. Fixed price, without credit counter. The piping is standardized; we take care of what's at the end of the pipe.