> ## Documentation Index
> Fetch the complete documentation index at: https://tyk-joancamostyk-patch-19.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Test MCP Tools with the Embedded MCP Inspector

> How to use the embedded MCP Inspector to test an MCP product's tools directly from the Developer Portal, before writing agent code.

## Availability

| Component        | Version | Editions   |
| :--------------- | :------ | :--------- |
| Developer Portal | v1.19.0 | Enterprise |

## Overview

The embedded MCP Inspector lets you test an MCP product's tools directly from the Live Portal, so you can validate a connection and see what a tool returns before writing any agent code.

## Open the Inspector

The Inspector is available for MCP-typed products only, and appears in two places. On the Product's detail page, the **Service explorer** tab embeds it inline under a **Try it** toggle (**Instructions** shows the operator-authored markdown instead). Selecting **Try it out** on an individual service opens that service's own documentation page, which shows the same **Try it** / **Instructions** toggle.

Once the Inspector loads:

1. It lists the tools the MCP server exposes.
2. Select a tool to see its input parameters.
3. Fill in the parameters and call the tool. The response appears in the same view.

## How the Inspector Connects

The Inspector does not talk to your MCP server directly. It talks to a proxy hosted by the Portal itself, which forwards the connection to the MCP server URL configured on the product. You cannot point the Inspector at a different server; the Portal always decides the upstream.

## Providing Credentials

Unlike the GraphQL Playground, the Inspector does not automatically populate your credentials. Enter your issued credential into the Inspector's connection form yourself. The Portal's proxy forwards it to the MCP server without reading or modifying it. See [Access protected MCP proxies with OAuth 2.1](/portal/mcp-oauth-access) for how the Portal surfaces credentials and token information for a PRM-protected MCP proxy.

## Configuring the /fetch Endpoint's SSRF Guard

The Inspector uses a generic HTTP fetcher, `/fetch`, for OAuth and PRM metadata discovery (for example, resolving an authorization server's metadata document). This is separate from the MCP JSON-RPC proxying [described above](#how-the-inspector-connects) and does not affect tool calls.

| Setting                     | Environment variable                     | Default | Description                                                                                                                                                                                                                                                                    |
| :-------------------------- | :--------------------------------------- | :------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Block private fetch targets | `PORTAL_MCP_INSPECTOR_BLOCKPRIVATEFETCH` | `true`  | When `true`, `/fetch` rejects targets that resolve to loopback, RFC 1918/RFC 4193 private ranges, link-local addresses (including cloud metadata endpoints), CGNAT (`100.64.0.0/10`), or multicast/unspecified addresses. Redirect hops are re-checked against the same rules. |
| Public base URL             | `PORTAL_MCP_INSPECTOR_PUBLICBASEURL`     | Empty   | A trusted absolute origin (`scheme://host`) used for the Inspector's proxy address and DNS-rebind checks instead of the request's `Host`/`X-Forwarded-Proto` headers. Leave empty for a single-host deployment; the Portal falls back to the request's own origin.             |

`PORTAL_MCP_INSPECTOR_BLOCKPRIVATEFETCH` defaults to `true` for security (to prevent SSRF). For local development against a Gateway or authorization server on `localhost` or a private network address, it needs to be set to `false`. The Portal logs a startup warning while it is off.

Turning it on only affects `/fetch` (OAuth/PRM metadata discovery), not the Inspector's ability to call MCP tools. If your authorization server or its metadata endpoint is only reachable at a private or internal address, enabling this setting blocks the Inspector from reaching it.

## Vendored Inspector Version

The Portal ships v1.0.1 of the [MCP Inspector](https://github.com/modelcontextprotocol/inspector), which supports the [2025-11-25 MCP specification](https://modelcontextprotocol.io/specification/2025-11-25). The Inspector's v2 line supports the newer [2026-07-28 specification](https://modelcontextprotocol.io/specification/2026-07-28); Tyk does not yet support v2, so tools and features that depend on the 2026-07-28 specification are not available in the embedded Inspector.

## Troubleshooting

<AccordionGroup>
  <Accordion title="The Inspector still connects to an old MCP server URL after an operator changes it">
    The proxy caches the upstream address per API. If an operator updates the product's MCP server URL, the change may not take effect until the Portal is restarted.
  </Accordion>

  <Accordion title="The Inspector shows a connection error immediately">
    Check whether the issue is the Portal's proxy or the upstream MCP server itself - the Inspector's banner indicates which side is unreachable.
  </Accordion>

  <Accordion title="OAuth/PRM discovery fails with &#x22;Target address is not allowed&#x22;">
    `PORTAL_MCP_INSPECTOR_BLOCKPRIVATEFETCH` is enabled, and the authorization server or metadata endpoint the Inspector tried to reach resolves to a private, loopback, link-local, or cloud-metadata address. See [Configuring the /fetch endpoint's SSRF guard](#configuring-the-fetch-endpoints-ssrf-guard).
  </Accordion>
</AccordionGroup>