AnalyticsProof

Create a journey from steps

create_journey

Create a journey from steps (permission: edit)

Create a saved journey on a website test from steps you write, without the recorder. The target decides the project, so an organization key sends no projectId. The journey starts on the test's URL (there is no url field); to start elsewhere, make a navigate the first step. Steps are validated strictly: unknown fields are refused and every problem is reported at once in error.details[] as { path, message, code } (e.g. steps[3].selector); nothing is saved then. Typed values are never echoed. No consent action is added: record the banner click as a step when the journey needs it. The answer is the journey document (as GET /journeys/{id} returns it, with its ETag and Location) plus scan: the baseline replay, which starts right away (poll scan.pollUrl); scan is null with scanError when it could not be queued. A click inside an iframe names the iframes in iframeChain (CSS, outermost first); typing inside iframes is not supported yet. The Idempotency-Key also derives the journey id, so a retry after a lost slot answers the original journey. idempotencyKey (sent as the Idempotency-Key header): retrying the same call with the same value replays the original answer; the same value with different arguments is 422 idempotency_conflict, and 409 idempotent_in_progress means wait error.meta.retryAfter seconds and retry.

To change an existing journey use replace_journey (every step, a new baseline) or patch_journey (name or status only).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "targetId": "<targetId>",
      "name": "<name>",
      "steps": "<steps>"
    },
    "name": "create_journey"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	The journey name.
`steps`	Yes	Replayed in order from the test's URL (`steps[i]` is stored as step i); to start elsewhere, make a `navigate` the first step.
`targetId`	Yes	A website test of a project the key reaches; it decides the project (no `projectId`).
`viewport`	No	Browser viewport of the replay; default desktop.
`idempotencyKey`	No	Optional Idempotency-Key: reuse the same value when retrying this exact call so it is applied once.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 5, 2026
- addedInput schema / properties / name / description
```
Added value: +"The journey name."
```
- addedInput schema / properties / viewport / description
```
Added value: +"Browser viewport of the replay; default desktop."
```
First observedNov 4, 2026

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Substantially beyond the annotations: it discloses the required edit permission, strict validation that reports every error at once via error.details[] with path/message/code and saves nothing, that typed values are never echoed, that no consent action is auto-added, and that a baseline scan starts immediately with scan/scanError outcomes. It also documents retry semantics (422 idempotency_conflict, 409 idempotent_in_progress with retryAfter). Not a contradiction with idempotentHint=false — the tool is non-idempotent by default and idempotency is opt-in via the key — but it stops short of stating rate limits, step-cap consequences, or whether an unsuccessful scan invalidates the created journey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first sentence and the alternative-routing sentence is correctly placed last. It is dense but nearly every clause carries operational content; minor redundancy exists where it restates schema facts such as typed values never being echoed and idempotencyKey being sent as the Idempotency-Key header.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description compensates fully: the response is the journey document as GET /journeys/{id} returns it, with ETag and Location, plus a `scan` baseline result that should be polled via scan.pollUrl, or null with scanError. Combined with the iframeChain limitation (clicks yes, typing no) and the idempotency retry rules, an agent has what it needs to call and follow up.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already carries per-field meaning; the description adds only cross-parameter knowledge — targetId determines the project so no projectId is sent, and there is deliberately no top-level url field. That generative detail (how to start off-URL) is genuinely beyond the schema, though most individual field semantics are left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening states a specific verb and resource ("Create a journey from steps") and immediately narrows the scope: a saved journey on a website test built from steps you write, without the recorder. It closes by naming the sibling mutation tools (replace_journey, patch_journey), so an agent can place it in the CRUD family without opening another schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The final line routes the agent explicitly: use replace_journey for a full step rewrite plus new baseline, patch_journey for name or status only. It also gives conditional guidance inside the call itself — the journey starts on the test URL, so make a `navigate` the first step to start elsewhere — which is exactly the decision an agent would otherwise get wrong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All AnalyticsProof tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?