Skip to content

Testing and Debugging with Postman

Ross Belmont edited this page Apr 10, 2026 · 3 revisions

Once you've configured Postman with OAuth 2.0 authentication for Salesforce, you can test the MCP server by calling its tools directly. This is the single most valuable debugging tool at your disposal — and it's free.

Why Postman First?

When something isn't working, the first question is always: "Is it the MCP server or the MCP client?" Postman removes the LLM entirely from the equation. You send structured tool calls and receive structured responses — no language model interpretation, no client-specific behavior, no ambiguity.

  • If it works in Postman, the issue is with your MCP client.
  • If it doesn't work in Postman, the issue is with authentication, permissions, or server configuration.

This single step saves more debugging time than anything else.

Testing Tools Without Parameters

Some MCP tools don't require any input parameters, making them ideal for initial testing. Two simple examples are describeGlobal and getUserInfo.

To test a tool without parameters:

  • In the Message tab, you'll see a list of available tools on the left side
  • In the right pane, you'll see a JSON structure with "method": "tools/call" and a "params" section
  • Click on a tool name (such as describeGlobal or getUserInfo) in the left pane. Postman automatically populates the JSON in the right pane:
    {
      "method": "tools/call",
      "params": {
        "name": "describeGlobal",
        "arguments": {}
      }
    }
  • Click Run in the upper right corner
  • View the results in the Response pane at the bottom of the window

For describeGlobal, you'll see a list of all Salesforce objects available in your org. For getUserInfo, you'll see information about the current authenticated user.

Testing Tools With Parameters

Many MCP tools require input parameters. The soqlQuery tool is a good example that lets you execute SOQL queries against your Salesforce org.

To test the soqlQuery tool:

  • Click on soqlQuery in the tools list on the left side
  • Postman populates the JSON structure in the right pane:
    {
      "method": "tools/call",
      "params": {
        "name": "soqlQuery",
        "arguments": {}
      }
    }
  • Add your SOQL query to the arguments object. For example, to query Account records:
    {
      "method": "tools/call",
      "params": {
        "name": "soqlQuery",
        "arguments": {
          "query": "SELECT Id, Name, Type, Industry, Phone, Website, BillingStreet, BillingCity, BillingState, NumberOfEmployees, AnnualRevenue FROM Account WHERE Name = 'Abbott Insurance'"
        }
      }
    }
  • Click Run in the upper right corner
  • View the query results in the Response pane at the bottom

The response shows the matching Account records with all requested fields.

Running a SOQL query in Postman

What to Try Next

Once you've successfully tested these basic tools, you can explore other available tools:

  • getObjectSchema — Get detailed metadata about a specific Salesforce object
  • getRelatedRecords — Retrieve related records for a given record
  • listRecentSobjectRecords — Get recently viewed records of a specific object type
  • find — Search across multiple objects using SOSL

Each tool will have different required and optional parameters. Click on the tool name in Postman to see the parameter structure, then add your specific values in the arguments object before clicking Run.

Debugging Common Issues

Debugging Checklist

When something isn't working, run through this list:

  1. Verify authentication — Can you get a valid access token? Check token expiry. If using a refresh token, try requesting a fresh access token.
  2. Verify server activation — Is the server toggled on in Setup → API Catalog → MCP Servers? Activation can take up to 2 minutes.
  3. Verify scopes — Are you using mcp_api and refresh_token? Old beta scopes (api, sfap_api, einstein_gpt_api) will not work with the GA service.
  4. Verify URL — Is the URL correct for your org type? Production and sandbox orgs use different URL patterns. See Connecting Your MCP Client for the full reference.
  5. Check ECA propagation — New or recently modified External Client Apps may take up to 30 minutes to become operational.
  6. Check permissions — Does your user have access to the objects and fields the tool is querying? The agent inherits your FLS, CRUD, and sharing permissions.

Reading the Response

Successful tool calls return structured JSON with the requested data. Error responses include error codes and messages:

  • 401 — Authentication failure. Token expired, invalid, or wrong scopes.
  • 403 — Permission denied. Your user doesn't have access to the requested resource.
  • 404 — Server not found. Wrong URL, or the server isn't activated in Setup.

Postman's MCP and AI Features

Postman offers AI-powered developer tools that allow you to connect an LLM to MCP server responses for agentic workflow testing. These AI features are separate capabilities within Postman and are not part of the Salesforce MCP server itself.

The MCP server is completely deterministic — when you call a tool directly in Postman, you're making structured API calls to Salesforce and receiving structured responses. No language model processes your requests or responses on the Salesforce side.

Official Troubleshooting

For formal resolution paths beyond what's covered here, see the official troubleshooting documentation.

Clone this wiki locally