The Salesforce MCP server has 25 tools with generally present schemas and descriptions, but significant inconsistencies in quality. All tools have names following verb_noun conventions (get_, list_, create_, update_, delete_). Most have descriptions, though quality varies from adequate to terse. Schemas are present for all tools with proper JSON Schema structure and type definitions. However, parameter descriptions are inconsistent, some parameters lack descriptions entirely (e.g., 'nameFilter' in list_apex_triggers has no description beyond the key name), and several tools have descriptions under 50 characters. Error handling is minimal across the board, with no recovery guidance or actionable error messages visible in the code. The generic REST API tool (call_rest_api) is particularly concerning as it allows POST/PATCH/DELETE on arbitrary endpoints with free-form bodies, creating security and validation risks. Output schemas are not documented for most tools. The server is transport-limited (STDIO only), which caps protocol readiness regardless of definition quality. Average description length is ~120 characters, below the 194-char baseline for A+ tools. Parameter descriptions average ~40 characters, significantly below the 72-char baseline.

• Document output schemas for all tools. Add a 'Returns' section to each tool description listing the fields of the response object, their types, and what they represent. Example: 'Returns: { id (string), name (string), status (string: Completed|Processing|Failed) }'
• Add non-trivial descriptions to all parameters. Every parameter must have 10+ character description answering 'What does this control?' Example: 'nameFilter' → 'Filter Apex classes by name (partial match, case-insensitive)'
• Expand tool descriptions to 50-150 characters. Include WHEN to use the tool and any prerequisites. Example for run_tests: 'Execute Apex test classes. Returns test results with pass/fail status. Use after creating or modifying Apex code to verify correctness.'
• Sanitize all SOQL-building parameters. Replace string interpolation with parameterized queries or escape special characters. For nameFilter, escape single quotes and prevent wildcard injection.
• Refactor call_rest_api into specific, scoped tools (e.g., query_sobjects, get_sobject_record) that validate endpoint paths and request bodies against a whitelist. Remove generic PATCH/DELETE support or require explicit confirmation.
• Add structured error handling with recovery guidance. Example: 'Apex class not found (ID: 01p7Q000000...). Try list_apex_classes() with a name filter to find the correct class.'
• Implement confirmation/dry-run for destructive operations. Add a 'dryRun' boolean parameter to delete_apex_class and delete_apex_trigger, or create separate 'validate_deletion' tools.