External MCP reaches Agentforce: the real challenge starts after the first tool connects

The tool catalog is part of agent behavior

In MCP, a tool has a name, description and machine-readable inputSchema. The model uses that material to decide when to call the function and which arguments to supply. The specification also permits the list to change and lets the server notify clients of that change. Renaming a parameter, broadening a description or adding a destructive action is therefore not cosmetic: it can alter the agent's decision space. The contract should be versioned, reviewed and tested like an API, with positive examples, invalid inputs, size limits and a predictable structured result.

Salesforce import creates a useful barrier: discovered tools do not automatically enter the agent; an administrator chooses the allowlist and then adds actions to a subagent. Selection should be minimal and task-oriented. A logistics assistant that checks delivery dates and creates labels does not need functions that cancel orders or edit customers. OrbTrail recommends separating servers and credentials by domain and sensitivity, recording the hash or version of the approved schema and rerunning tests whenever tools/list changes. The allowlist narrows the visible surface, but does not replace server-side authorization.

Client credentials authenticates the application—not automatically the user

The example uses the OAuth 2.0 client credentials grant from an Anypoint Connected App. It fits machine-to-machine communication: Salesforce presents a client ID and secret, receives a bearer token and reuses it until renewal is required. The architectural consequence matters. The external service sees the integration identity, not necessarily the person who started the conversation. If the same token can query every warehouse or execute every operation, the agent inherits that reach even when the end user has narrower CRM permissions.

A narrowly scoped service identity may be enough for low-risk reads. Sensitive actions need an additional authorization decision based on trusted context: tenant, purpose, operation class and, where the design supports it, delegated identity. A user identifier freely generated by the model must never be accepted as authorization evidence. Secrets belong in credential management, never prompts, logs or responses; rotation must be rehearsed; and development, test and production should use separate clients and scopes. The OWASP MCP list highlights token exposure, scope creep and insufficient authorization as core risks for precisely this reason.

Retry semantics decide whether a failure becomes a duplicate charge

The article says the platform handles token acquisition and refresh, serialization, errors and retries. That convenience means the tool owner must define what can safely repeat. Reading the current time is naturally safe; creating a label, reserving inventory or initiating a refund is not. Every effectful action should accept a stable idempotency key, return an operation identifier and clearly distinguish failure before execution, partial failure and completion. A timeout does not prove that nothing happened. Without this contract, an automatic retry can duplicate the effect while the agent believes it is merely recovering.

Errors must also be useful to machines and people. JSON-RPC separates protocol failures, unknown tools, invalid arguments and internal errors; the domain should add stable codes for unavailable capacity, conflict, authorization and quota. The agent can then refuse, request correction, check status or escalate to a human instead of inventing an outcome from ambiguous prose. For irreversible operations, keep a human confirmation before invocation, as the MCP specification recommends, and record the relationship between session, tool, schema version, approved parameters and result.

CloudHub provides a control point, but teams still need to design the SLO

Anypoint API Manager can apply authentication, policies and rate limits, while tracking volume, client applications, HTTP codes, violations and average latency. Those features are an operating foundation, not a ready-made service-level objective. Before publishing a tool, define a latency budget that fits the conversation, maximum rate per client, timeout for each dependency, degradation behavior and alert. An endpoint that succeeds in two seconds during an isolated test may make the experience unusable when an agent performs several calls in sequence.

Traffic limits contain a subtlety: distributed policies need a shared counter across replicas, otherwise each replica can enforce its own quota. The documentation also shows that HTTP 429 blocks calls until the window ends. Clients and agents should treat that result as exhausted capacity, not absent data. For an initial production release, track at least success rate by tool, p50/p95 latency, 4xx by reason, 5xx, timeouts, retries, compensated operations and cost per completion. OrbTrail's analysis is that MuleSoft's real payoff appears when these signals become common across multiple agents—not when it merely hosts a script.

Conclusion: an MCP server should begin life as a platform product

The timezone walkthrough proves the integration no longer requires a handcrafted layer inside every org. The opportunity is meaningful: one governed capability can serve Agentforce, other MCP clients and several teams. Reuse also increases blast radius. A mature rollout starts with one read-only function, a narrow contract and metrics; validates agent selection with a prompt suite; introduces a reversible action with confirmation and idempotency; and only then moves into critical processes. MCP standardizes how a tool is presented and called. Security, meaning and reliability remain decisions for the team that publishes it.