​
Introduction

Once you’ve explored available Agentforce Context Protocol (ACP) tools and understand their input and output parameters, the next practical step is to test them. Direct tool testing allows you to:

  • Verify your understanding of a tool’s functionality.
  • Experiment with different input values and observe the results.
  • Confirm that a tool is working as expected in your Salesforce environment.
  • Troubleshoot issues by isolating tool behavior.

The most common way to test individual tools is through the ACP Tool Explorer LWC (or a similar interface provided in your Salesforce org).

​
Using the ACP Tool Explorer for Testing

The ACP Tool Explorer, which you use to discover tools, often includes a feature to directly execute and test them.

​
Steps for Testing a Tool:

  1. Navigate to the ACP Tool Explorer:

    • As described in “Exploring Available Tools,” open the ACP Tool Explorer from the Salesforce App Launcher or your designated access point.

  2. Select a Tool:

    • Browse or search for the tool you wish to test.
    • Click on the tool to view its details.

  3. Access the Testing Interface:

    • Within the tool’s detail view, look for a “Test,” “Execute,” or “Run Tool” section or button. This interface will typically provide input fields for each of the tool’s parameters.

  4. Provide Input Parameters:

    • Carefully fill in the values for the tool’s input parameters, as detailed in “Understanding Tool Inputs and Outputs.”
    • Pay attention to required versus optional fields and the expected data types.
    • For complex inputs like JSON objects or lists, ensure the formatting is correct.

  5. Execute the Tool:

    • Once you’ve entered the inputs, click the “Test,” “Execute,” or “Run” button.
    • The Tool Explorer will send these inputs to the ACP and invoke the selected tool.

  6. Observe the Output:

    • After the tool executes, the Tool Explorer will display the output parameters returned by the tool.
    • Examine the output to see if the tool behaved as expected.
      • Check success flags or status indicators.
      • Review any data returned (e.g., record IDs, query results).
      • If an error occurred, inspect error_message or error_code fields for diagnostic information.

​
Example: Testing slack_send_message

If you were testing the hypothetical slack_send_message tool:

  • Inputs you might provide:
    • channel_id: (e.g., “C012345XYZ”) - The ID of a test Slack channel.
    • text: (e.g., “Hello from ACP Tool Explorer! This is a test.”)
    • as_user (optional): (e.g., false or leave blank)
  • Expected Outputs (on success):
    • success: true
    • message_ts: A Slack timestamp string (e.g., “1678886400.000123”)
    • error_message: null or empty

If the channel_id was incorrect, you might see:

  • success: false
  • message_ts: null
  • error_message: (e.g., “Error: Channel not found”)

​
Important Considerations for Testing

  • Environment: Be aware of the environment you are testing in (e.g., Sandbox, Production). Tests, especially those that create or modify data, can have real effects. Prefer testing in non-production environments whenever possible.
  • Permissions: Ensure the user you are logged in as (or the user configured for the ACP connection) has the necessary permissions in the target system (e.g., permission to post in a Slack channel, create a Salesforce record, etc.).
  • Data Sensitivity: Avoid using sensitive or personally identifiable information (PII) in your tests, especially if logging is enabled or if testing against production systems.
  • Idempotency: Understand if a tool is idempotent (meaning running it multiple times with the same inputs produces the same result without unintended side effects). For example, querying data is usually idempotent, but creating a new record is not.
  • Rate Limits: Be mindful of API rate limits on target systems if performing many tests in rapid succession.

​
What if a Tool Doesn’t Have a UI for Testing?

While the ACP Tool Explorer is the standard, in some rare cases or for very specific backend tools, a direct UI for testing might not be available. In such scenarios:

  • Developer Console (for Apex-based tools): Salesforce developers might test Apex-level tool invocations using Anonymous Apex in the Developer Console.
  • API Testing Tools (e.g., Postman): If ACP tools are exposed via an API layer, tools like Postman could be used, but this is less common for end-user testing.
  • Building a Simple Flow: You could build a very simple Salesforce Flow that calls the tool with fixed inputs to test its behavior.

However, for most users, the ACP Tool Explorer should be the go-to method.

​
Conclusion

Testing individual ACP tools is a vital step in understanding their capabilities and ensuring they function correctly within your specific Salesforce setup. The ACP Tool Explorer provides a convenient way to perform these tests, allowing you to experiment with inputs and analyze outputs directly. This hands-on experience builds confidence and proficiency in using ACP for Agentforce agents and automations.

With the completion of this guide, you have covered the fundamentals of discovering, understanding, and testing ACP tools!