Loading ToolBench
A server providing Salesforce API integration tools through the Model Context Protocol
This Salesforce MCP server has 9 tools with mixed quality. Strengths: all tools have descriptions (194-400+ chars), names follow verb_noun patterns (search_, describe_, get_, manage_), and input parameters have types and descriptions. Weaknesses: no input schemas are visible in the source code provided, only parameter descriptions in docstrings; no output schemas documented; error handling is generic ('Error...' strings with no recovery guidance); no tool annotations (readOnlyHint/destructiveHint); no pagination support despite tools returning potentially large datasets (query_salesforce_records, get_salesforce_validation_rules); manage_debug_logs is a compound tool doing enable/disable/retrieve in one tool rather than three. Per-tool analysis shows strong naming and adequate descriptions, but critical gaps in schema formalization and error handling push the overall score into the fair (C) range.
Get detailed schema metadata including all fields, relationships, and field properties of any Salesforce object. This tool provides a comprehensive view of an object's structure including: - Field names and types - Required/optional status - Lookup and master-detail relationships - Custom field attributes - Field-level help text and descriptions
Get the complete Salesforce object schema as raw JSON. This returns the unfiltered API response directly from Salesforce. This tool is useful when you need the complete, detailed metadata for advanced analysis or when you need to access specific metadata properties not included in the standard describe format.
Show all relationship fields (lookups, master-detail) for a Salesforce object. This tool identifies all relationship fields, showing: - Parent and child relationships - Lookup vs master-detail relationship types - Related object names - Cascade delete behavior - Required relationship status This is useful for understanding dependencies and connections between objects.
Get fields of a specific type for a Salesforce object. If no type is specified, returns all fields. This tool allows you to filter fields by their data type, which is useful when you're looking for specific kinds of fields such as: - Text fields (string) - Number fields (double, integer) - Date/time fields - Picklist fields - Reference/lookup fields - Formula fields - And more
No visible input schemas in FastMCP tool definitions. The source shows @mcp.tool() decorators with function signatures, but no explicit JSON Schema registration. Schema validation happens at function parse time, but LLMs cannot see formalized schema constraints (enums, min/max, patterns, required fields) without explicit schema objects.
No documented output schemas. Tools return plain strings (e.g. 'result = search_objects(pattern)' returns a str). LLMs cannot infer structure, field names, or downstream tool compatibility. query_salesforce_records should return a list of records with Id, Name, etc., but the docstring only says 'list of records', no field documentation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Get all values from a picklist field. This tool returns all available options for a dropdown/picklist field, including: - Value labels - API names - Default value indicator - Active/inactive status - Controlling field dependencies (if any)
Get validation rules for a specific object using Tooling API. This function retrieves all validation rules defined for a Salesforce object, including both active and inactive rules. It returns a formatted markdown table with comprehensive details about each rule.
Manage debug logs for Salesforce users - enable, disable, or retrieve logs. This function allows comprehensive management of Salesforce debug logs: 1. ENABLE: Set up debug logging for a specific user with a chosen log level 2. DISABLE: Turn off debug logging for a user 3. RETRIEVE: Get logs for a user, with options to view specific log details
Query Salesforce records using SOQL with filtering, sorting, and limiting options. This tool enables you to retrieve records from any Salesforce object with flexible querying options.
Search for Salesforce standard and custom objects by name pattern. This tool allows you to quickly find Salesforce objects (standard or custom) by searching for patterns in their names. It's useful when you're not sure about the exact name of an object or want to discover related objects.
manage_debug_logs is a compound tool combining three separate operations (enable, disable, retrieve) behind a 'operation' enum. This violates single-responsibility: an LLM must reason about which operation to use, parameters differ per operation (log_level required for enable, optional for others), and error handling is operation-specific. Should split into enable_debug_logs, disable_debug_logs, retrieve_debug_logs.
No pagination support. query_salesforce_records accepts a limit parameter (default 10), but no offset, cursor, or next_token. If an LLM needs 50+ records, it must make multiple sequential calls manually. No page count or total_records in response implies no guidance on whether more data exists.
Error handling is generic: all errors return 'Error <tool>: {str(e)}' with no recovery guidance. If describe_salesforce_object fails with 'Object not found', there's no hint to try search_salesforce_objects first. No error classification (retryable vs user-fixable vs fatal).
No tool annotations. ReadOnlyHint and DestructiveHint are absent. manage_debug_logs is marked WRITE in the summary but the tool definition has no @mcp.tool(requires=[...]) or hint. Most tools are read-only (search, describe, get, query) but LLMs cannot see this without annotations.
manage_debug_logs has conditional required parameters. log_level is required only for operation='enable', optional for others. The parameter description says 'required for enable operation', but FastMCP/LLMs cannot enforce conditional requirements. Should be split or require explicit validation with clear error messages.
No response field consistency. search_salesforce_objects returns 'a formatted list', describe_salesforce_object returns 'detailed schema information', but what fields? If an LLM calls search_salesforce_objects, can it extract object API names to pass to describe_salesforce_object? Unclear due to unstructured output.
query_salesforce_records's where_clause and order_by are free-form strings (no validation). LLMs can inject malformed SOQL, e.g. 'Status = "Active" OR 1=1' (SOQL injection risk). Should provide structured alternatives (e.g. filter objects with field/operator/value) or validate SOQL syntax server-side with clear error messages.