Three tools with clear verb-noun naming (describe_, create_, soql_) and adequate descriptions (100-150 chars each). All parameters have type strings and descriptions. However, critical gaps: no output schemas documented, no error handling guidance, no parameter constraints (enums, ranges), and descriptions lack actionable context (when to use, what to expect). The fieldsJson parameters accept free-form JSON strings without validation hints. No mention of pagination, result limits, or field filtering. Security concern: targetUsername parameter enables user impersonation without documented permission checks or audit trail. Tools are directly visible in source with @McpTool annotations, so no inference penalty applies.

• Document output schemas for all three tools. Example for describe_sobject: 'Returns {fields: [{name, type, createable, updateable, ...}], ...}'. Example for create_record: 'Returns {id, success, errors: []}'. This enables LLMs to plan downstream calls.
• Add enum constraints or format hints to fieldsJson parameters. Replace 'JSON object of field name/value pairs' with 'JSON object where keys are valid Salesforce field names and values match field types (string, number, boolean, date). Example: {"Name":"Acme","Industry":"Technology","AnnualRevenue":5000000}'.
• Document permission requirements and audit trail. Add to targetUsername description: 'Requires admin or user-impersonation permission. All operations are logged with caller identity, timestamp, and parameters for compliance.'
• Enhance error messages with recovery guidance. In errorJson(), categorize errors: 'Invalid field "XYZ", call describe_sobject() first to see available fields' or 'User not found, verify targetUsername exists in your Salesforce org'.
• Add pagination and result limits to soql_query. Accept optional limit (1-10000, default 100) and offset parameters. Document: 'Returns at most 100 records per call. Use offset to paginate. Include total_count in response so LLM knows if more results exist.'