A² Playground — Collections and A²D Assets

The A² Playground lets you test MCP, A2A, and REST endpoints in the A²D platform and in the standalone A² Playground client (hosted at a2playground.a2d-ai.com and as a desktop build). Two companion features let you organize reusable REST requests and drill into your organisation’s assets: REST Collections (My Library and Local Workspace) and the 3-level A²D Assets tree.

This page covers both. It applies to the A² Playground only — the REST APIs → Playground tab inside a REST API asset is unchanged.

Overview

A Collection is a grouping node that stores a reusable baseUrl, shared request headers, and shared authentication. Inside a collection you add individual endpoints: { method, path, queryParams, body, name }. Headers and auth live at the collection level and are applied to every endpoint when you send a request.

The A²D Assets sidebar is now three levels deep:

Level 1: protocol group (A2A Requests, MCP Requests, REST Requests).
Level 2: the asset itself (Agent Card, MCP Server, REST API).
Level 3: each environment defined on the asset’s Environments tab, with the asset’s mocking scenarios listed under that environment.

REST Collections

What a collection stores

name
baseUrl — e.g. https://api.example.com/v1
headers — shared request headers
auth — shared auth config (none, bearer, basic, client_credentials, or custom)
endpoints[] — each endpoint has method, path (relative to baseUrl), queryParams, optional body, and a name

Query parameters are stored structurally on each endpoint — not embedded in the URL — so they survive save/reload and can be edited in the Params tab without re-parsing a URL string.

Where collections live

Collections live inside My Library (web) and Local Workspace (desktop). They sit beside folders; a collection is not a folder, so the existing 3-level folder nesting is unchanged. Endpoints appear as children of the collection.

Creating a collection — My Library (web)

Use My Library on the hosted playground (a2playground.a2d-ai.com) and inside the main platform’s /tester view. Collections and endpoints are scoped to your organisation and shared with all members.

Open the sidebar and find the Collections section under My Library.
Create a collection, set baseUrl, add shared headers and auth.
Add endpoints by selecting method, entering a path (relative to baseUrl), and optional query parameters and body.
Click an endpoint to open it in the tester.

Creating a collection — Local Workspace (desktop only)

The desktop build stores your library as plain JSON on disk so you can version-control and share your workspace.

On-disk layout:

<workspace-root>/
  myFolder/
    petstore.collection.json
    petstore/
      list-pets.rest.json
      create-pet.rest.json

<slug>.collection.json — the collection sidecar (id, name, baseUrl, headers, auth).
<slug>/ — sibling directory that contains the endpoint request files.
Each *.rest.json carries the endpoint’s method, path, queryParams, and body.

The file watcher picks up external edits (e.g. git pull) and refreshes the sidebar.

Legacy saved requests

Saved requests you created before collections existed keep working. They render under their existing folder, keep any query string in the URL field, and don’t require migration.

A²D Assets — 3-level hierarchy

What’s at each level

Level 1 — protocol group. A2A Requests, MCP Requests, REST Requests.
Level 2 — asset. One leaf per Agent Card, MCP Server, or REST API in your current organisation.
Level 3 — environment. Each environment defined on the asset’s Environments tab is surfaced here (for example Mocking Service, Pre-Prod, Prod). Under each environment you see the asset’s mocking scenarios.

Level 3 reads live from the asset. Adding a new environment on the asset’s Environments tab — or adding a mocking scenario — shows up in the sidebar the next time it loads.

Scenarios are click-to-prefill

A scenario leaf in the sidebar pre-fills the tester with the scenario’s matching request so you can execute it against the selected environment’s baseUrl. The scenario’s expected response is shown alongside the live execution result.

Editing a scenario happens in the asset’s own Mock Scenarios tab — the sidebar is read-only for scenarios by design, to keep one source of truth.

Saving a scenario or request as your own

Clicking Save to My Library from an A²D Assets node clones the request into My Library under an auto-created A²D Assets / <asset> / <environment> collection, linked to the asset and environment that produced it. Once saved it becomes a normal collection endpoint — you can edit headers, auth, body, and query params locally without touching the asset.

Safe points to remember

The REST APIs → REST API detail → Playground tab inside the main platform is unchanged. Collections only apply to the A² Playground (standalone + /tester).
No asset data is modified by anything described here. Collections and saved endpoints live in the playground library (or your Local Workspace JSON files) — never in rest_apis, rest_endpoints, mcp_servers, agent_cards, a2tf_asset_environments, or any mocking-scenario table.
Legacy saved requests continue to work. The collection_id column on saved requests is optional; a request is either a legacy standalone request (folder only) or a collection endpoint (collection only) — never both.

Next Steps

Organise your requests once, reuse them everywhere — and drill straight from an asset’s environments into the scenarios that back them.

Protocol Tester Testing MCP Endpoints