In Short

  • Problem: a friend wanted to drive his Pipedrive CRM with Claude without giving an agent broad, vague access to all commercial data.
  • What I tested: existing Pipedrive MCP options, then a small local TypeScript server in mock mode, over stdio, and finally against a real Pipedrive account with disposable objects prefixed MCP LAB -.
  • Result: the core commercial workflow works live for creating, reading, updating, and cleaning up organizations, people, leads, deals, notes, activities, follow-ups, and closures. The product test was skipped because the account had no products.
  • Lesson: a useful CRM MCP is not the one that exposes the whole API. It gives enough actions to work, with visible limits before the first real write.
  • Linked repo: pezzos/pipedrive-mcp-lab.

The Starting Need

The initial request was not abstract. A friend wanted Claude to help with things he already does in Pipedrive: find a deal, prepare a follow-up, create an activity, qualify a lead, move an opportunity, or add a note after a call.

That immediately raises a boundary question: should an agent be given a wide connector and told to behave, or should it receive a small set of explicit actions?

I preferred the second option. A CRM contains commercial context, names, notes, and sometimes sensitive follow-up information. Even for a lab, the tool should make its write surface obvious.

What I Built

The lab started with a local TypeScript MCP server. It first ran against mocks, then through stdio, then against a real account with disposable data.

The live write rule was deliberately visible: lab-created objects were prefixed with MCP LAB -, and write actions required an explicit confirmation flag. That made it possible to distinguish test data from real business data and to clean up after the run.

The important part was not the number of tools. Writes were closed by default. A real write needed PIPEDRIVE_ENABLE_WRITES=true, dry_run=false, and a confirmation. For the live lab, confirm_lab_write=true allowed disposable writes only on objects whose names started with MCP LAB -.

The useful workflow was not “access Pipedrive”. It was:

  • create the CRM objects needed for a lead;
  • read them back;
  • update the deal and related notes;
  • create follow-up activity;
  • close or clean up the disposable objects;
  • record what was not tested.

What Worked

The core flow worked live for the main CRM objects. That is enough to show that a small MCP can be useful without becoming a full Pipedrive replacement.

It also confirmed the value of guardrails. The prefix, confirmation flag, and explicit cleanup path made the lab easier to trust.

The live run was useful because it found the boring API mismatches mocks can miss: person email and phone had to be shaped as arrays, activity people had to go through participants, lead value needed both amount and currency, and one organization address field was removed instead of being left as a misleading schema promise.

What Remains Out Of Scope

This is not a production connector. It does not prove OAuth, hosting, remote access, pagination under load, rate-limit behavior, dashboards, email sync, file handling, automation, reports, or product line items.

The product case was specifically skipped because the account had no products available. That is a result, not a hidden success.

I would not connect this as-is to a client CRM full of real data. At minimum, that would need permission profiles, a clearer read/write split, confirmations integrated into the MCP client, a logging strategy, and probably OAuth or a proxy if the tool leaves a local machine.

What I Would Reuse

For a local assisted use, I would reuse the shape of the MCP:

  • start from reading, because finding the right CRM context is already useful;
  • encode business gestures, not only raw API endpoints;
  • make writes explicit;
  • prefix disposable data;
  • keep cleanup as part of the test;
  • write down the missing surfaces instead of smoothing them over.

That is the main lesson. A narrow MCP can be more useful than a broad connector when the goal is to help an agent act without pretending it should own the whole CRM.

Before Reusing The Connector

The linked repo contains the TypeScript stdio MCP server, the Pipedrive client, guarded CRM tools, Zod validations, dry-run behavior, mocked tests, a replay prompt, and RESULTATS.md separating mock proof, live reads, disposable live writes, and remaining limits.

It is useful for inspecting a careful local connector shape before adapting it. It is not ready to connect to a client CRM without review, replace the Pipedrive UI, solve OAuth or remote hosting, or give an agent broad CRUD access without explicit confirmation.