Loading ToolBench
MCP server providing Salesforce CRM and Pardot (Marketing Cloud Account Engagement) tools. Users connect via MCP OAuth 2.1. Provides tools for Salesforce operations (SOQL queries, lead/contact CRUD, pipeline reporting, activity history) and Pardot operations (prospects, campaigns, lists, forms, visitor activities, emails, lifecycle history).
This MCP server provides 22 tools for Salesforce and Pardot integration with HTTP transport. Naming is consistent (verb_noun pattern: sf_*, pardot_*) and descriptive. All tools have descriptions ranging from 56-152 characters, meeting baseline standards. However, critical gaps exist: (1) Input schemas are present but incomplete, many parameters lack `required` array declarations, min/max constraints, and enum values where appropriate. (2) Output schemas are NOT documented anywhere in the provided code, LLMs cannot reason about return structures, forcing trial-and-error tool usage. (3) Error handling is implicit (no visible error recovery guidance). (4) Parameter descriptions are minimal (12-82 chars) and sometimes omit format/constraint details. Overall, the server is functional but below production bar for agent reasoning.
Add a prospect to a Pardot list.
Get campaigns from Pardot.
Get emails from Pardot with optional filtering by campaign ID or prospect email.
Get form handlers from Pardot.
Get forms from Pardot.
Get lifecycle history (visitor activities and email records) for a prospect.
Output schemas are completely undocumented. LLMs cannot reason about return structures (fields, types, whether results are paginated, what IDs are included for chaining). Forces trial-and-error tool usage and prevents intelligent composition.
Input schemas lack `required` array declarations. Parameters like 'who_id' in sf_get_tasks and 'prospect_id' in pardot_update_prospect should be marked required, but no schema shows this. LLMs cannot infer which params are mandatory.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 67 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Get lists from Pardot.
Get a prospect from Pardot by exact email match.
Get prospects from Pardot with optional filtering by email, campaign, or list.
Get visitor activities from Pardot with optional filtering by prospect ID or email.
Set or update the Pardot Business Unit ID (BUID) for the current session.
Update a prospect in Pardot with specified fields.
Create a new lead in Salesforce.
Get combined activity history (tasks and events) for a lead or contact.
Get contacts from Salesforce with optional filtering by account and creation date.
Get events (activity records) from Salesforce with optional filtering.
Get leads from Salesforce with optional filtering by status and creation date.
Get tasks (activity records) from Salesforce with optional filtering.
Get a pipeline report of opportunities by stage and amount.
Run an arbitrary SOQL query against Salesforce and return all matching records.
Update a contact in Salesforce with specified fields.
Update a lead in Salesforce with specified fields.
No enum constraints on categorical parameters. 'status' in sf_get_leads accepts free-form strings ('Open - Not Contacted', 'Working') without enum declaration. LLMs will hallucinate invalid values.
List and discovery tools (pardot_get_campaigns, pardot_get_lists, pardot_get_forms, pardot_get_form_handlers) have NO input parameters at all. No pagination support (limit, offset, cursor). Large result sets will blow the context window without pagination guidance.
No error handling or recovery guidance visible. When sf_query fails or a Salesforce ID is invalid, LLMs have no guidance on what to do next. Raw API errors will be surfaced without context.
Parameter descriptions are minimal and lack format/constraint details. E.g. 'days_created' (12 chars) does not state min/max range (is 1 day valid? 365?). 'fields' object param (29 chars) doesn't specify allowed field names or types.
Tools with destructive side effects (sf_update_lead, sf_update_contact, pardot_update_prospect, sf_create_lead, pardot_add_prospect_to_list) do not declare this in descriptions. No confirmation pattern or dry-run support visible.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are visible in the tool definitions. Modern MCP spec supports these to help agents classify tools by risk, their absence removes safety signals.