The situation
An employee-facing AI application proposes this reference path: user -> agent host -> MCP client -> selected Salesforce MCP server -> approved Salesforce APIs/actions. The application may search/read authorized Cases and Knowledge and add internal Case notes. Account ownership changes and sensitive Contact exports are prohibited. Any separately approved high-value or destructive capability requires explicit human approval; approval must not override a prohibited operation.
Compare Salesforce Hosted MCP with a custom MCP adapter where their responsibilities differ. These are business capabilities to implement or select after checking the server catalog, not claims that named standard tools exist. (1) Identify host/client/server and tool/resource/prompt responsibilities. (2) Explain why discovery is not execution authorization and limit the exposed operation set. (3) For the documented Hosted MCP path, explain named-user OAuth authorization-code flow with PKCE and configured External Client App access; do not generalize that contract to every custom server. (4) Show where CRUD, FLS, sharing, and business authorization are enforced. (5) Validate Case identity, note visibility, content, and record relationships at the action boundary. (6) Design parameter-bound approval for an allowed high-risk extension. (7) Audit identity, operation, safe argument metadata and outcome. (8) Handle revoked access, timeouts and ambiguous writes without elevated fallback or duplicate notes. Distinguish client-side confirmation from server-side enforcement.
Consider in your response
- Separate MCP roles and discovery from authorization
- Apply implementation-specific identity contracts
- Constrain and validate Salesforce capabilities
- Audit and recover agent-initiated operations
