Pipedrive MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools are clearly distinct by resource type (activities, deals, organizations, persons, etc.) and action (get vs. search). However, some ambiguity exists between 'get_overview', 'get_quarter_summary', and 'get_quarterly_progress', which all provide high-level metrics and could be confused for overlapping purposes. The search tools also have some overlap (e.g., 'search_items' vs. specific resource searches), but descriptions help differentiate them.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, using snake_case uniformly. All tools start with 'get_' or 'search_', followed by the resource name (e.g., 'get_deals', 'search_persons'), with variations like 'summary' or specific qualifiers (e.g., 'get_current_quarter_deals') maintaining this structure. There are no deviations in naming conventions.
Tool Count3/5
With 30 tools, the count is borderline high for a CRM server, as it includes many specialized variants (e.g., summary versions, quarterly tools) that might be excessive. While Pipedrive's domain is broad, 30 tools feels heavy and could overwhelm agents, though not extreme. A more streamlined set of 15-20 tools might be more appropriate.
Completeness4/5
The tool surface provides comprehensive read/search coverage for core CRM resources (deals, persons, organizations, activities, notes, users, pipelines, stages) with both detailed and summary views. However, there are notable gaps in write operations (e.g., create, update, delete), which are essential for full lifecycle management in a CRM system. Agents can perform queries effectively but may fail when needing to modify data.
Average 2.9/5 across 30 of 30 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure, yet it provides no information about read-only status, pagination behavior, rate limits, or what constitutes a match. This leaves the agent with no safety or 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While not verbose, the three-word description suffers from under-specification rather than effective conciseness. For a tool with 7 parameters and numerous search-related siblings, this length is inappropriately minimal and fails to front-load any meaningful context.
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?
Given the complexity (7 parameters, 6 optional), lack of annotations, no output schema, and dense sibling space with overlapping functionality (get_deals, search_items, search_summarized), the description is inadequate. It relies entirely on the schema for parameter documentation without explaining the search domain or return 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?
The input schema has 100% description coverage for all 7 parameters (e.g., 'Comma-separated fields to search in'), so the baseline score of 3 applies. The description adds no semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search for deals' is essentially a tautology that merely converts the snake_case tool name into sentence form with minimal grammatical expansion. It fails to specify the scope of search (e.g., exact vs. fuzzy matching) or distinguish from sibling tools like get_deals or search_items.
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?
The description provides no guidance on when to use this search functionality versus retrieving deals directly via get_deals, or when to use search_items versus this specific deal search. No prerequisites or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It omits critical details: whether search is case-sensitive, supports wildcards, relevance scoring, or pagination behavior (despite having start/limit parameters).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While only three words, this represents under-specification rather than efficient conciseness. The single sentence fails to earn its place by providing no information beyond the tool name itself.
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?
With 6 parameters, no output schema, no annotations, and numerous sibling tools (including get_persons and search_organizations), the description is inadequate. It should clarify the search algorithm and distinguish from listing operations.
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 100%, so the schema adequately documents all 6 parameters (term, fields, exact_match, etc.). The description adds no parameter-specific context, but baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search for persons' is a tautology that restates the tool name (search_persons). It states the verb and resource but offers no differentiation from sibling tools like get_persons, get_person, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this search tool versus get_persons (list all) or search_organizations. No mention of prerequisites, indexing delays, or search syntax requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to indicate whether this is a read-only/safe operation, expected data volume, pagination behavior, or any side effects. The verb 'Get' implies reading but lacks explicit safety confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (three words) with no structural issues or wasted text. However, its brevity results in under-specification rather than efficient information delivery.
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?
Given the presence of closely related siblings ('get_stage', 'get_pipeline', 'get_pipelines') and the lack of output schema, the description inadequately explains the tool's behavior. It omits critical context about default behavior when optional parameters are missing and retrieval scope.
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 100% ('Filter stages by pipeline ID'), so the schema adequately documents the parameter. The description adds no additional semantic context about the parameter, earning the baseline score for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get pipeline stages' is largely tautological, restating the tool name 'get_stages' with minimal expansion. While it confirms the domain (pipeline), it fails to distinguish this bulk-fetch tool from the sibling 'get_stage' (singular) or clarify the scope of retrieval.
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 guidance provided on when to use this tool versus alternatives like 'get_stage' (for single stage retrieval) or 'get_pipeline'. The description does not explain what happens when the optional 'pipeline_id' parameter is omitted (e.g., returns all stages vs. error).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 burden of behavioral disclosure. It fails to mention pagination behavior beyond the bare schema, rate limits, authentication requirements, or whether this is a safe read operation versus potentially expensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is not wasteful, but given 7 parameters, zero annotations, no output schema, and numerous similar sibling tools, it is undersized rather than appropriately concise. Front-loading is impossible with such brevity.
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 tool with 7 filterable parameters and multiple similar siblings, the description is incomplete. It should explain pagination limits, the relationship between filter_id and other filter parameters, and when to prefer search_deals versus this listing endpoint.
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?
With 100% schema description coverage, the structured fields already document start/limit pagination and filtering options sufficiently. The description adds no additional parameter context (e.g., that status filters are mutually exclusive with filter_id, or pagination best practices), warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the basic action (Get) and resource (deals from Pipedrive), but lacks specificity to distinguish from siblings like get_deal (singular), search_deals, or get_deals_summary. It doesn't clarify if this is a bulk listing operation versus a targeted fetch.
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 guidance provided on when to use this tool versus the 6+ sibling deals tools (e.g., search_deals for queries, get_deal for single record retrieval, get_deals_summary for analytics). No mention of prerequisites or filtering recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden of behavioral disclosure. It does not indicate this is read-only/safe, does not explain default behavior when filters are omitted (returns all notes?), pagination behavior beyond the schema defaults, or any rate limiting concerns for large datasets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the single sentence is not verbose, it suffers from under-specification rather than efficient precision. Given the lack of annotations and output schema, the description should be front-loaded with more behavioral context rather than being so terse.
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?
With 9 parameters and no output schema or annotations, the description leaves significant gaps. It fails to explain the relationship between the various filter parameters (user_id, deal_id, person_id, org_id) and their combinability, nor does it address return values or error conditions expected from this complex query tool.
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 100%, so the schema adequately documents all 9 parameters (pagination, entity filters, pinned flags). The description adds no parameter-specific guidance, but the baseline score of 3 applies when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the basic action (Get a list) and resource (notes from Pipedrive), but fails to distinguish from sibling tool 'get_note' (singular). It borders on tautology by restating the tool name without clarifying when to use the plural/list version versus the singular fetch.
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 guidance provided on when to use this tool versus 'get_note' or other sibling tools. No mention of prerequisite conditions (e.g., needing specific IDs for filtering) or when to apply which filters among the 9 available parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers none. It does not indicate return format, pagination behavior, permission requirements, or whether 'all' refers to all accessible pipelines globally or within a specific scope.
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?
The description is extremely brief at three words. While it wastes no words, it is insufficiently sized for the tool's complexity given the sibling context and lack of output schema. However, the structure itself is appropriately concise.
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?
Given the presence of a singular variant sibling tool ('get_pipeline') and the absence of an output schema, the description should clarify the scope of 'all' and hint at return structure. It fails to provide necessary context for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters. Per evaluation guidelines, tools with 0 parameters receive a baseline score of 4, as there are no parameter semantics to clarify beyond what the empty schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all pipelines' is essentially a tautology that restates the tool name. While it indicates the tool retrieves multiple items, it fails to distinguish from the sibling tool 'get_pipeline' (singular) or clarify what constitutes a pipeline in this CRM context.
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 guidance provided on when to use this tool versus the singular 'get_pipeline' or other filtering tools. There are no stated prerequisites, constraints, or conditions that would help an agent select this over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but mentions only the basic read operation. It omits pagination behavior details despite having pagination parameters, says nothing about rate limits, auth requirements, or whether results are cached versus real-time.
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?
The single sentence is efficiently structured with no redundant words, delivering the core intent compactly. However, the extreme brevity becomes a liability given the tool's complexity and sibling relationships, preventing a higher score.
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 tool with five optional filtering parameters, no output schema, and numerous siblings including search variants, the seven-word description is insufficiently contextualized. Without annotations or return value documentation, the description should elaborate on result structure and behavioral specifics but does not.
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?
The input schema has 100% description coverage for all five parameters (start, limit, user_id, filter_id, first_char), adequately documenting pagination and filtering semantics without needing restatement in the description. With high schema coverage, the baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the basic action ('Get') and resource ('organizations') but lacks specificity regarding scope and filtering capabilities. It does not distinguish this listing tool from siblings like `get_organization` (singular retrieval), `get_organizations_summary` (summary data), or `search_organizations` (search functionality), leaving ambiguity about when to select this specific variant.
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?
The description provides no guidance on when to use this tool versus alternatives or what prerequisites might exist. There are no stated conditions, exclusions, or comparisons to inform the agent's selection among the numerous sibling organization-retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Merely states it retrieves a list without disclosing pagination behavior, data completeness guarantees, or access scope implied by the filtering parameters.
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?
Extremely brief (7 words) and front-loaded with action verb. No wasted words, though brevity comes at cost of helpfulness given the tool's complexity.
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?
Insufficient for a 5-parameter filtering/pagination tool with no output schema or annotations. Omitting mention of pagination strategy or filtering capabilities leaves significant gaps despite full schema coverage.
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 has 100% description coverage, so baseline applies. Description adds no parameter-specific context beyond what the schema already documents for the five filtering/pagination options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
States basic action (get/list) and resource (persons) with source system (Pipedrive), but fails to distinguish from sibling tools like 'get_person' (singular retrieval) or 'search_persons' (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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this bulk retrieval endpoint versus singular 'get_person', summary 'get_persons_summary', or 'search_persons' alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosure burden. However, it reveals nothing about search semantics (fuzzy vs exact matching behavior), pagination behavior, return values, or read-only status. The schema hints at 'exact_match' and pagination, but the description adds no context.
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?
The description is extremely brief at three words with zero redundancy. However, given the tool's complexity (5 parameters including pagination controls), this brevity may be inadequate rather than appropriately concise. No structural issues.
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 search tool with 5 parameters, pagination support, and no output schema or annotations, the description is incomplete. It fails to explain the search scope, what fields are available to search (hinted at only in the 'fields' parameter), or how results are returned.
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?
With 100% schema description coverage across the 5 parameters, the baseline score is 3 per the rubric. The description 'Search for organizations' adds no additional parameter semantics beyond what the schema already provides (term, fields, exact_match, start, limit).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the core action ('Search') and resource ('organizations'), but is extremely minimal and borderline tautological (tool name is 'search_organizations', description says 'Search for organizations'). It fails to differentiate from sibling tools like 'get_organizations' or 'search_persons'.
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?
Contains no guidance on when to use this tool versus alternatives like 'get_organizations' (which likely retrieves specific records by ID) or 'search_persons'/'search_deals'. No mention of prerequisites, filtering logic, or expected use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It omits whether this is read-only (though implied by 'Get'), what specific metrics are returned, data freshness, or computational cost. 'Comprehensive' and 'key metrics' are vague descriptors that disclose little about actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence structure is appropriately concise, but wastes words on vague modifiers ('comprehensive', 'key') without adding specific value. 'Current quarter context' is somewhat redundant given the 'quarter' parameter options.
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?
Given the lack of output schema and the presence of multiple similar summary tools (activities, deals, persons), the description inadequately specifies what domains this summary covers. It mentions 'metrics' but not whether these include deals, revenue, activities, or pipeline data, leaving significant gaps for a 'summary' tool.
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 coverage is 100%, providing clear descriptions for 'quarter', 'year', and 'user_id'. The description adds no additional semantic clarity (examples, format constraints, interaction between optional params) beyond what the schema already provides, warranting the baseline score.
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?
The description uses a clear verb ('Get') and resource ('quarterly summary') and specifies it includes 'key metrics' and 'current quarter context'. However, it fails to distinguish from the sibling tool 'get_quarterly_progress', leaving ambiguity about when to choose this over that alternative.
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 guidance is provided on when to use this tool versus alternatives like 'get_quarterly_progress', 'get_deals_summary', or 'get_current_quarter_deals'. There are no prerequisites, exclusions, or workflow suggestions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers almost no behavioral context. It does not mention pagination behavior, rate limits, response format, or whether results are cached vs. real-time.
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?
The single sentence wastes no words and is appropriately front-loaded, but is so terse that it under-delivers value for a 6-parameter tool with multiple siblings.
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 tool with 6 filtering/pagination parameters, no output schema, and no annotations, a one-sentence description is inadequate. It lacks context on parameter relationships (e.g., mutual exclusivity of user_id vs filter_id) and output structure.
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?
Input schema has 100% description coverage, documenting all 6 parameters including pagination and filter options. The description adds no parameter semantics beyond what the schema already provides, meeting the baseline score of 3 for high-coverage schemas.
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?
The description uses the specific verb 'Get' with resource 'list of activities' and source 'Pipedrive', making the basic purpose clear. However, it fails to distinguish from sibling tool 'get_activity' (singular), which likely retrieves a single activity rather than a list.
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?
The description provides no guidance on when to use this tool versus 'get_activity' or 'get_activities_summary', nor does it mention when filters should be applied versus retrieving all activities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure burden. It implies a read operation via 'Get' but does not state whether it's read-only, safe to retry, or what happens when the ID is not found (exception vs null return).
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?
Single sentence of appropriate length for a simple retrieval tool. No redundancy or waste, though minimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple single-parameter getter with complete schema coverage, but lacks domain context (e.g., what constitutes an 'activity' in this CRM system) and error behavior documentation expected when no output schema exists.
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 100% (the single 'id' parameter has description 'Activity ID'), so the schema fully documents inputs. The description adds no additional parameter semantics, meeting the baseline score for high-coverage schemas.
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?
The description uses specific verb 'Get' and resource 'activity', with 'specific' and 'by ID' indicating singular retrieval. However, it does not explicitly distinguish from sibling tool 'get_activities' (plural) or state when to use one versus the other.
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 guidance provided on when to use this tool versus alternatives like 'get_activities' or 'search_items'. No mention of prerequisites like needing to know the activity ID beforehand.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Get' implies a read-only operation, the description omits error handling (e.g., invalid ID), return structure, authentication requirements, or rate limits. This leaves significant behavioral gaps for a data retrieval 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?
The description is extremely concise at five words with the main action front-loaded. However, given the lack of annotations and the complex sibling landscape, this brevity crosses into under-specification. It wastes no words but omits necessary context.
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?
Given the presence of numerous sibling tools (get_deals, search_deals, etc.) and the absence of both output schema and annotations, the description is incomplete. It fails to clarify the distinction between retrieval by specific ID versus querying or bulk listing, which is essential for tool selection.
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 100% for the single 'id' parameter, which is documented as 'Deal ID' in the schema. The description references the parameter implicitly ('by ID') but adds no additional semantic context (e.g., expected format, where to find valid IDs) beyond the schema baseline.
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?
The description provides a clear verb ('Get'), resource ('deal'), and scope ('specific...by ID'), meeting the basic requirements for purpose clarity. However, it fails to explicitly differentiate from sibling tools like 'get_deals' or 'search_deals', which is critical given the presence of multiple deal-retrieval tools.
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?
The description contains no guidance on when to use this singular lookup versus the plural 'get_deals', the filtered 'get_current_quarter_deals', or the flexible 'search_deals'. Agents cannot determine selection criteria from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, yet description fails to disclose behavioral traits like what happens when ID is not found, whether this is a read-only operation, or what data structure is returned.
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?
Extremely concise (6 words) with no redundancy. Front-loaded with action and resource. Slightly too minimal—could benefit from one clarifying clause about return behavior without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a single-parameter retrieval tool, but given the rich ecosystem of similar siblings (get_organizations, search_organizations), lacks guidance on the specific retrieval pattern this implements.
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 has 100% coverage with 'Organization ID' already describing the parameter. Description adds no additional semantics, but baseline 3 is appropriate given schema completeness.
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 clear verb 'Get' and resource 'organization', and uses 'specific' and 'by ID' to implicitly distinguish from sibling 'get_organizations' (plural/list). However, could explicitly name the sibling alternative for clarity.
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?
Provides no guidance on when to use this versus 'get_organizations', 'search_organizations', or other retrieval alternatives. No mention of prerequisites or error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, yet description fails to disclose error behavior (e.g., 404 vs null if person not found), return value structure, or whether this is a safe read-only operation. Carries minimal burden of behavioral disclosure.
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?
Extremely concise at six words. Action is front-loaded. No redundancy. However, brevity sacrifices opportunity to provide usage context that would elevate it to a 5 without significantly impacting length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple singleton fetch operation with 100% schema coverage. Missing output description (no output schema provided) and lacks behavioral safety hints that annotations would typically cover. Sufficient but minimal.
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 coverage is 100% with 'id' fully described as 'Person ID'. Description reinforces this with 'by ID', matching the schema semantics. No additional parameter guidance needed given single, well-documented required parameter.
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?
Uses specific verb 'Get' and resource 'person', and specifies 'by ID' which implicitly distinguishes from sibling list/search operations (get_persons, search_persons). However, lacks domain context (e.g., CRM contact vs employee) and doesn't explicitly contrast with plural variants.
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?
Provides no explicit guidance on when to use this versus get_persons or search_persons. The phrase 'by ID' implies prerequisite knowledge of the identifier, but does not state this requirement explicitly or mention error conditions when ID is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Get' implies read-only access, there is no information about error handling, rate limits, caching behavior, or the structure of returned data.
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?
The description is extremely concise at five words with no redundancy or wasted language. However, given the lack of output schema and annotations, it may be overly minimal—slightly more detail about return values would improve utility without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter retrieval tool with complete schema documentation, the description is minimally adequate. However, the absence of an output schema and annotations means critical information about the pipeline object structure and error scenarios is missing.
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?
The input schema has 100% description coverage ('Pipeline ID'), so the baseline score applies. The description adds no additional semantics about the ID format or valid ranges, but the schema documentation is sufficient.
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?
The description clearly states the action (Get), resource (pipeline), and identification method (by ID). It implies a singular retrieval operation distinct from the sibling 'get_pipelines', though explicit differentiation is not provided.
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 guidance provided on when to use this tool versus the sibling 'get_pipelines' or related tools like 'get_stage'. No mention of prerequisites, permissions, or error conditions (e.g., invalid ID).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses 'forecasting data' (indicating deal probability calculations) and 'date awareness' (implying automatic current quarter detection), but omits safety information (read-only status), side effects, or rate limits.
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?
Single sentence, front-loaded with the action verb. While efficient, 'date awareness' is vague and could be replaced with more specific behavioral context. No redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should better explain what 'progress tracking' returns (metrics, deals, summary?). It mentions key features (forecasting, quarterly scope) but leaves the actual return structure undefined.
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 100%, establishing a baseline of 3. The description mentions 'forecasting data' which aligns with the include_forecast parameter, and 'current quarter' hints at implicit date filtering not shown in the schema, but adds no syntax, format, or dependency details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool gets 'progress tracking' for the 'current quarter' with 'forecasting data,' which provides some scope, but 'progress tracking' remains vague and fails to distinguish from siblings like get_quarter_summary or get_current_quarter_deals. The verb 'Get' is generic.
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 guidance is provided on when to use this tool versus alternatives like get_quarter_summary, get_overview, or get_current_quarter_deals. There are no exclusions, prerequisites, or workflow positioning hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 burden of behavioral disclosure. While 'Get' implies read-only access, the description does not explicitly confirm this is safe/non-destructive, disclose pagination behavior, mention rate limits, or describe what user data fields are returned.
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?
Single sentence, front-loaded with the verb 'Get'. Zero redundancy. However, given the complete lack of annotations and output schema, the extreme brevity leaves significant behavioral context undocumented, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for identifying the operation but incomplete regarding behavioral expectations. Without output schema or annotations, the description should ideally explain that this returns a paginated list of user objects and may require multiple calls for large organizations.
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?
Input schema has 100% description coverage (start and limit are fully documented). The description adds no parameter-specific context, but with complete schema coverage, the baseline score of 3 is appropriate as the schema carries the semantic load.
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 specific verb (Get), resource (users), and scope (from Pipedrive). The parenthetical '(salespersons)' adds helpful specificity distinguishing internal users from 'persons' (contacts) in Pipedrive terminology, and 'all' distinguishes it from sibling 'get_user'. However, it doesn't explicitly clarify the difference between users and persons for agents unfamiliar with Pipedrive's data model.
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?
Provides no guidance on when to use this tool versus alternatives like 'search_items' or sibling 'get_user'. Does not mention pagination requirements for large user bases or when to prefer single-user lookup versus listing all users.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 burden of behavioral disclosure. It fails to mention pagination behavior (despite start/limit parameters), result format, whether searches are case-sensitive, or performance characteristics. The phrase 'search across' implies a read operation but lacks specifics.
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?
Extremely concise at one sentence. While no words are wasted and the core purpose is front-loaded, the brevity approaches under-specification given the 8 parameters and lack of supporting annotations.
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?
Insufficient for complexity. With 8 parameters, no output schema, and no annotations, the description should explain pagination, field selection behavior, and result structure. As-is, it leaves critical operational context undocumented.
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?
With 100% schema description coverage, the baseline is 3. The description implies the 'item_types' parameter by mentioning 'multiple item types' but does not add syntax details, format constraints, or examples beyond what the schema already documents for the 8 parameters.
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?
The description clearly states the verb (search) and scope (across multiple item types in Pipedrive). The phrase 'multiple item types' effectively distinguishes this from siblings like search_deals, search_persons, and search_organizations which handle single types.
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 explicit guidance provided on when to use this tool versus the specific single-type search siblings (search_deals, search_persons, etc.) or when cross-type searching is preferred. No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosure burden. While 'authenticated' hints at auth requirements, the description fails to specify what 'details' are returned (fields, structure), whether the data is cached, or other behavioral traits like idempotency.
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?
Single sentence is appropriately front-loaded with the action. Efficient length for a zero-parameter tool, though 'details' is slightly vague and could be more specific about what user properties are fetched.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple identity retrieval tool, but lacks return value documentation needed given the absence of an output schema. Does not mention what user attributes (ID, email, permissions) are included in the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, establishing the baseline score of 4 per the rubric. The description correctly implies no inputs are needed beyond the implicit authentication context.
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 clear verb ('Get') and specific resource ('details of the current authenticated user'). The term 'current' implicitly distinguishes it from sibling tools 'get_user' and 'get_users', though it doesn't explicitly contrast them.
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?
Provides no guidance on when to use this versus alternatives like 'get_user' (e.g., when you don't know the user ID) or when it should be invoked (e.g., at session start). Contains no 'when-not-to' or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States 'Get' implying read-only access, but fails to disclose error behavior (e.g., ID not found), authorization requirements, or return structure. Minimal behavioral context provided.
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?
Extremely concise five-word sentence with zero redundancy. 'specific' distinguishes from plural sibling; 'by ID' references the parameter. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple single-resource getter with 100% schema coverage, but gaps remain given no output schema exists. Missing error handling, return value structure, or content descriptions that would help an agent handle responses appropriately.
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 coverage is 100% (single parameter with description 'Note ID'). Description mentions 'by ID' which aligns with the parameter, but adds no additional semantic detail about ID format ranges, validation rules, or required context beyond what the schema already documents.
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 clear verb ('Get') and resource ('note') with scope ('specific', 'by ID'). Distinguishes from sibling 'get_notes' by emphasizing singular retrieval via ID, though could clarify what constitutes a 'note' in this CRM context.
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?
Lacks explicit when-to-use guidance versus alternatives like 'get_notes' or search patterns. While 'by ID' implies usage when an identifier is known, it does not state when to prefer this over filtering multiple notes or searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Get', failing to indicate whether the operation is read-only, what happens if the ID is invalid/not found, or what data structure is returned.
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?
The description is a single, efficient sentence with the action verb front-loaded. There is no redundant or wasted text, and the length is appropriate for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter retrieval tool with full schema coverage, the description is minimally adequate. However, given the lack of output schema and annotations, it omits expected details about return values or error conditions (e.g., 'returns stage object or 404').
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?
The input schema has 100% description coverage ('Stage ID'), establishing a baseline of 3. The description mentions 'by ID' which aligns with the parameter, but adds no additional semantic context such as ID format constraints or lookup behavior beyond what the schema already provides.
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?
The description uses a clear verb ('Get') and resource ('stage') and qualifies the scope with 'specific' and 'by ID'. However, it does not explicitly contrast with the sibling tool 'get_stages' (plural), leaving the agent to infer the distinction from the naming convention alone.
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?
The description provides no guidance on when to use this tool versus alternatives like 'get_stages' or 'get_pipeline', nor does it mention prerequisites such as needing a valid stage ID from a prior call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. While 'Get' implies read-only, the description omits error behavior (e.g., 'not found' handling), authentication requirements, and what specific user details are returned. Lacks safety and behavioral context expected for unannotated tools.
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?
Single sentence, eight words. Front-loaded with action verb, zero redundancy. Appropriate length for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple 1-parameter retrieval tool, but given no output schema exists, the description could specify what user details are returned (profile, permissions, etc.) or error conditions. Acceptable but minimal.
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 coverage is 100% with 'id' fully documented in the schema. Description mentions 'by ID' which aligns with the parameter but adds no additional semantic value (format constraints, example IDs, relationship to other parameters). Baseline 3 appropriate given schema completeness.
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?
Clear verb (Get) and resource (user) with specific identifier (by ID). However, it fails to distinguish from sibling tools like 'get_users' (batch retrieval) or 'get_current_user' (authenticated user context).
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?
Provides no guidance on when to use this single-user lookup versus the plural 'get_users' or 'get_current_user'. The phrase 'by ID' implies usage but doesn't explicitly state selection criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses key behavioral traits: 'summarized results' and 'token-optimized' indicate reduced payload size versus full searches. However, it omits details about what specific fields are returned, omitted, or how the summary is constructed.
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?
Extremely concise at 9 words. Every element earns its place: action ('Search'), scope ('across all Pipedrive items'), output type ('summarized results'), and key characteristic ('token-optimized'). No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Input parameters are fully schema-documented, but given zero annotations, no output schema, and the presence of multiple overlapping search siblings, the description should explain what 'summarized' actually includes/excludes to aid tool selection. Adequate but incomplete.
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 coverage is 100%, establishing a baseline of 3. The description adds no specific parameter guidance beyond what's in the schema (e.g., no format details for 'item_types' comma-separation or 'term' syntax beyond the schema's 'Search term').
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?
Clear verb 'Search' and resource 'Pipedrive items'. The phrase 'summarized results (token-optimized)' distinguishes this from sibling search tools like search_items and get_deals by indicating compressed output, though it doesn't explicitly name the alternatives.
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 explicit guidance on when to use this versus the numerous sibling search tools (search_deals, search_persons, search_items, etc.) or when to prefer summarized over full results. The term 'summarized' implies usage but lacks explicit when/when-not direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, description adds valuable behavioral context about token optimization and field reduction. However, omits other behavioral traits like confirming read-only safety, pagination behavior, or cache characteristics that annotations would typically cover.
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?
Single efficient sentence with clear front-loading. Parenthetical '(optimized for token usage)' and dash 'shows essential fields only' both earn their place by clarifying the summary nature without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a 3-parameter read tool: explains the summary nature compensating for lack of output schema. However, with no annotations and no output schema, could benefit from mentioning pagination behavior or filtering capabilities (user_id) explicitly in the description.
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 has 100% description coverage (start, limit, user_id). Description provides baseline context by implying pagination via 'list', but doesn't add parameter-specific semantics, syntax, or format details beyond what the schema already provides.
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?
Clear verb 'Get' + resource 'organizations' with specific modifier 'summarized'. Distinguishes from sibling 'get_organizations' via 'essential fields only' and 'optimized for token usage', though it doesn't explicitly name the alternative tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage guidance through 'optimized for token usage', suggesting when to use (token-constrained contexts). However, lacks explicit 'when-not-to-use' or direct comparison to 'get_organizations' or 'search_organizations' siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It successfully communicates that this returns a 'summarized' view with 'essential fields only' and is 'optimized for token usage,' indicating the response payload is smaller than full deal objects. However, it omits other behavioral traits like safety (read-only implied by 'Get' but not stated), permissions required, or error conditions.
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?
Description is a single, dense sentence with no waste. The parenthetical '(optimized for token usage)' and em-dash clause add value without verbosity. Every word earns its place by conveying both purpose and behavioral optimization.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description partially compensates by characterizing the output ('summarized,' 'essential fields'). However, given zero annotations and no output schema, completeness suffers from missing behavioral guarantees (read-only status) and response structure details.
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 100%, providing complete parameter documentation (pagination, status enum, filters). The description adds no specific parameter semantics beyond the schema, which is acceptable when schema coverage is high, meeting the baseline.
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?
Clear verb ('Get'), resource ('deals'), and scope ('summarized'). The phrase 'optimized for token usage' and 'essential fields only' effectively distinguishes this from sibling get_deals (implied to be full detail), though it does not explicitly name the sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage context via 'optimized for token usage,' suggesting when to choose this over alternatives (when token conservation matters). However, it lacks explicit 'when not to use' guidance or named sibling alternatives (e.g., 'use get_deals for full details').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the token-efficient nature and mentions 'key metrics' and 'recent items' as return contents. However, it omits response structure, calculation methods for metrics, pagination behavior, and whether the user_id filter restricts the entire overview or just recent items.
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?
Single sentence with zero waste. The core action and resource appear first ('Get a high-level overview'), followed by content details ('key metrics and recent items'), and ends with the efficiency characteristic. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three optional parameters and no output schema, the description adequately hints at return contents ('metrics', 'recent items') but falls short of describing the actual response structure. For a read-only overview tool with 100% schema coverage, the description covers intent but lacks operational specifics expected when no annotations or output schema exist.
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 coverage is 100%, establishing a baseline of 3. The description mentions 'recent items' which maps to the include_recent_deals and include_recent_activities parameters, reinforcing their purpose. However, it adds no semantic detail about the user_id parameter beyond the schema's 'optional' designation, nor does it explain interaction effects between parameters.
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?
The description uses a specific verb ('Get') and resource ('high-level overview'), clearly indicating this is an aggregate dashboard endpoint rather than a specific entity fetcher. The mention of 'key metrics and recent items' clarifies the content scope, distinguishing it from siblings like get_deal or get_activities that return full records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(very token-efficient)' implies usage for quick summaries versus detailed data retrieval, but lacks explicit when/when-not guidance. It does not name alternatives (e.g., 'use get_deals for full deal details') or specify prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses summarization behavior ('essential fields only'), but omits read-only/safety status, rate limits, and pagination details beyond schema defaults.
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?
Single efficient sentence with front-loaded purpose. The parenthetical and dash construction is slightly irregular but all content earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Compensates for missing output schema by describing response characteristics ('summarized', 'essential fields'). Adequate for a 4-param filtering tool, though could specify what constitutes an 'activity' in this domain context.
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 has 100% description coverage (start, limit, user_id, done). Description adds no parameter-specific semantics, but baseline is 3 when schema coverage is high.
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?
Specific verb 'Get' + resource 'activities' + scope modifier 'summarized'. The parenthetical '(optimized for token usage)' and '- shows essential fields only' clearly distinguishes this from sibling 'get_activities' and other summary tools by specifying the token-efficient nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage via 'optimized for token usage' (suggests use when token conservation matters), but lacks explicit 'when to use vs when to use get_activities instead' guidance or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full disclosure burden. It successfully explains the key behavioral trait of automatic quarter determination based on the current date, which is crucial for agent expectations. However, it omits safety characteristics (read-only vs. destructive), return value structure, and error handling patterns that annotations would typically cover.
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?
The single sentence is appropriately front-loaded with the core action and resource. The parenthetical clarification '(automatically uses correct quarter based on today's date)' efficiently conveys the key value proposition without redundancy. No extraneous information dilutes the directive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description lacks information about return values (e.g., whether it returns a list, count, or summary object). While the tool name suggests the return type, explicit confirmation would strengthen completeness. The parameter schema is fully documented, making the definition minimally viable but not comprehensive.
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?
Input schema has 100% description coverage, establishing a baseline of 3. The description mentions 'date context' which aligns with the implicit quarter filtering, but does not add semantic clarification beyond the schema for specific parameters (e.g., explaining 'user_id' refers to deal owners, or detailing the status filter behavior).
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?
The description uses a specific verb ('Get') with clear resource ('deals') and scope ('current quarter'). It effectively distinguishes from sibling tool 'get_deals' by specifying the time-bounded scope and automatic date handling, and differs from 'get_quarter_summary' by targeting individual deals rather than aggregated data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage scenarios through 'automatically uses correct quarter based on today's date', suggesting when to use this tool (when manual date calculation should be avoided). However, it lacks explicit guidance on when to choose this over 'get_deals' or 'search_deals' for date-filtered queries, and states no prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Explains the data shape behavior (returns essential fields only), but lacks details on rate limits, caching, or specific field exclusions beyond the general summary note.
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?
Single sentence with zero waste. Front-loaded action verb ('Get') and immediate parenthetical clarification of optimization goal. Every word earns its place.
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?
Appropriately complete for a list summary tool. Explains the nature of returned data (summarized/essential fields) compensating for missing output schema, though could mention pagination behavior or total availability.
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 100% (all 3 parameters documented), so baseline score applies. Description does not add parameter-specific semantics beyond what the schema provides, but none is needed given complete schema coverage.
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?
Description provides specific verb 'Get', resource 'persons', and clearly distinguishes from sibling 'get_persons' via 'summarized', 'optimized for token usage', and 'essential fields only'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use (token optimization scenarios) via 'optimized for token usage', but does not explicitly name the alternative 'get_persons' for full data retrieval or state exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![pipedrive-mcp-server MCP server](https://glama.ai/mcp/servers/bratland/pipedrive-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/bratland/pipedrive-mcp-server)

Score Badge

Copy to your README.md:

[![pipedrive-mcp-server MCP server](https://glama.ai/mcp/servers/bratland/pipedrive-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/bratland/pipedrive-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bratland/pipedrive-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server