Loading ToolBench
Model Context Protocol (MCP) server for Salesforce Marketing Cloud Engagement (MCE)
This server has 4 tools with reasonable naming and schema coverage, but exhibits moderate gaps in parameter descriptions, unclear use cases, and missing output validation guidance. Tools follow verb_noun convention and use enums appropriately, but descriptions lack the specificity needed for LLM tool selection. Schema definitions are present and use Zod correctly, but several parameters lack detailed constraints and guidance. No error handling strategy visible for REST/SOAP failures.
Returns Marketing Cloud Engagement documentation links and how to use this MCP server (tools, BU scoping, examples).
Health check tool. Echoes input and confirms server readiness.
Generic REST request for Salesforce Marketing Cloud Engagement. Provide method, path, query, headers, and optional JSON body. OAuth is injected; retries and timeouts handled.
Generic SOAP request for Salesforce Marketing Cloud Engagement. Supports Create, Retrieve, Update, Delete, Perform, Configure. Either provide properties/filter/options or a raw XML payload.
mce_v1_rest_request and mce_v1_soap_request are overly generic and lack parameter descriptions. Parameters like 'profile', 'businessUnitId', 'objectType', 'filter', and 'options' have no inline documentation of what values are valid or how they affect behavior.
mce_v1_rest_request accepts unbounded parameters. 'timeoutMs' has no min/max. 'attachments' array has no size limits. Large or malformed inputs could cause API timeouts or memory exhaustion without guidance.
No error handling or recovery guidance visible. Tools return status codes (HTTP, SOAP) but lack actionable error messages. An LLM receiving 'status=401' has no instruction on whether to retry, ask the user, or investigate credentials.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
mce_v1_rest_request and mce_v1_soap_request output schemas use 'any' types (data: any, results: array(any)). This defeats LLM reasoning, the agent cannot know what fields to extract or what to do next. Responses must be structured.
mce_v1_soap_request provides two input paths: structured (properties/filter/options) and raw XML. Dual APIs increase complexity, error surface, and LLM confusion. Should pick one or document when to use each.
No indication of which operations are safe (GET/read) vs. destructive (DELETE/write). Tools should declare risk/idempotency via tool annotations or description callouts so agents know if they can retry safely.
Documentation tool returns a long text blob rather than structured reference data (links as key-value pairs, examples as objects with method/path/query fields). Agents would benefit from structured output for programmatic lookup.