> ## Documentation Index > Fetch the complete documentation index at: https://tyk.io/docs/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 connect to your MCP server directly. The Portal sits in between and connects to the MCP server URL configured on the product. You cannot point the Inspector at a different server. The Portal only allows a connection to the server of the product whose page you opened. ## Saved Settings and the Seeded Server In v1.20.0, the Inspector opens with the product's MCP server already added and named after the API. If the Portal cannot find the server URL, the list is empty and you can add a server yourself. The Portal saves each developer's server list and OAuth credentials, so they survive a Portal restart. They belong to one developer, on one product and API, for one login session. Signing in again starts fresh. ## 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](https://tyk.io/docs/portal/mcp-oauth-access.md) 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. Both Inspector versions use these settings. | 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. ## Inspector Versions The Portal includes two versions of the [MCP Inspector](https://github.com/modelcontextprotocol/inspector) and shows one of them on MCP product pages. | Version | MCP specification | When it is used | | :- | :- | :- | | V1 (1.0.1) | [2025-11-25](https://modelcontextprotocol.io/specification/2025-11-25) | Default | | V2 | [2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28), or 2025-11-25 for a server that does not support it | When an operator turns on the V2 setting | ### Choosing the Inspector Version Both versions are always available. The `PORTAL_MCP_INSPECTOR_USEV2` setting only decides which one the product page shows. It is `false` by default, so the page shows V1 until an operator turns it on. Setting it back to `false` returns the page to V1. ### Protocol Negotiation MCP inspector V2 connects with the handshake set in `PORTAL_MCP_INSPECTOR_PROTOCOLERA`. The default, `auto`, tries 2026-07-28 first and falls back to the 2025-11-25 handshake if the server does not support it. Developers cannot change this in the Inspector. The following settings control the Inspector versions. | Setting | Environment variable | Default | Description | | :- | :- | :- | :- | | Use Inspector V2 | `PORTAL_MCP_INSPECTOR_USEV2` | `false` | When `true`, MCP product pages show Inspector V2 instead of V1. | | Protocol era | `PORTAL_MCP_INSPECTOR_PROTOCOLERA` | `auto` | The handshake V2 uses with the product's MCP server: `auto`, `legacy` or `modern`. An unrecognized value is treated as `auto`. `legacy` uses 2025-11-25 and never tries 2026-07-28. | ## Troubleshooting > [accordion] The V1 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] The Inspector page shows "no MCP server for this API" > > Either the product has no MCP server, or you do not have access to the product. The Portal answers with the same message in both cases, so it does not reveal that a product exists. > [accordion] 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] OAuth/PRM discovery fails with "Target address is not allowed" > > `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).