Built-in Tools

Testing Tools in the Playground

Configuring a tool is only half the job. Before pointing Claude Desktop, Claude Code, or Cursor at your MCP server, verify it works. Vectoralix ships two layers of testing: a per-tool Test modal on each Configure page, and a top-level Playground that connects to any MCP server over the real protocol.

Closing the feedback loop

Without an in-dashboard testing path, the only way to verify a tool is to wire it into an external AI client and watch what happens. The Playground closes that loop. You configure a tool, run it through the per-tool Test modal, then exercise it end-to-end through the Playground over the real MCP protocol — all before any external client sees the URL.

Two layers of testing

Per-tool Test modal

Each tool's Configure page exposes a Test header action — Test Code on Code Execute tools, Test API on API URL tools. The action opens a persistent three-zone modal that calls the same Action the live MCP endpoint would. The modal does not close between Run cycles — edit inputs, press mod+enter, watch zones update, repeat.

  • Zone 1 — Inputs. The parameter form, auto-generated from the tool's parameter or request-mapping rows. Always visible, always editable.
  • Zone 2 — Execution context (Code) or Composed request (API). Appears after the first Run; shows the casted parameter values, or the raw HTTP/1.1 request that would go on the wire (with sensitive headers masked).
  • Zone 3 — Result pipeline. Sandbox output for Code Execute; HTTP status, raw body, mapped fields, and post-processing output for API URL. When a stage fails, an error stage badge (ssrf, http, or post_processing) shows exactly where the pipeline broke.

Test actions are only available once the tool has the minimum required scalar: a non-empty code_body for Code Execute, a non-empty url_template for API URL. Until then the Test button is hidden.

Full Playground page

The Playground is a top-level navigation item in the Vectoralix panel that acts as a generic MCP client. It speaks the real MCP protocol over Streamable HTTP to any server you give it — including servers you do not own.

  • Connection setup — paste an MCP URL and an optional Bearer token. One-click quick-connect on the MCP server detail page pre-fills both for your own servers.
  • Initialize handshake — runs on connect; the left panel populates with the server's tools, resources, and prompts as the server reports them.
  • Invoke any capability — pick a tool, a resource, or a prompt; fill in parameters via an auto-generated form (or a raw JSON toggle when the schema cannot be rendered as a form); click Execute / Read / Get; see the result.
  • JSON-RPC log — every exchange is logged at the bottom of the page in raw JSON-RPC. Entries are expandable and copyable, so you can paste them into a support ticket or diff them against what an external client sees.

Parameter input forms

Both the per-tool Test modal and the Playground build their parameter forms automatically from the tool's JSON Schema. Strings render as text inputs, numbers as numeric inputs, dates as date pickers, booleans as toggles, arrays and objects as JSON textareas. When the schema is too exotic to render as a form, a raw JSON toggle falls back to hand-edited input.

Quick-connect from your server detail page

On the MCP server edit page, the Test in Playground button is the fastest way to enter the Playground for a server you already own. It navigates to the Playground with the server's endpoint URL and credentials pre-filled, ready to connect.

Endpoint shape

Servers exposed by Vectoralix accept the same protocol whether you call them from the Playground or from a real AI client. The endpoint is:

POST https://vectoralix.com/mcp/<serverUid>

Verification pattern

  1. Configure the tool on its Configure page.
  2. Run the per-tool Test modal until inputs and outputs look right.
  3. Open the Playground; quick-connect to the server the tool is attached to.
  4. Invoke the same tool through the real MCP handshake; verify the result matches what the modal showed.
  5. If both match, the URL is safe to hand to an external AI client.

State and observability boundaries

  • Playground sessions are ephemeral — connection state and history live in Livewire only.
  • Test calls are not written to the server's request_logs; those track real inbound traffic from external clients, not outbound test calls from the dashboard.
  • A second click on Run while a test is in flight is a no-op — the page-wide concurrency guard prevents stacked executions.

Safety and limits

  • Per-tool Test actions use the same SSRF validator, sandbox, and 1 MB response cap as live tool calls.
  • The Playground's outbound MCP client is itself SSRF-guarded, HTTPS-only in production, with a 10-second timeout and per-user/org rate limiting.
  • OAuth credentials in URLs are redacted in the modal's Zone 1 live URL preview and Zone 2 composed request — first 10 characters kept, then asterisks.
  • A 128 KB display cap is applied to test output before it is stored in Livewire state, keeping round-trip payloads small. The cap applies only to what is rendered in the dashboard, not to what the live MCP call returns.

External traffic still goes to the request log: The Playground is the right place to verify before exposure. Once a real client invokes your server, every request lands in the per-server request log — that is the next layer of verification, and it is documented under Observability.