Skip to main content
Glama
Sign In
nubiia-dev

Pipedrive MCP Server

by nubiia-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

deals_list_all_auto

Retrieve all Pipedrive deals in a single response with automatic cursor pagination; use filters or max_items to limit results for reports or exports.

Instructions

Automatically fetch ALL deals with pagination handling. Backed by Pipedrive API v2 (GET /api/v2/deals), paginated via cursor.

This tool automatically handles cursor pagination and fetches all deals matching the filters. Unlike deals/list, this returns ALL results in a single response.

WARNING: This can return large datasets. Use filters to limit results.

Workflow tips:

  • Same filters as deals/list (status, stage_id, user_id, person_id, org_id, etc.)

  • Specify max_items to limit total results if needed

  • No need to manage cursor - pagination is automatic (loops until additional_data.next_cursor is null)

  • Best for exports, reports, or comprehensive analysis

  • Use add_time_from / add_time_until to filter by creation date (client-side)

  • sort_by only accepts a small set of v2 fields (confirmed working: id, add_time, update_time)

Common use cases:

  • Get all open deals: { "status": "open" }

  • Export all deals for a pipeline: { "pipeline_id": 1 }

  • Get old unqualified deals: { "pipeline_id": 4, "add_time_until": "2023-12-31" }

Input Schema

NameRequiredDescriptionDefault
sortNoField to sort by. v2 only accepts a small enum — confirmed: id, add_time, update_time.
org_idNoFilter by organization ID
statusNoFilter by deal status. 'all_not_deleted' is v1-only and is translated to 'no status filter'.
sort_byNoSort direction
user_idNoFilter by user (owner) ID — sent as owner_id to v2. If owned_by_you=1 is also set, owned_by_you takes precedence and this value is ignored.
stage_idNoFilter by stage ID
filter_idNoID of the filter to use
max_itemsNoMaximum number of items to return
person_idNoFilter by person ID
pipeline_idNoFilter by pipeline ID
owned_by_youNoFilter deals owned by the authorized user. Takes precedence over user_id when both are provided.
add_time_fromNoFilter deals created on or after this date (YYYY-MM-DD). Applied client-side.
add_time_untilNoFilter deals created on or before this date (YYYY-MM-DD). Applied client-side.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv2.7.1
    • changedInput schema / properties / owned_by_you / description
      Previous value: -"Filter deals owned by the authorized user"New value: +"Filter deals owned by the authorized user. Takes precedence over user_id when both are provided."
    • changedInput schema / properties / sort / description
      Previous value: -"Field to sort by"New value: +"Field to sort by. v2 only accepts a small enum — confirmed: id, add_time, update_time."
    • changedInput schema / properties / status / description
      Previous value: -"Filter by deal status"New value: +"Filter by deal status. 'all_not_deleted' is v1-only and is translated to 'no status filter'."
    • changedInput schema / properties / user_id / description
      Previous value: -"Filter by user (owner) ID"New value: +"Filter by user (owner) ID — sent as owner_id to v2. If owned_by_you=1 is also set, owned_by_you takes precedence and this value is ignored."
  2. Changed2 schema fields changedv2.3.1
    • addedInput schema / properties / add_time_from
      Added value: +{
+  "description": "Filter deals created on or after this date (YYYY-MM-DD). Applied client-side.",
+  "type": "string"
+}
    • addedInput schema / properties / add_time_until
      Added value: +{
+  "description": "Filter deals created on or before this date (YYYY-MM-DD). Applied client-side.",
+  "type": "string"
+}
  3. First observedv2.1.0

TDQS

A4.2/5.0
Behavior4/5

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

No annotations exist, so the description carries the full behavioral burden and does well: it discloses the pagination loop ('loops until additional_data.next_cursor is null'), the large-payload risk, and that add_time filters are applied client-side. It omits auth/permission requirements and rate-limit behavior, which matters for a bulk-fetch tool.

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

Conciseness4/5

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

Well front-loaded — the one-line purpose precedes the warning and tips. It is slightly long and repeats the pagination point three times ('with pagination handling', 'automatically handles cursor pagination', 'no need to manage cursor'), which costs a little density but not comprehension.

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

Completeness4/5

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

For a 13-parameter, unannotated, no-output-schema bulk-fetch tool, the description covers filtering strategy, limiting, sorting caveats, and concrete call examples. Remaining gaps are return shape/envelope and rate-limit or permission constraints, which an agent would want before pulling an unbounded dataset.

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

Parameters2/5

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

Schema coverage is 100%, so the baseline would be 3, but the description actively conflicts with the schema: it says 'sort_by only accepts a small set of v2 fields (confirmed working: id, add_time, update_time)' while the schema defines sort_by as an asc/desc direction enum and 'sort' as the field name. An agent reading the prose first could set sort_by incorrectly. The rest of the parameter commentary (max_items, date filters, client-side application) is useful but duplicated from the schema.

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

Purpose5/5

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

States a specific verb and resource ('fetch ALL deals') plus the defining mechanism ('automatically handles cursor pagination'), and explicitly contrasts with the sibling deals/list: 'Unlike deals/list, this returns ALL results in a single response.' An agent can pick between the two without inspecting schemas.

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

Usage Guidelines5/5

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

Gives explicit when-to-use ('exports, reports, or comprehensive analysis'), an explicit caveat with mitigation ('WARNING: This can return large datasets. Use filters to limit results'), and names the alternative tool. The workflow tips section further bounds usage (max_items, date filters, sort field limits).

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