Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Pipedrive MCP Server show me my open deals"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for Pipedrive CRM. This server allows LLMs like Claude to interact with your Pipedrive data through a standardized interface.
Developed by Osher Digital
22 Tools for comprehensive Pipedrive access
Saved Filter Support: Use Pipedrive's saved filters to query by custom fields
Field Definitions: Map custom field hashes to human-readable names
Activities: Access calls, meetings, tasks, and emails
Flexible Sorting: Sort deals by date, value, or title
Date Range Filtering: Filter by created/updated dates
Rate Limiting: Built-in rate limiting to respect Pipedrive API limits
Related MCP server: Pipedrive MCP Server
cd pipedrive-mcp-python
# Install with uv
uv syncCreate a .env file in the project root (or set environment variables):
# Required
PIPEDRIVE_API_TOKEN=your_api_token_here
PIPEDRIVE_DOMAIN=your-company.pipedrive.com
# Optional - Rate Limiting
PIPEDRIVE_RATE_LIMIT_MIN_TIME_MS=250
PIPEDRIVE_RATE_LIMIT_MAX_CONCURRENT=2Log into your Pipedrive account
Go to Settings > Personal preferences > API
Copy your API token
# Run with uv
uv run pipedrive-mcpAdd to your Claude Desktop configuration:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"pipedrive": {
"command": "/path/to/pipedrive-mcp-python/.venv/bin/python",
"args": ["-m", "pipedrive_mcp.server"],
"cwd": "/path/to/pipedrive-mcp-python"
}
}
}Set environment variables in your shell profile or .env file in the project directory.
claude mcp add pipedrive -- /path/to/pipedrive-mcp-python/.venv/bin/python -m pipedrive_mcp.serverTool | Description |
| Get all users/owners from Pipedrive |
Tool | Description |
| Get deals with comprehensive filtering (see below) |
| Get a single deal by ID with all custom fields |
| Get notes for a specific deal |
| Full-text search deals |
get_deals parameters:
search_title - Search by deal title (partial matches)
owner_id - Filter by owner/user ID
stage_id - Filter by pipeline stage
status - Filter by status: open, won, lost, deleted (default: open)
pipeline_id - Filter by pipeline
filter_id - Use a saved filter from Pipedrive
min_value / max_value - Filter by deal value range
created_after / created_before - Filter by creation date (ISO format: YYYY-MM-DD)
updated_after / updated_before - Filter by update date
sort_by - Sort field: add_time, update_time, title, value (default: add_time)
sort_order - Sort direction: asc, desc (default: desc)
limit - Maximum results (default: 500)
Tool | Description |
| Get all persons, optionally filtered by saved filter |
| Get a single person by ID with all custom fields |
| Full-text search persons |
Tool | Description |
| Get all organizations, optionally filtered |
| Get a single organization by ID |
| Full-text search organizations |
Tool | Description |
| Get all sales pipelines |
| Get a single pipeline by ID |
| Get all stages, optionally filtered by pipeline |
Tool | Description |
| Full-text search leads |
Tool | Description |
| Search across all item types |
Supported item types: deal, person, organization, product, file, activity, lead
Tool | Description |
| Get all saved filters from Pipedrive |
Filter types: deals, persons, org, products, activities
Use saved filters to query by custom fields:
Create a filter in Pipedrive UI with your criteria
Call get_filters() to find the filter's ID
Pass filter_id to get_persons(), get_deals(), or get_organizations()
Tool | Description |
| Get deal field definitions (maps hash IDs to names) |
| Get person field definitions |
| Get organization field definitions |
These tools map custom field hash keys (like c3976c9693716fc786c2092081506816441ee526) to human-readable field names.
Tool | Description |
| Get activities (calls, meetings, tasks, emails) |
| Get all activity types configured in Pipedrive |
get_activities parameters:
deal_id - Filter by deal
person_id - Filter by person
org_id - Filter by organization
user_id - Filter by assigned user
activity_type - Filter by type (call, meeting, task, email, etc.)
done - Filter by completion status (True/False)
start_date / end_date - Filter by date range (ISO format)
limit - Maximum results (default: 100)
get_deals(limit=10)get_deals(created_after="2026-01-01")get_deals(sort_by="value", sort_order="desc", limit=10)get_filters(filter_type="persons") # Find the filter ID
get_persons(filter_id=122) # Use the filterget_activities(deal_id=123, activity_type="call")get_deal_fields() # Returns mapping of hash keys to field names# Install with dev dependencies
uv sync --extra dev
# Run tests
uv run pytest
# Run with verbose output
uv run pytest -vMIT License - see LICENSE file for details.
Developed by Osher Digital - Digital transformation and AI integration specialists.
Get activities (calls, meetings, tasks, emails) from Pipedrive.
Retrieves activities with various filter options. Can filter by linked entities, type, completion status, and date range.
Args: deal_id: Filter by deal ID person_id: Filter by person ID org_id: Filter by organization ID user_id: Filter by assigned user ID activity_type: Filter by type (call, meeting, task, email, etc.) done: Filter by completion status (True=done, False=not done) start_date: Activities from this date (ISO format: YYYY-MM-DD) end_date: Activities until this date (ISO format: YYYY-MM-DD) limit: Maximum results (default: 100)
Returns: JSON array of activities with subject, type, due date, done status, notes, and linked entities
Examples: - get_activities() - Get recent activities - get_activities(deal_id=123) - Get activities for a specific deal - get_activities(done=False) - Get incomplete activities - get_activities(activity_type="call") - Get all calls - get_activities(start_date="2026-01-01", end_date="2026-01-31") - Get January activities
| Name | Required | Description | Default |
|---|---|---|---|
| deal_id | No | ||
| person_id | No | ||
| org_id | No | ||
| user_id | No | ||
| activity_type | No | ||
| done | No | ||
| start_date | No | ||
| end_date | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It mentions return format but does not disclose read-only nature, destructive potential, rate limits, or authentication requirements. Adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with sections (Args, Returns, Examples) and concise bullets. It is front-loaded with purpose. Slightly lengthy but efficient; a small reduction might improve.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0% schema coverage and no annotations, the description covers all parameters, return format, and provides examples. Lacks non-obvious constraints (e.g., pagination) but is complete enough for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds detailed explanations for all 9 parameters, including types, defaults, and format (ISO date). Examples demonstrate usage, adding significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets activities (calls, meetings, tasks, emails) from Pipedrive, with specific verb and resource. It distinguishes from sibling tools like get_deal or get_person by focusing on activities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists numerous filter options and examples, implying when to use (e.g., to get activities for a deal, person, or by type). However, it does not explicitly state when not to use or contrast with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all activity types configured in Pipedrive.
Returns the list of activity types (call, meeting, task, lunch, etc.) available in your Pipedrive account. Use this to know what types can be used when filtering activities.
Returns: JSON array of activity types with id, name, and icon
Examples: - get_activity_types() - Get all available activity types
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses return format (JSON array with id, name, icon) and includes examples. Implies read-only operation. Could mention idempotency but not necessary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: purpose, returns, examples in three short sections. No fluff, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, output schema exists, and description covers return structure and example call, it provides full context for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, schema coverage 100%, so baseline 3. Description adds value by explaining return structure and providing example usage, thus score 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get all activity types configured in Pipedrive.' Provides specific resource and action, and distinguishes from sibling tools like get_activities which return activities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to know what types can be used when filtering activities.' Gives clear context, though does not specify when not to use or name alternatives; sufficient for a simple list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single deal by ID with all details.
Retrieves comprehensive information about a specific deal including all custom fields, owner info, pipeline stage, and related entities.
Args: deal_id: The Pipedrive deal ID
Returns: JSON object with deal details
Examples: - get_deal(deal_id=123) - Get deal with ID 123
| Name | Required | Description | Default |
|---|---|---|---|
| deal_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the tool retrieves comprehensive information about a deal, including custom fields and related entities, which is helpful. However, it does not disclose any potential behaviors like error handling, rate limits, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear one-line purpose, followed by a detailed paragraph and structured Args/Returns/Examples. It is concise without being overly terse, though the paragraph repeats some words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description does not need to detail return structure. It mentions 'JSON object with deal details' and provides an example. The tool is simple (one param), so the description is sufficient for an agent to understand its use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter. The description includes 'Args: deal_id: The Pipedrive deal ID', which adds context beyond the schema's 'Deal Id' title, but does not provide format or constraints beyond what the schema already indicates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a single deal by ID with all details', using specific verb and resource. It distinguishes from sibling tools like 'get_deals' (which lists deals) and 'search_deals' (searching for deals).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific deal ID and need full details, but does not explicitly state when not to use it or mention alternatives. The sibling list provides context, but the description itself lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all deal field definitions from Pipedrive.
Returns field metadata that maps the hash IDs (like 'c3976c9693716fc786c2092081506816441ee526') to human-readable names. Essential for understanding custom fields in deal data.
Returns: JSON array of field definitions with: - key: The field ID/hash used in deal data - name: Human-readable field name - field_type: Type of field (text, number, date, enum, etc.) - options: Available options for enum/set fields
Examples: - get_deal_fields() - Get all deal field definitions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description details the returned structure (key, name, field_type, options) and the overall purpose. It doesn't mention side effects, but for a read-only tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear summary, a structured 'Returns' section, and an example. Every sentence adds value, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters) and the existence of an output schema, the description fully covers what the tool does and what it returns. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is trivially 100%. The description includes an example call, which adds no extra semantics but meets the baseline for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all deal field definitions from Pipedrive' and explains the mapping from hash IDs to human-readable names. It distinguishes itself from siblings like 'get_deals' and 'get_person_fields' by focusing on field metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that the tool is 'Essential for understanding custom fields in deal data,' providing clear context for when it should be used. It doesn't explicitly state when not to use it, but the purpose is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get notes for a specific deal.
Retrieves all notes and comments associated with a deal.
Args: deal_id: The Pipedrive deal ID
Returns: JSON array of notes
Examples: - get_deal_notes(deal_id=123) - Get notes for deal 123
| Name | Required | Description | Default |
|---|---|---|---|
| deal_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the behavior (retrieve all notes/comments) but does not mention any limitations, side effects, or authentication requirements. It is adequate for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with sections for Args, Returns, and Examples. It is front-loaded with the core purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description is complete: it explains the resource, parameter, return type, and provides an example. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides a plain English description of the deal_id parameter and includes an example, adding meaning beyond the schema's title and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves notes for a specific deal, using a specific verb and resource. It distinguishes itself from sibling tools like get_deal (deal details) and get_activities (activities) by focusing on notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when notes are needed for a deal, but does not explicitly state when to use or not use this tool compared to alternatives. No guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get deals from Pipedrive with filtering options.
Retrieves deals with various filter options. Can filter by title search, date ranges, owner, stage, status, pipeline, and value range. Results are sorted by creation date (newest first) by default.
Args: search_title: Search by deal title (partial matches) owner_id: Filter by owner/user ID stage_id: Filter by pipeline stage status: Filter by status - 'open', 'won', 'lost', or 'deleted' (default: 'open') pipeline_id: Filter by pipeline filter_id: ID of a saved filter from Pipedrive (use get_filters to see available filters) min_value: Minimum deal value filter max_value: Maximum deal value filter created_after: Only deals created after this date (ISO format: YYYY-MM-DD) created_before: Only deals created before this date (ISO format: YYYY-MM-DD) updated_after: Only deals updated after this date (ISO format: YYYY-MM-DD) updated_before: Only deals updated before this date (ISO format: YYYY-MM-DD) sort_by: Field to sort by - 'add_time', 'update_time', 'title', 'value' (default: 'add_time') sort_order: Sort direction - 'asc' or 'desc' (default: 'desc' for newest first) limit: Maximum number of results (default: 500)
Returns: JSON array of deals with summary
Examples: - get_deals() - Get all open deals (newest first) - get_deals(limit=10) - Get 10 most recent open deals - get_deals(status="won") - Get won deals - get_deals(created_after="2026-01-01") - Get deals created this year - get_deals(filter_id=5) - Get deals matching saved filter #5 - get_deals(sort_by="value", sort_order="desc") - Get highest value deals first
| Name | Required | Description | Default |
|---|---|---|---|
| search_title | No | ||
| owner_id | No | ||
| stage_id | No | ||
| status | No | open | |
| pipeline_id | No | ||
| filter_id | No | ||
| min_value | No | ||
| max_value | No | ||
| created_after | No | ||
| created_before | No | ||
| updated_after | No | ||
| updated_before | No | ||
| sort_by | No | add_time | |
| sort_order | No | desc | |
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses default sorting (newest first), default limit (500), and available filter fields. However, it does not mention pagination behavior, error handling, or any potential side effects. Still, it provides good operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary paragraph, parameter list, return type, and examples. It is somewhat verbose but appropriate for the number of parameters. Could be slightly more concise but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 parameters, no required params, and presence of output schema, the description covers all parameters, defaults, and provides examples. It lacks pagination details beyond limit but is generally sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides detailed meanings for each parameter, including allowed values for status, date format guidance, and sort options. This adds significant value beyond the bare schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'Get deals from Pipedrive with filtering options.' It specifies the verb (Get), resource (deals), and scope (with filtering). This distinguishes it from siblings like get_deal (single) and search_deals (full-text search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing many filter options but does not explicitly state when to use this tool versus alternatives like search_deals or get_deal. No direct guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all saved filters from Pipedrive.
Returns the list of saved filters that can be used with get_deals, get_persons, and get_organizations. Filters allow you to query by custom fields that aren't directly supported in the API.
To filter by custom fields (like "User Type = cemoh"):
Create a filter in Pipedrive UI with your criteria
Use get_filters() to find the filter's ID
Pass that filter_id to get_persons(), get_deals(), etc.
Args: filter_type: Filter by type - 'deals', 'persons', 'org', 'products', 'activities' If not specified, returns all filters.
Returns: JSON array of filters with id, name, and type
Examples: - get_filters() - Get all saved filters - get_filters(filter_type="persons") - Get only person/contact filters - get_filters(filter_type="deals") - Get only deal filters
| Name | Required | Description | Default |
|---|---|---|---|
| filter_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but the description covers return format (JSON array with id, name, type), the effect of the optional filter_type parameter, and that it retrieves all filters if unspecified. No destructive behavior mentioned, consistent with a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with Args, Returns, and Examples sections. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a simple list tool with one parameter. Explains return format, usage pattern, and integration with other tools. Output schema exists but description still clarifies content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully documents the single parameter filter_type: lists valid values (deals, persons, etc.) and explains default behavior. Adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves saved filters from Pipedrive, explaining their use with other tools like get_deals. It distinguishes from siblings by focusing on filter retrieval, which is unique among the listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when to use: to get filter IDs for custom field queries, with a step-by-step process. Lacks explicit when not to use, but the context is sufficient for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single organization by ID.
Retrieves comprehensive information about a specific organization including all custom fields.
Args: org_id: The Pipedrive organization ID
Returns: JSON object with organization details
Examples: - get_organization(org_id=789) - Get organization with ID 789
| Name | Required | Description | Default |
|---|---|---|---|
| org_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions it retrieves 'comprehensive information' and 'including all custom fields', but does not explicitly state it is a read-only operation or disclose any side effects. No annotations provided, so the description carries the burden but only partially addresses behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct with a clear structure: purpose, arguments, returns, and example. Every sentence serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter, an output schema (implied), and is a simple retrieval, the description covers all necessary aspects: what it does, what input is needed, and what is returned. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'org_id' parameter by stating 'The Pipedrive organization ID' and providing a concrete example, which is valuable given the schema has zero description coverage. It clarifies the parameter's purpose beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get a single organization by ID', clearly identifying the verb and resource. It distinguishes itself from sibling tools like 'get_organizations' (plural) and 'search_organizations' by focusing on a single entity retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a parameter description and a usage example, but does not specify when to use this tool versus alternatives (e.g., when to use 'get_organizations' for listing or 'search_organizations' for filtering). No guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all organization field definitions from Pipedrive.
Returns field metadata that maps the hash IDs to human-readable names. Essential for understanding custom fields in organization data.
Returns: JSON array of field definitions with key, name, field_type, and options
Examples: - get_organization_fields() - Get all organization field definitions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description explains the return type and example usage, but does not disclose behavioral traits such as authentication requirements, rate limits, or whether the response is paginated. Basic transparency, but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is relatively concise with a clear intro, return description, and example. Could be slightly more streamlined, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema present, the description adequately covers the tool's purpose and return structure. Provides context that it is essential for custom fields, making it fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so baseline is 4. The description provides an example call 'get_organization_fields()' confirming no arguments are needed, which adds clarity beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all organization field definitions from Pipedrive, using the verb 'Get' and specifying the resource. It distinguishes from sibling tools like get_deal_fields and get_person_fields by focusing on organizations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for understanding custom fields in organization data, but does not explicitly state when to use this tool versus alternatives or provide any exclusions. No guidance on prerequisites or contextual when-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all organizations from Pipedrive.
Retrieves all organizations/companies with their details. Use filter_id to apply a saved filter for custom field filtering.
Args: filter_id: ID of a saved filter from Pipedrive (use get_filters to see available filters) limit: Maximum number of organizations to return (default: 500)
Returns: JSON array of organizations
Examples: - get_organizations() - Get all organizations - get_organizations(limit=100) - Get first 100 organizations - get_organizations(filter_id=8) - Get organizations matching saved filter #8
| Name | Required | Description | Default |
|---|---|---|---|
| filter_id | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the tool retrieves organizations and respects a limit, but it fails to mention pagination behavior, error handling, idempotency, or the read-only nature. The lack of details beyond basic retrieval reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief intro, clearly labeled arguments, return type, and examples. It is fairly concise, though the first two sentences are slightly redundant ('Get all organizations...' and 'Retrieves all organizations...'). Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional parameters) and the presence of an output schema, the description covers the basics adequately. It explains parameters and provides usage examples. However, it lacks details on pagination behavior, error scenarios, and the exact structure of returned organizations, which would be needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates well. It explains 'filter_id' as a saved filter ID and 'limit' as maximum results with a default of 500, and provides examples. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves all organizations from Pipedrive with details. It implies a list operation but does not explicitly differentiate from sibling tools like get_organization (single) or search_organizations (full-text search). The examples reinforce the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to get all organizations) and how to apply saved filters via filter_id. It references get_filters for available filters. However, it does not provide guidance on when not to use it or mention alternatives like get_organization for fetching a specific organization by ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single person/contact by ID.
Retrieves comprehensive information about a specific contact including all custom fields and related data.
Args: person_id: The Pipedrive person ID
Returns: JSON object with person details
Examples: - get_person(person_id=456) - Get person with ID 456
| Name | Required | Description | Default |
|---|---|---|---|
| person_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states that the tool retrieves 'comprehensive information including all custom fields and related data,' which is useful. However, it does not mention any side effects, permissions, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: description, Args, Returns, and Examples. It is concise, front-loaded with the purpose, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with 1 parameter and an output schema, the description covers retrieval purpose, parameter meaning, return format, and an example. It could mention behavior when the person ID is not found, but overall it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds an Args section explaining 'person_id: The Pipedrive person ID', which provides meaningful context beyond the schema's minimal type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a single person/contact by ID', using a specific verb and resource. It distinguishes from sibling tools like 'get_persons' (plural) and 'search_persons'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an Args and Returns section, and an example showing correct usage. However, it does not explicitly state when to use this tool over alternatives like 'get_persons' or 'search_persons'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all person/contact field definitions from Pipedrive.
Returns field metadata that maps the hash IDs to human-readable names. Essential for understanding custom fields in person data.
Returns: JSON array of field definitions with key, name, field_type, and options
Examples: - get_person_fields() - Get all person field definitions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It correctly implies idempotent read operation but does not disclose authentication needs, rate limits, or side effects. It is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a clear intro, return details, and example. Sentence count is reasonable; no wasted words, but the structure could be slightly tighter by merging purpose and return info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and existing output schema, the description covers purpose, return structure, and example adequately. It is complete for this simple tool, though it could explicitly note that the output schema provides further details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds value by explaining the return structure (key, name, field_type, options) and purpose, earning the baseline of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves all person/contact field definitions from Pipedrive, specifying it returns metadata mapping hash IDs to human-readable names. It distinguishes itself from sibling tools like get_deal_fields and get_organization_fields by being specific to persons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. While it mentions being 'essential for understanding custom fields in person data,' it does not differentiate from other field retrieval tools or provide context on prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all persons/contacts from Pipedrive.
Retrieves all contacts with their details including custom fields. Use filter_id to apply a saved filter for custom field filtering.
Args: filter_id: ID of a saved filter from Pipedrive (use get_filters to see available filters). Create filters in Pipedrive UI to filter by custom fields like "User Type". limit: Maximum number of persons to return (default: 500)
Returns: JSON array of persons
Examples: - get_persons() - Get all contacts - get_persons(limit=100) - Get first 100 contacts - get_persons(filter_id=12) - Get contacts matching saved filter #12
| Name | Required | Description | Default |
|---|---|---|---|
| filter_id | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the return type (JSON array) and default limit, but does not mention pagination, rate limits, authorization needs, or whether the operation is purely read-only. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Examples sections. It is front-loaded with the core purpose. A few sentences could be trimmed (e.g., 'including custom fields' is redundant), but overall it is efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are covered. The description mentions JSON array and example usage. For a simple retrieval tool with only two optional parameters, it covers the essential context. Missing error handling or invalid filter behavior, but acceptable given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no param descriptions in schema), so description fully compensates. It explains filter_id as a saved filter ID, suggests using get_filters, and shows examples. Limit is described with default. This adds substantial meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all persons/contacts from Pipedrive' with specific verb and resource. It mentions retrieval with optional filtering, but does not explicitly differentiate from sibling tools like 'get_person' (singular) or 'search_persons', which would strengthen clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through examples and parameter explanations (e.g., use filter_id for saved filters). It references 'get_filters' for available filters, but does not explicitly state when to use this tool vs. alternatives or when not to use it. Lacks when-not or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single pipeline by ID.
Retrieves details about a specific pipeline.
Args: pipeline_id: The Pipedrive pipeline ID
Returns: JSON object with pipeline details
Examples: - get_pipeline(pipeline_id=1) - Get pipeline with ID 1
| Name | Required | Description | Default |
|---|---|---|---|
| pipeline_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It only mentions it returns a JSON object but does not disclose side effects, auth requirements, rate limits, or any behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core sentence is clear, but the docstring-like format (Args, Returns, Examples) adds redundancy. Could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema, so return details aren't required. Provided example helps. For a single-parameter retrieval tool, it's adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It adds a brief explanation ('The Pipedrive pipeline ID') but no format, constraints, or examples beyond the schema's integer type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get a single pipeline by ID' and 'Retrieves details about a specific pipeline.' This uses a specific verb and resource, clearly distinguishing from siblings like get_pipelines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_pipelines for multiple pipelines. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all pipelines from Pipedrive.
Retrieves all sales pipelines configured in your Pipedrive account.
Returns: JSON array of pipelines
Examples: - get_pipelines() - Get all pipelines
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses the return type (JSON array) and provides an example, but doesn't mention edge cases (e.g., empty result) or auth requirements. For a simple read tool, this is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with front-loaded purpose, followed by return type and example. Every sentence is useful with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, read-only, output schema present), the description fully covers what the agent needs to know, including return format and usage example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, and schema coverage is 100%. The description adds no parameter info (none needed). Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all pipelines' and 'Retrieves all sales pipelines configured in your Pipedrive account', using a specific verb and resource. It distinguishes from sibling tool get_pipeline (singular) which likely retrieves a single pipeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit when-to-use or when-not-to-use guidance. It simply states the function without comparing to alternatives like get_pipeline. Usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all stages, optionally filtered by pipeline.
Retrieves all stages across pipelines. Can filter to show only stages for a specific pipeline.
Args: pipeline_id: Optional pipeline ID to filter stages
Returns: JSON array of stages with pipeline information
Examples: - get_stages() - Get all stages across all pipelines - get_stages(pipeline_id=1) - Get stages for pipeline 1
| Name | Required | Description | Default |
|---|---|---|---|
| pipeline_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes read operation ('Retrieves') and return type (JSON array). No annotations provided, so description bears full burden; it adequately discloses behavior without mentioning auth or rate limits, which are less critical for a simple get.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded summary, followed by structured details (Args, Returns, Examples). Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Single optional parameter fully explained; return type described; examples cover both use cases. Output schema exists, so no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description explains pipeline_id is optional, filters stages, and adds examples. Adds significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves all stages with optional pipeline filtering. Distinguishes from sibling tools like get_pipelines (pipelines vs stages).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context for when to use (with/without filter) and includes examples. Does not explicitly state when not to use, but clarity is sufficient given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all users/owners from Pipedrive.
Returns all users in your Pipedrive account with their ID, name, email, active status, and role. Useful for filtering deals by owner.
Returns: JSON array of users
Examples: - get_users() - Get all users to see available owners
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It correctly indicates a read operation and lists return fields, but lacks details on authentication, rate limits, or edge cases. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with separate sections for purpose, return details, use case, and example. Every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and presence of output schema (as per context), the description sufficiently explains what the tool returns and how to use it, making it complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Description adds no param detail, which is acceptable. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all users/owners from Pipedrive' and lists returned fields, distinguishing from sibling tools that retrieve different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('Useful for filtering deals by owner') but does not include when-not-to-use or alternatives, though it's implicit given the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across all item types in Pipedrive.
Performs a cross-type search across deals, persons, organizations, products, files, activities, and leads.
Args: term: Search term item_types: Comma-separated item types to search (deal, person, organization, product, file, activity, lead). If not specified, searches all types. limit: Maximum results (default: 100)
Returns: JSON array of matching items across types
Examples: - search_all(term="acme") - Search "acme" across all types - search_all(term="enterprise", item_types="deal,person") - Search specific types
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | ||
| item_types | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It discloses that the tool returns a JSON array of matching items, specifies the default limit, and shows the return type. However, it does not mention potential side effects (though search is read-only), pagination, or rate limits, which would enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for Args, Returns, and Examples. Every sentence is useful, and there is no redundancy or wasted words. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 3 parameters and lack of annotations, the description covers purpose, parameters, return type, and examples. Since an output schema exists, the description does not need to detail return fields. It could optionally mention pagination or sorting details, but the provided information is sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description adds significant meaning: 'term' is a search term, 'item_types' is a comma-separated list of types with a default of all, and 'limit' is maximum results with a default of 100. This is very helpful beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool searches across all item types in Pipedrive and lists the specific types (deals, persons, organizations, products, files, activities, leads). It differentiates from sibling tools like search_deals or search_organizations by indicating it performs a cross-type search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (cross-type search) and includes examples for searching all types or specific types. It implicitly suggests that for single-type searches, sibling tools should be used, but does not explicitly state when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search deals by term.
Searches across deal titles, notes, and related content.
Args: term: Search term limit: Maximum results (default: 100)
Returns: JSON array of matching deals
Examples: - search_deals(term="acme") - Search for deals mentioning "acme" - search_deals(term="enterprise", limit=50) - Search with limit
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses it returns a JSON array of matching deals and searches across specific fields. As a search tool, it is implicitly read-only and non-destructive, which is adequately conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections (Args, Returns, Examples) and front-loads the purpose. While it is slightly verbose with formal formatting, every sentence adds value and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and descriptions in the schema, the description fully covers purpose, parameters, return format, and usage examples. No gaps remain for a search tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful detail beyond the input schema: it explains that 'term' is the search term and 'limit' caps results (default 100), with examples showing usage. Since schema description coverage is 0%, this compensation is crucial and well-done.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs full-text search across deals by term, specifying it searches deal titles, notes, and related content. This verb+resource combination precisely differentiates it from sibling tools like search_all and search_leads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching deals and provides examples, but lacks explicit guidance on when to use this tool versus alternatives like search_organizations or search_persons. The sibling names indicate scope, satisfying a clear context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search leads by term.
Searches across lead titles and related content.
Args: term: Search term limit: Maximum results (default: 100)
Returns: JSON array of matching leads
Examples: - search_leads(term="startup") - Search for leads mentioning "startup"
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden but only states it is a full-text search, returns a JSON array, and has a default limit. It does not disclose rate limits, side effects, or error behavior, making it adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear lead sentence, a brief parameter list, and an example. It is front-loaded and efficient, though the structure could be slightly more organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low schema coverage and presence of an output schema, the description does not explain return structure detail (e.g., fields, pagination) or error handling. It is somewhat complete for a simple search but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds basic meaning by explaining 'term' as the search term and 'limit' as maximum results with default 100. However, it lacks details on accepted formats or edge cases, providing minimal compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Full-text search leads by term' and specifies it searches across 'lead titles and related content,' distinguishing it from sibling search tools like search_deals and search_organizations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an example and default limit but lacks explicit guidance on when to use this tool vs siblings like search_all or other entity-specific searches, and does not specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search organizations by term.
Searches across organization names and other fields.
Args: term: Search term limit: Maximum results (default: 100)
Returns: JSON array of matching organizations
Examples: - search_organizations(term="acme") - Search for Acme organizations
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It explains the search is full-text across multiple fields, returns a JSON array, and includes a default limit. It omits details like pagination or error handling, but for a simple search tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with labeled sections (Args, Returns, Examples). The examples are helpful, though the repetitive phrasing in the Args block could be slightly tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no nested objects, and an output schema), the description covers purpose, parameters, return type, and an example. It lacks mention of potential errors or behavior when no results are found, but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description compensates by explaining `term` as 'Search term' and `limit` with default behavior. Examples further clarify usage, adding meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs full-text search on organizations by term, specifying it searches across names and other fields. It is distinct from sibling search tools like search_deals and search_persons, which target different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for searching organizations but does not explicitly compare to alternatives or provide when-to-use/when-not-to-use guidance. Sibling tools like search_all exist, but no exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search persons/contacts by term.
Searches across person names, emails, phone numbers, and notes.
Args: term: Search term limit: Maximum results (default: 100)
Returns: JSON array of matching persons
Examples: - search_persons(term="john") - Search for persons named John - search_persons(term="@acme.com") - Search by email domain
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. Discloses searched fields and parameters but omits behavior on case sensitivity, partial matching, pagination beyond limit, sorting, or empty term handling. Lacks detail for reliable agent use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with front-loaded purpose. Includes structured Args and Examples. Could streamline the Args section since it repeats schema, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides basic outline of functionality and return type ('JSON array of matching persons'). With output schema present, heavy detail on return structure is not critical, but lacks specifics like field names or error handling. Adequate for a simple search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema by describing 'term' as search term and 'limit' as max results with default 100. However, schema coverage is 0% and description does not explain expected formats or constraints (e.g., term length). Adequate but not thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it performs full-text search on persons/contacts across specified fields (names, emails, etc.). Examples reinforce purpose. Could explicitly differentiate from sibling search tools like 'search_all' or 'search_organizations'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Does not provide guidance on when to use this tool versus alternatives like 'search_all' or 'search_organizations'. No explicit when-not or context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0get_activitiesget_activity_typesget_dealget_deal_fieldsget_deal_notesget_dealsget_filtersget_organizationget_organization_fieldsget_organizationsget_personget_person_fieldsget_personsget_pipelineget_pipelinesget_stagesget_userssearch_allsearch_dealssearch_leadssearch_organizationssearch_personsEvery tool has a clearly distinct purpose: separate retrieval functions for individual entities vs. lists, dedicated search tools, and metadata helpers. There is no functional overlap that would cause an agent to select the wrong tool.
All tools follow a consistent verb_noun pattern (get_X, search_X) using snake_case, with no deviations. This makes the API predictable and easy to navigate.
22 tools is slightly above the typical 3-15 range, but it is justified by the breadth of Pipedrive's data model (deals, persons, organizations, activities, pipelines, etc.) and the need for both single-entity and list retrieval endpoints.
The entire tool surface is read-only. There are no create, update, delete, or mutation operations, which is a significant gap for a CRM management use case. Agents cannot perform any write actions, limiting the server's utility.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Operate the Plixana CRM from any AI: contacts, deals, quotes, WhatsApp and metrics.
Read deals, persons, organizations, activities and pipelines; create and update CRM records.
xmagnet — AI-powered B2B CRM for Claude. 35 tools that turn natural-language prompts into real CRM actions: prospect, enrich, score leads, manage deals, scan buying intent, run email campaigns and sequences, build forms and landing pages, refine ICP, and analyze performance — all directly inside Claude. 🚀 ONE-CLICK INSTALL: https://api.xmagnet.ai/claude The install page guides Claude users through 3 steps in under a minute: open Claude Connectors, paste the connector name, paste the server URL, sign in. A reviewer workspace is auto-provisioned on first sign-in with sample contacts, deals, campaigns, and ICP suggestions, so every tool works end-to-end with zero setup. No 2FA. No paid plan required. Free tier exposes all 35 tools. What you can do: • Prospecting — search_contacts, search_companies, search_investors, find_contacts_at_companies, enrich_contact, validate_email, find_competitors, company_intelligence • Pipeline — get_deals_pipeline, scan_deal_intent, get_ghost_pipeline, create_deal • Campaigns & sequences — create_campaign, generate_campaign_content, get_campaign_stats, get_bounce_stats, get_unsub_stats, create_sequence_draft, list_sequences • Top of funnel — suggest_icp, get_icp, create_form, list_forms, create_landing_page, list_landing_pages, show_suggestions • Operations — analyze_contacts, get_contact_details, update_contact, save_contacts_to_crm, export_contacts, get_dashboard_stats, get_credit_balance Example prompts to try: • "Find C-suite contacts at fintech companies that raised Series A in the last 6 months." • "Scan my open deals for buying intent and prioritize follow-ups." • "Generate a re-engagement campaign for contacts who opened my last newsletter but didn't reply." • "Show me my deals pipeline by stage with weighted value and win rate." • "Generate a landing page for my Q2 webinar with a registration form." Built for founders, SDRs, RevOps, and growth teams who want their CRM to take action — not just store records. Install: https://api.xmagnet.ai/claude · Site: https://xmagnet.ai · Privacy: https://xmagnet.ai/privacy-policy · Terms: https://xmagnet.ai/terms-of-service · Support: ashish.sinha@xmagnet.ai
Agent personas for Claude. 16 tools, 13 personas, 3 workflows. Zero extra API cost. Free.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/osherai/pipedrive-mcp-python'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
