Loading ToolBench
Model Context Protocol server for Salesforce DevTools (SFDT) — exposes deployment, testing, quality analysis, audit, and release management tools as MCP tools for AI agents.
SFDT MCP server has 21 tools with consistent naming (verb_noun pattern: sfdt_*) and reasonable descriptions (avg ~120 chars). All tools have input schemas with type definitions and parameter descriptions. However, output schemas are not documented in the provided source, parameter descriptions lack depth (missing format constraints, ranges, examples of valid values), and error handling guidance is absent. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications. Descriptions are functional but generic, they state WHAT the tool does but rarely explain WHEN to use it or dependencies. Parameter validation rules are underdocumented (e.g., sfdt_deploy's 'testLevel' enum is present but no guidance on when each level is appropriate).
Run read-only org health diagnostics (suspicious setup audit trail, license usage, MFA coverage, unused Apex classes, inactive users, deprecated API versions, inactive flows, unused permission sets, connected apps, missing field descriptions, unreferenced Apex, object access lint). Returns a normalised snapshot of check results.
Generate a changelog from git history and metadata changes.
Compare metadata between two orgs, or between local source and an org. Returns compare results.
Retrieve Apex code coverage metrics for a target org.
Perform a metadata deployment to a target Salesforce org. Supports a smart delta mode (only git-changed metadata with smart test selection). Potentially destructive.
Generate documentation for Salesforce metadata (Apex, LWC, Flows, etc.).
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields without knowing what each tool returns. This violates pattern:tool and pattern:response-shaper.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite clear risk classifications. Destructive tools (sfdt_deploy, sfdt_quick_deploy, sfdt_rollback) should be marked with destructiveHint=true to guide agent safety logic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Run metadata drift detection between a target Salesforce org and local source directories.
Analyze a single Salesforce Flow's quality (health rules, scoring, scheduled-flow math). Accepts raw Flow XML.
Scan Salesforce Flows in an org for health issues (infinite loops, missing error handlers, unused variables, etc.). Returns a normalised snapshot of flow health results.
Retrieve the result of a long-running async job (monitor, etc.) by job ID. Returns the final result or a 'still running' status.
Retrieve the latest structured or raw execution logs for DevOps actions.
Generate package.xml and destructiveChanges.xml manifests using Git diff analysis.
Run continuous org health monitoring (async background job). Returns a job ID; poll with get_parked_result.
Generate a pull request description using AI (requires AI provider configured).
Run sfdt pre-deployment validation checks (git clean state, branch naming rules, Apex test runs, coverage threshold checks, etc.). Useful before validation or deployment.
Analyze Apex test quality, generate IsTest boilerplate stubs, or generate a fix-plan for coverage gaps.
Quick deploy a previously validated metadata validation job using validation job ID.
AI-powered code review of git diff (requires AI provider configured).
Roll back the last successful deployment using org backup snapshots.
Scan metadata in a target org and return inventory results.
Perform a deployment validation dry-run on Salesforce without committing changes.
Parameter descriptions lack actionable constraints. E.g., sfdt_deploy's 'testLevel' enum is present but no description explains when to use RunAllTestsInOrg vs RunLocalTests. sfdt_manifest_from_git's 'package' param lacks format guidance (is it a directory name? a package alias?).
No error handling guidance. Tools lack recovery hints (e.g., 'If validation fails, check sfdt_logs to see which tests failed'). Agents cannot self-correct on failures.
Destructive tools (sfdt_deploy, sfdt_quick_deploy, sfdt_rollback) require confirmExecution=true but lack dry-run or confirmation-request pattern documentation. Agents may not understand the safety mechanism.