Skip to main content
Glama
comma-compliance

pipedrive-mcp

by comma-compliance
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
TypeScript
Remote

pipedrive_deals_create

Create a new CRM deal with title, value, stage, status, org, person, and labels. Add custom fields by name or API key and set native labels via IDs or names.

Instructions

Create a new deal. Supports custom fields by name or key, and the native Label field via label_ids (IDs or label names).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesDeal title
valueNo
org_idNo
statusNo
currencyNo
stage_idNo
label_idsNoNative Label field. Label option IDs or label names (e.g. [367] or ['Test / Internal']). Replaces existing labels; pass [] to clear. Sent as top-level label_ids, not a custom field.
person_idNo
visible_toNoVisibility: 1=owner only, 3=owner's group, 5=owner's group+sub, 7=everyone
pipeline_idNo
custom_fieldsNoCustom fields by API key (e.g. { 'abc123hash': 'value' })
expected_close_dateNo
custom_fields_by_nameNoCustom fields by human-readable name (e.g. { 'Tier': 'Enterprise' })

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.1.1
    • addedInput schema / properties / custom_fields / description
      Added value: +"Custom fields by API key (e.g. { 'abc123hash': 'value' })"
    • addedInput schema / properties / custom_fields_by_name / description
      Added value: +"Custom fields by human-readable name (e.g. { 'Tier': 'Enterprise' })"
    • addedInput schema / properties / label_ids
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "string"
+          }
+        ]
+      },
+      "type": "array"
+    },
+    {
+      "type": "integer"
+    },
+    {
+      "type": "string"
+    }
+  ],
+  "description": "Native Label field. Label option IDs or label names (e.g. [367] or ['Test / Internal']). Replaces existing labels; pass [] to clear. Sent as top-level label_ids, not a custom field."
+}
    • addedInput schema / properties / visible_to / description
      Added value: +"Visibility: 1=owner only, 3=owner's group, 5=owner's group+sub, 7=everyone"
  2. First observedv1.1.0

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no permission/auth requirements, no mention of side effects such as triggering webhooks or affecting deal counts, no deduplication behavior, and no return information. Only 'create' implies mutation; the mutation semantics themselves are undocumented.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences, front-loaded with the core action and then the two special-case input mechanisms. No filler, no repetition of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter write tool with no annotations, no output schema, and 38% schema coverage, the description is too thin. An agent still lacks guidance on required companion IDs, visibility/permission implications, and typical success/failure behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 38% across 13 parameters, so the description should compensate. It adds genuine meaning for custom_fields (key vs human-readable name), custom_fields_by_name, and label_ids (IDs or names, replaces existing labels), but says nothing about value, org_id, status, currency, stage_id, person_id, pipeline_id, visible_to, or expected_close_date.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create a new deal') and immediately scopes the two non-obvious capabilities it supports: custom fields by name or key, and the native Label field via label_ids. It implicitly distinguishes itself from pipedrive_deals_update/deals_get, but never names those siblings explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no prerequisites (e.g. needing a pipeline/stage or person/org before creating), and no mention of how it relates to pipedrive_deals_update or the search/list siblings. The only routing hint is the note that labels go in label_ids rather than a custom field, which is really a parameter detail.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools