What can you do with this server?

This server acts as an unofficial Model Context Protocol (MCP) interface for the VWO (Visual Website Optimizer) REST API v2, enabling AI agents to manage A/B testing, split URL testing, and web rollout campaigns through a set of 45 tools and four workflow prompts. Core capabilities: * Diagnostics: Verify connection and API token validity. * Workspaces: List, create, update, and view account/sub-account activity timelines. * Campaigns: Full lifecycle management—list, get, create, update, and change status (start, pause, stop, archive, soft-delete) for all campaign types (A/B, split, multivariate, feature-rollout). Draft campaigns have separate list, get, update, and delete tools. * Goals, Variations, Sections: CRUD operations on campaign goals, variations (use raw changes string for variation content), and multivariate sections. * Metric Reports: List and get VWO Insights metric reports. * Labels: List workspace labels, view/add/remove labels on campaigns. * Tracking Code: Retrieve the SmartCode JavaScript snippet for a workspace. * Custom Widgets: Full CRUD plus bulk create and update (bulk update endpoint inferred). All mutating tools are flagged with ⚠️ and require explicit human approval. A rate limit of 1 request/second per token is enforced. Account selection supports explicit account ID, workspace name (resolved via list), or a default from VWO_ACCOUNT_ID; if unspecified, the server prompts to list workspaces. Workflow prompts: Four prompts provide structured guidance—vwo_general_guidance (house rules, approvals, rate limits), vwo_ab_test_workflow, vwo_split_test_workflow, and vwo_web_rollout_workflow. These prompts can fetch campaign data to embed real-world context for the AI agent. Configuration & Safety: The server is configured via environment variables (VWO_API_TOKEN, VWO_API_TOKEN_FILE, VWO_ACCOUNT_ID, etc.) and supports secure token handling across different hosts (Claude Code, VS Code, Codex CLI). It implements retry logic distinguishing idempotent and non-idempotent operations.

How do I use unofficial-vwo-mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@unofficial-vwo-mcp-server list my active campaigns" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

unofficial-vwo-mcp-server

by nextafter-michael

Overview Schema Related Servers Score Discussions

TypeScript

Remote

This server acts as an unofficial Model Context Protocol (MCP) interface for the VWO (Visual Website Optimizer) REST API v2, enabling AI agents to manage A/B testing, split URL testing, and web rollout campaigns through a set of 45 tools and four workflow prompts.

Core capabilities:

Diagnostics: Verify connection and API token validity.
Workspaces: List, create, update, and view account/sub-account activity timelines.
Campaigns: Full lifecycle management—list, get, create, update, and change status (start, pause, stop, archive, soft-delete) for all campaign types (A/B, split, multivariate, feature-rollout). Draft campaigns have separate list, get, update, and delete tools.
Goals, Variations, Sections: CRUD operations on campaign goals, variations (use raw changes string for variation content), and multivariate sections.
Metric Reports: List and get VWO Insights metric reports.
Labels: List workspace labels, view/add/remove labels on campaigns.
Tracking Code: Retrieve the SmartCode JavaScript snippet for a workspace.
Custom Widgets: Full CRUD plus bulk create and update (bulk update endpoint inferred).

All mutating tools are flagged with ⚠️ and require explicit human approval. A rate limit of 1 request/second per token is enforced. Account selection supports explicit account ID, workspace name (resolved via list), or a default from VWO_ACCOUNT_ID; if unspecified, the server prompts to list workspaces.

Workflow prompts: Four prompts provide structured guidance—vwo_general_guidance (house rules, approvals, rate limits), vwo_ab_test_workflow, vwo_split_test_workflow, and vwo_web_rollout_workflow. These prompts can fetch campaign data to embed real-world context for the AI agent.

Configuration & Safety: The server is configured via environment variables (VWO_API_TOKEN, VWO_API_TOKEN_FILE, VWO_ACCOUNT_ID, etc.) and supports secure token handling across different hosts (Claude Code, VS Code, Codex CLI). It implements retry logic distinguishing idempotent and non-idempotent operations.

unofficial-vwo-mcp-server

An unofficial MCP server that exposes VWO platform operations as tools an AI agent can call. Built on the MCP TypeScript SDK v2 (@modelcontextprotocol/server), stdio transport.

Not affiliated with or endorsed by VWO / Wingify.

New to this repo? See GETTING-STARTED.md for a step-by-step walkthrough (clone, build, get a token, register with a host). This file is the deeper reference — why things work the way they do.

Tools

45 tools. Reads are unmarked; ⚠ marks a tool that mutates VWO state and carries REQUIRES_HUMAN_APPROVAL, so hosts prompt a person on every call.

Area	Tools
Diagnostics	`vwo_verify_connection`
Workspaces	`vwo_list_workspaces`, `vwo_get_workspace`, `vwo_get_workspace_history`, ⚠ `vwo_new_workspace`, `vwo_update_workspace`
Campaigns	`vwo_list_campaigns`, `vwo_get_campaign`, `vwo_get_campaign_share_link`, ⚠ `vwo_new_campaign`, `vwo_update_campaign`, `vwo_update_campaign_status`
Drafts	`vwo_list_drafts`, `vwo_get_draft`, ⚠ `vwo_update_draft_campaigns`, `vwo_delete_draft_campaigns`
Goals	`vwo_list_campaign_goals`, `vwo_get_campaign_goal`, ⚠ `vwo_new_campaign_goal`, `vwo_update_campaign_goal`, `vwo_delete_campaign_goal`
Variations	`vwo_list_campaign_variations`, `vwo_get_campaign_variation`, ⚠ `vwo_new_campaign_variation`, `vwo_update_campaign_variation`, `vwo_delete_campaign_variation`
Sections	`vwo_list_campaign_sections`, `vwo_get_campaign_section`, ⚠ `vwo_new_campaign_section`, `vwo_update_campaign_section`, `vwo_delete_campaign_section`
Metric reports	`vwo_list_metric_reports`, `vwo_get_metric_report`
Labels	`vwo_list_labels`, `vwo_list_campaign_labels`, ⚠ `vwo_add_campaign_label`, `vwo_delete_campaign_label`
Tracking code	`vwo_get_smartcode`
Custom widgets	`vwo_list_custom_widgets`, `vwo_get_custom_widget`, ⚠ `vwo_new_custom_widget`, `vwo_update_custom_widget`, `vwo_delete_custom_widget`, `vwo_create_custom_widgets`, `vwo_update_custom_widgets`

Every tool name carries a vwo_ prefix. Claude Code additionally namespaces by server (mcp__vwo__vwo_list_campaigns), but the local prefix is what survives in hosts that don't namespace, and in any text — tool descriptions, error messages — that only ever shows the bare name.

Uses VWO REST API v2 exclusively. v1 is retired and the base URL is validated to end in /v2 at startup — see API version safety.

Where the docs and the live API disagree

Every route was verified against the live API (a 401 proves the route exists; a 404 proves it does not). Three cases where following the reference literally would have produced broken or wrong tools:

Operation	Reference says	Actual
Update/delete a campaign goal	`/accounts/{a}/campaign/{c}/goals/{g}` — singular `campaign`	Singular 404s. Plural `/campaigns/` is used.
Custom widgets	—	Served from `/changesets`, not any form of `/widgets`.
Update bulk custom widgets	`POST /accounts/{a}/attribute-list/{id}`	Unrelated endpoint. See caveat below.

vwo_update_custom_widgets is the one unverified endpoint. Its doc page points at an attribute-list endpoint that has nothing to do with widgets, and the nav lists the operation as GET. This server uses PATCH /accounts/{a}/changesets/bulk, which exists and is consistent with the single-widget PATCH and the bulk POST. The tool's own description tells the agent the endpoint is inferred. Confirm the first real call.

Collection response shapes are not consistent

VWO returns list collections in two different shapes, on the same endpoint depending on parameters. Verified against the live API:

Endpoint	`_data` shape
`GET /campaigns` (no `status`)	`{ partialCollection: [...], totalCount, offset }`
`GET /campaigns?status=…`	flat array
`GET /insights-metrics`	`{ partialCollection, totalCount, offset }` — and `partialCollection` is not an array when empty
`/drafts`, `/feeds`, `/goals`, `/variations`, `/accounts`	flat array
`/labels`, `/changesets`	`_data` omitted entirely when empty

_metadata is never present on any of them, despite the docs implying it; the real total lives at _data.totalCount, and only on the wrapped shape.

This bit hard: an earlier listResult handled only the flat-array case and silently returned [] for the wrapped one, so a workspace holding 142 campaigns reported count: 0. extractCollection in src/tools/shared.ts now normalizes every shape above, and — because the failure was silent, which is what made it dangerous — an unrecognized shape now surfaces a warning in the tool result telling the agent to report a bug rather than conclude there is no data.

Two more undocumented `/campaigns` behaviors

status is a real query parameter that VWO does not document. UPPERCASE only (lowercase returns HTTP 400). Valid values, taken from the error message VWO returns for an invalid one: ACTIVE, DELETED, ARCHIVED, RUNNING, PAUSED, STOPPED, NOT_STARTED. Omitting it returns campaigns of every status — including soft-deleted ones, so check each result's own isDeleted and status fields before reporting a campaign as live. Note status=ARCHIVED returns campaigns whose own status field reads STOPPED: archived-ness is a separate axis from the status value.

limit is capped at 25 on this endpoint, silently — limit=50 and limit=100 both return 25 (while /feeds honors limit=100, so the cap is per-endpoint). The tool's schema caps limit at 25 to match, because allowing a larger value broke paging: nextOffset is derived partly from whether a page came back full, and a 25-item response to a limit=100 request looks like a final page. Verified after the fix that paging walks all 142 campaigns across 6 pages and terminates correctly.

Two more shapes worth knowing: vwo_update_campaign_status is a bulk endpoint with no campaign id in the path (ids go in the body), and vwo_update_campaign requires its payload wrapped in a campaigns object — the tool adds that wrapper itself, since models reliably get nesting like that wrong.

Campaign type/platform values are lowercase and hyphenated, not the generic A/B-testing names they resemble. An early version of this server's tool descriptions said "AB", "SPLIT_URL", "MVT", "FUNNEL", "WEB", "FULLSTACK" — all wrong. VWO's own type filter enum on GET /campaigns is ab, multivariate (not mvt), split (not split-url), feature-rollout, feature-test, plus non-testing types (heatmap, survey, recording, …); platform is website, full-stack, or mobile-app. Fixed in src/tools/campaigns.ts and reflected in the workflow prompts below, which is also how feature-rollout was confirmed as the real type value behind "Web Rollouts."

Campaign-resource writes need a plural wrapper

VWO wraps every campaign-resource write body in the plural resource name. An unwrapped body is rejected with HTTP 400 "Request is not in desired format." — a real failure hit while creating a variation, not a theoretical one:

Operation	Required body
`vwo_update_campaign`	`{"campaigns": {…}}`
`vwo_new_campaign_goal` / `vwo_update_campaign_goal`	`{"goals": {…}}`
`vwo_new_campaign_variation` / `vwo_update_campaign_variation`	`{"variations": {…}}`
`vwo_new_campaign_section` / `vwo_update_campaign_section`	`{"sections": {…}}`

All of these tools add the wrapper for you — pass the fields flat. An already-wrapped body is passed through untouched, so both forms work. The wrapper key is spec.segment in campaignResource.ts, so goals/variations/sections get it from one place; vwo_update_campaign has its own.

Variation changes: write `changes`, read `editorData`

The asymmetry here is a genuine trap. Reading a variation returns editorData — VWO's internal op stack ({stack: [{op: {opName: …}}]}). Writing that same structure back is rejected. The write format is a raw changes string, which VWO then compiles into editorData itself:

// write this
{ "name": "Variation 1", "changes": "<script>/* JS that mutates the page */</script>" }

Both vwo_new_campaign_variation and vwo_update_campaign_variation say so in their body descriptions, and vwo_general_guidance repeats it, because the natural move — read the variation, edit the structure you got, write it back — is exactly the thing that fails.

A newly created campaign is not a valid test yet

vwo_new_campaign returns status: NOT_STARTED (a draft that serves no traffic), but it also leaves the campaign in a state that isn't a working A/B test, and nothing in VWO's docs warns about it:

VWO creates only a Control — every other variation must be added explicitly.
That Control comes back isDisabled: true, percentSplit: 0, and adding a variation does not change it. Left alone, the test has no baseline.
The create response can report stale variation values, so read the campaign back rather than trusting it.

The three workflow prompts share a POST_CREATE_VERIFY_SECTION that walks through fixing this.

Deleting a campaign

There is no DELETE /campaigns/{id} endpoint — checked the whole spec; campaigns are the one major resource without one. Removal is a status change to DELETED (or ARCHIVED) via vwo_update_campaign_status, which soft-deletes: the campaign still appears in vwo_list_campaigns with isDeleted: true and via status=DELETED. So creating a campaign is reversible, but deletion is treated as destructive and gated on an explicit user request. (The prompts previously claimed creation could not be undone; that was wrong and is corrected.)

Request bodies

VWO documents a request schema for only three write endpoints (vwo_new_workspace, vwo_update_workspace, vwo_new_campaign). Those get explicit typed fields — including vwo_new_campaign's urls and goals, which are now typed from shapes confirmed by a real successful creation rather than left as opaque arrays.

Every other write tool takes a validated body object passed through to VWO — rather than a strict schema invented here that would reject valid payloads. To keep that from meaning "go read the docs first", each body description carries the endpoint's doc URL plus a concrete verified example, and vwo_general_guidance collects the common ones. The goal is that an agent never needs to fetch VWO's reference for a routine write.

Account listing must pass `includeCurrent`

GET /accounts omits the token's own main workspace unless includeCurrent=true is passed. This caused a real bug: vwo_list_workspaces passed it and saw 43 workspaces, while the account directory backing workspaceName resolution did not and saw 41 — so workspaceName could never resolve the token's own workspace, which is the one a user is most likely to name. It failed with "no match" plus a candidate list that conspicuously omitted it. Two different counts from the same account is the tell. Fixed in accounts.ts.

Related MCP server: VoIPbin MCP Server

Prompts

Tools are actions an agent takes; prompts are a separate MCP primitive for guidance — text that steers how the model approaches a situation, with no tool call attached. This server exposes four:

Prompt	Purpose
`vwo_general_guidance`	House rules that apply everywhere: resolving workspaces, what needs approval, rate limits, which workflow prompt to use, and to check VWO's own docs for platform-behavior questions. No arguments.
`vwo_ab_test_workflow`	Inspect → plan → apply → verify → iterate for a same-page A/B test (type `ab`/`multivariate`).
`vwo_split_test_workflow`	The same shape, for a Split URL test (type `split`) — each variation is a distinct destination URL, not a code change. Simpler: no `editorData` to inspect.
`vwo_web_rollout_workflow`	The same shape, for a Web Rollout (type `feature-rollout`) — mechanically identical to the A/B workflow, but with no control variation and no analytical goal.

All three workflow prompts do real work before returning: when given a campaignId, each fetches that campaign and its variations server-side — including, for the A/B and rollout workflows, each variation's editorData (VWO's undocumented field for the actual DOM/JS/CSS a variation applies) — and embeds that snapshot directly in the returned guidance, so the model starts from real data instead of spending a turn discovering it. If the fetch fails for any reason (bad token, wrong id, ambiguous workspace), the prompt still returns successfully — it degrades to telling the model to fetch that information itself.

The workflow each prescribes, in short: for an existing campaign, understand what's there in your own words before touching anything (either its code, for A/B/rollout, or which URL each variation points to, for split); for a brand-new one, run a full requirements checklist first (below) since this server has no delete_campaign tool — once vwo_new_campaign succeeds there's no undoing it through this API. Either way: plan the specific change and say so before calling a write tool; apply one focused change; then verify it visually — see Verifying a change in a browser below — before considering it done; iterate using user feedback, with a cap so it doesn't loop blindly forever. Shared machinery (snapshot fetch, verify/iterate text, wrap-up) lives in src/prompts/shared.ts; read src/prompts/abTestWorkflow.ts and its two siblings for the exact text.

New-campaign checklists. Nothing gets inferred silently except items with a stated default. Shared by all three: workspace, page targeting (urls/excludedUrls — explicitly confirmed, never silently assumed to be "just this one page"); audience defaults to All Visitors with no segment filtering unless stated otherwise, stated explicitly in the plan so it's easy to override. Then per campaign type:

A/B test: campaign type asked if ambiguous between ab/split/multivariate (real VWO values — see type value corrections below); at least one goal required; traffic split defaults even across variations; variation count and what each one does are extracted from the request if implied, or asked per-variation if vague.
Split test: type is fixed at split (stated, not asked, since invoking this prompt already answers that); each variation needs its own explicit destination URL — never invented; still requires goals, same as an A/B test (a split test is still a controlled experiment). One genuinely open question flagged in the prompt itself: VWO's API doesn't document which field carries a variation's destination URL — the model is told to inspect what VWO actually returns rather than guess a field name, and to check VWO's support docs if that isn't enough.
Web rollout: type is fixed at feature-rollout; no goal is asked for — the prompt has the model try goals: [] first (VWO's schema shows no minimum length, though that's not a server-side guarantee) and falls back to a placeholder goal only if VWO rejects the empty array, explaining to the user why it exists; no control variation, just one, at a rollout percentage that defaults to 100% unless the user wants a staged rollout.

Prompts: what they are and their limits

Prompts are offered by the server, but nothing in MCP requires a host to do anything with them. tools/call is universal because it's the entire point of a tool-using agent; prompts/list and prompts/get are separate calls a host has to choose to make. Claude Code wires prompts up as slash commands (/mcp__vwo__vwo_ab_test_workflow, and likewise for the split-test and rollout ones), so a person can invoke one directly. Whether the model itself ever decides to call prompts/get depends entirely on your own wrapper's logic — nothing about registering a prompt makes an agent aware it exists unless the host lists prompts for it or a human invokes one.

That's why the server-level instructions field (sent once, automatically, at connect time — see src/index.ts) explicitly names all four prompts: it's the one guaranteed way to make the model aware they exist without your wrapper doing anything extra. If your wrapper's agent loop calls prompts/list itself and decides when to invoke one based on the user's request, that's the more autonomous version of this — but it's work your wrapper has to do; this server can't reach into your agent loop and invoke its own prompt on the model's behalf.

Verifying a change in a browser

vwo_get_campaign_share_link does not return a live preview. I checked VWO's actual response schema before writing anything that depends on it: it returns a link into VWO's own dashboard summary/report page (https://app.wingify.com/#/campaign/{id}/summary?token=...), and there is no separate "preview URL" endpoint anywhere in VWO's v2 API.

What VWO's product actually provides: that summary page hosts a preview control — a field to enter a URL and a button that opens a live rendering of the campaign for that URL in a new tab. That's a UI feature, not an API contract, so the prompts tell the model to locate it visually (via a screenshot) rather than assume fixed coordinates or a stable selector. The intended flow, if a browser automation tool is present in the session — the prompts check for any browser automation capability, not specifically a tool named "Chrome DevTools MCP":

Open the share link.
Find the preview control, enter the campaign's primaryUrl, activate it.
It opens a new tab with the variation actually rendered — enumerate open tabs to find it, switch to it, screenshot it, and compare against the specific intended change (for the split-test workflow: compare against the intended destination URL instead — there is no DOM to diff, and VWO's traffic split may route a given visit to any variation, so one preview attempt confirms landing on one expected destination, not all of them at once).
On a further edit, reload that same tab rather than reopening the share link and re-clicking through the control each time.

If no browser tool is available at all, the prompt tells the model to say so explicitly and immediately — not discover the gap silently after attempting a call, and not quietly downgrade to a weaker check while implying the change was verified. It then tries, in order: ask the user to open the share link and preview control themselves and report what they see (their report counts as verification); failing that, fall back to re-fetching the variation to confirm editorData stored the intended edit — and explicitly label that outcome unverified, since confirming the data was stored is not the same as confirming it rendered. The point is that the model should never report a content change as "done" with more confidence than it actually earned.

Quick start

Requires Node.js >= 20.19 (declared in package.json's engines field).

npm install && npm run build

Then set a token and confirm it works — this makes one real API call and prints a diagnostic:

VWO_API_TOKEN=your-token-here node dist/index.js --verify

Exit code 0 means the credentials work. Generate a token at https://app.vwo.com/#/developers/tokens.

To actually register the server with Claude Code and/or Claude Desktop, see GETTING-STARTED.md — node scripts/register_mcp_server_claude.js does the build, the link, and the host config in one interactive pass.

Configuring the API token

This is the part worth getting right, so here is how MCP servers handle it in general before the specifics.

The model never sees the token, because the token is never part of the MCP conversation. An MCP server is a separate process. The host (your agent wrapper) launches it and passes secrets through the process environment — the same way you'd configure any CLI tool. The agent only ever sees tool results. There is no code path by which the token reaches the model's context: it is read once at startup in src/config.ts, attached to outbound requests in src/vwo/client.ts, and scrubbed from every log line and tool result by src/redact.ts.

That is the standard pattern — the official GitHub, Slack, and Postgres MCP servers all work this way.

Option A — `.mcp.json` in the consuming project, with variable expansion (recommended)

Drop examples/mcp.json into the root of the project that uses the server, as .mcp.json. Claude Code expands ${VAR} and ${VAR:-default} in command, args, env, url, and headers — so the file references the secret without containing it, and stays safe to commit:

{
  "mcpServers": {
    "vwo": {
      "type": "stdio",
      "command": "node",
      "args": ["${VWO_MCP_HOME:-../unofficial-vwo-mcp-server}/dist/index.js"],
      "env": {
        "VWO_API_TOKEN": "${VWO_API_TOKEN}"
      }
    }
  }
}

VWO_API_TOKEN then comes from wherever you keep it — your shell profile, your OS keychain, or .claude/settings.local.json (below). If it's unset, Claude Code loads the config anyway and reports a missing-variable warning in claude mcp list.

Project-scoped .mcp.json servers need one-time approval; Claude Code prompts on first use, or you can pre-approve with "enabledMcpjsonServers": ["vwo"] in .claude/settings.json.

Scopes. --scope project writes .mcp.json (shared, committed). --scope local — the default — writes ~/.claude.json under that project's path, which is private to you and never in version control. Local scope is the better home for a literal token:

claude mcp add vwo --scope local --env VWO_API_TOKEN=your-token -- node /abs/path/dist/index.js

Option A2 — `.claude/settings.local.json` to supply the variable

.claude/settings.json supports an env block whose variables apply to the session and to subprocesses Claude Code spawns, which includes MCP servers. Put the secret in .claude/settings.local.json — Claude Code gitignores that file when it creates it, and it overrides the committed settings.json:

{
  "env": {
    "VWO_API_TOKEN": "your-token-here"
  }
}

Pair it with the committed .mcp.json from Option A: the shared file declares the server, the personal file supplies the credential. If you create settings.local.json by hand, add it to .gitignore yourself.

Most hosts work the same way — a command/args/env block — but the exact file and key names vary. Two more, each verified against its current docs rather than assumed:

VS Code (native MCP support). Save examples/vscode-mcp.json as .vscode/mcp.json (workspace) or via the MCP: Open User Configuration command (user profile, applies to all workspaces). The top-level key is servers, not mcpServers. Secrets use an inputs block instead of shell expansion:

{
  "inputs": [
    { "type": "promptString", "id": "vwo-api-token", "description": "VWO API token", "password": true }
  ],
  "servers": {
    "vwo": {
      "type": "stdio",
      "command": "node",
      "args": ["/absolute/path/to/unofficial-vwo-mcp-server/dist/index.js"],
      "env": { "VWO_API_TOKEN": "${input:vwo-api-token}" }
    }
  }
}

VS Code prompts for the token the first time the server starts and stores it securely — it's never written into mcp.json.

Codex CLI. Append to examples/codex-config.toml at ~/.codex/config.toml (all projects) or ./.codex/config.toml (this project). Codex's config is TOML, not JSON, and has no ${VAR} expansion — instead, env_vars forwards specific variables that are already set in your shell into the server's process:

[mcp_servers.vwo]
command = "node"
args = ["/absolute/path/to/unofficial-vwo-mcp-server/dist/index.js"]
env_vars = ["VWO_API_TOKEN"]

Any other host follows the same shape — declare the server, supply VWO_API_TOKEN however that host keeps secrets out of its config file:

{
  "mcpServers": {
    "vwo": {
      "command": "node",
      "args": ["/absolute/path/to/unofficial-vwo-mcp-server/dist/index.js"],
      "env": { "VWO_API_TOKEN": "your-token-here" }
    }
  }
}

If a token ends up literally in a config file, protect it like any credential file (chmod 600, never committed).

Option B — a token file (better isolation)

A process's environment is readable by other processes on some systems (ps -e, /proc/<pid>/environ). To avoid that, point the server at a file whose entire contents are the token:

"env": { "VWO_API_TOKEN_FILE": "/run/secrets/vwo_api_token" }

VWO_API_TOKEN_FILE takes precedence over VWO_API_TOKEN. This composes directly with Docker/Kubernetes secret mounts and with pass/age-style secret files.

Option C — reading from an OS keychain at spawn time

Best of both for a desktop wrapper: keep the secret in the OS keychain and resolve it only when launching the child process, so it is never written to disk in plaintext.

// In your agent wrapper, when spawning the MCP server:
const token = await keytar.getPassword('vwo-mcp', 'api-token'); // or `security find-generic-password` / DPAPI
const child = spawn('node', ['dist/index.js'], {
    env: { ...process.env, VWO_API_TOKEN: token },
    stdio: ['pipe', 'pipe', 'pipe']
});

Your wrapper owns the "ask the user for their key once, store it securely" UX; the MCP server stays a dumb consumer of an env var. That separation is deliberate — it keeps the server usable from any host.

Option D — `.env` for local development only

Copy .env.example to .env. .env is gitignored. Note the server does not load .env itself; use your shell or a runner:

node --env-file=.env dist/index.js --verify

Why the token is not a tool parameter

A tempting alternative is an authenticate(apiKey) tool. Don't — it is the one design that actively breaks the security property:

The model would have to know the key to pass it, so it lands in the context window.
It would be written into conversation transcripts and any logging around them.
It would be replayed on every tool call, multiplying exposure.
Anything that can read the transcript — including a prompt injection that gets the agent to repeat it — can exfiltrate it.

Secrets belong in the process boundary, not the conversation. There is intentionally no tool in this server that accepts, sets, or returns a token.

If you later expose this over HTTP instead of stdio

For a multi-tenant or remote deployment, per-user tokens in the server environment stop making sense. MCP's answer is OAuth 2.1: the server acts as an OAuth Resource Server and each request carries the caller's bearer token. The SDK ships the pieces (verifyBearerToken, OAuthTokenVerifier, protected-resource metadata helpers). That is a different architecture from this one — out of scope here, but the client and tool layers would carry over unchanged since auth is isolated to config.ts + client.ts.

All configuration

Variable	Required	Default	Purpose
`VWO_API_TOKEN`	yes*	—	API token.
`VWO_API_TOKEN_FILE`	yes*	—	Path to a file containing the token. Wins over `VWO_API_TOKEN`.
`VWO_ACCOUNT_ID`	no	—	Default account: a numeric id, or `current`. Unset means tools require an explicit `accountId`.
`VWO_ALLOWED_ACCOUNT_IDS`	no	unrestricted	Comma-separated allow-list of account ids this server may touch.
`VWO_API_BASE_URL`	no	`https://app.wingify.com/api/v2`	Set to `https://app.vwo.com/api/v2` for the older host. Must be https and end in `/v2`.
`VWO_AUTH_HEADER`	no	`token`	Header carrying the token, per VWO's docs.
`VWO_MIN_REQUEST_INTERVAL_MS`	no	`1000`	Request spacing. VWO allows 1 req/sec per token.
`VWO_REQUEST_TIMEOUT_MS`	no	`30000`	Per-request timeout.
`VWO_LOG_LEVEL`	no	`info`	`debug` \| `info` \| `warn` \| `error`. Goes to stderr.

* One of the two is required. Startup fails with exit code 78 (EX_CONFIG) and an actionable message if neither is set.

Which tools auto-run and which need approval

This is a host concern, not something .mcp.json controls. In Claude Code it lives in .claude/settings.json under permissions — see examples/claude-settings.json:

{
  "enabledMcpjsonServers": ["vwo"],
  "permissions": {
    "allow": ["mcp__vwo__vwo_verify_connection", "mcp__vwo__vwo_list_*", "mcp__vwo__vwo_get_*"],
    "ask":   ["mcp__vwo__vwo_new_*", "mcp__vwo__vwo_create_*", "mcp__vwo__vwo_add_*", "mcp__vwo__vwo_update_*"],
    "deny":  ["mcp__vwo__vwo_delete_*"]
  }
}

The tool names are deliberately prefix-consistent so this stays a four-line policy: vwo_list_* and vwo_get_* are exactly the read tools, and every mutating tool starts with vwo_new_, vwo_create_, vwo_add_, vwo_update_, or vwo_delete_. Move vwo_delete_* from deny to ask when you want deletions available.

The mcp__vwo__ and vwo_ prefixes look redundant here on purpose: mcp__vwo__ is Claude Code's server namespace and disappears in hosts that don't add one, while vwo_ is this server's own prefix and is what the model actually reads in tool descriptions and error messages ("call vwo_list_workspaces first") regardless of host. If you expect to run this server alongside others that also prefix their own tools, the double prefix is the price of names that stay meaningful outside Claude Code too — see multiple MCP servers.

Matcher syntax:

Pattern	Matches
`mcp__vwo`	every tool from the `vwo` server
`mcp__vwo__*`	same, wildcard form
`mcp__vwo__vwo_list_campaigns`	that one tool
`mcp__vwo__vwo_get_*`	its `vwo_get_` tools

The server name is whatever key you used in .mcp.json. Allow-rule globs are only permitted after a literal mcp__<server>__ prefix — a bare "*" or "mcp__*" in allow is ignored with a warning. deny and ask accept broader globs, so "deny": ["mcp__*"] blocks all MCP tools.

Put the rules in committed .claude/settings.json to share them, or .claude/settings.local.json to keep them personal (local wins).

Running alongside other MCP servers

If your wrapper also loads, say, Chrome DevTools MCP, every tool name arrives in the model's context at once. Two reasons vwo_ earns its keep in that situation specifically:

Not every host namespaces by server the way Claude Code does. A wrapper that flattens tool names, or a host with no namespacing convention at all, would otherwise expose a bare list_campaigns sitting next to some other server's list_pages with nothing marking either as belonging to a particular integration.
Namespacing only covers the tool list. Tool descriptions and this server's own error messages reference other tools by name in prose ("call vwo_list_workspaces first"), and that text is host-agnostic — it reads correctly whether or not the host prefixes anything.

The trade-off is that in a host which does namespace, permission rules end up with the double prefix seen above (mcp__vwo__vwo_list_campaigns). That's cosmetic; the glob policy is unaffected either way.

Two server-side backstops, so a permissive host config can't cause damage on its own:

Read-only tools declare annotations.readOnlyHint, letting hosts treat them as safe.
Destructive tools should spread REQUIRES_HUMAN_APPROVAL from tools/shared.ts into their config. Claude Code then prompts on every call even in bypassPermissions mode and even if an allow rule matches. Use it for anything that mutates a live experiment.

Choosing which VWO account a tool acts on

Your token manages multiple accounts (VWO's UI calls them workspaces), so this is the part most likely to go wrong quietly. The resolution order for every account-scoped tool:

Explicit accountId argument.
workspaceName argument, resolved via GET /accounts.
VWO_ACCOUNT_ID default, if configured.
Otherwise: a deliberate error telling the agent to call vwo_list_workspaces and ask the user.

Step 4 is the important one. The obvious alternative — falling back to VWO's accounts/current — is the dangerous option: a multi-account token would happily run the call against whichever account VWO considers current, which is rarely the one the user meant. Failing with instructions costs one extra round trip and can't touch the wrong client's data.

So does the LLM ask, or look it up?

It looks it up, then asks only if ambiguous. Concretely, when the user says "pause the homepage test in Acme Corp":

The agent calls vwo_list_workspaces → [{id: 12345, name: "Acme Corp"}, ...].
It calls vwo_list_campaigns with accountId: 12345.

You can skip step 1 by passing workspaceName: "Acme Corp" directly; the server resolves it. Name resolution is deliberately strict — an unknown or ambiguous name returns an error listing the candidates rather than picking one, which turns a potential wrong-account write into a clarifying question. The tool descriptions tell the model, in as many words, never to guess an id.

The account list is cached for 60 seconds, since VWO allows only 1 request/second per token and name resolution would otherwise spend that budget on every call.

Pick the setup that matches your usage

Situation	Configuration
Always one account	`VWO_ACCOUNT_ID=12345` — the model never thinks about accounts.
Many accounts, agent chooses	Leave `VWO_ACCOUNT_ID` unset. Tools require an explicit account.
Many accounts, but only some in scope	`VWO_ALLOWED_ACCOUNT_IDS=12345,67890`. Anything else is refused and hidden from `vwo_list_workspaces`.
One agent per client	Run one server instance per account, each with its own `VWO_ACCOUNT_ID`, registered under distinct names (`vwo-acme`, `vwo-globex`). Permission rules can then differ per client.

VWO_ALLOWED_ACCOUNT_IDS is enforced in two places: the account list is filtered, and any explicit accountId outside the list is refused. It's the guardrail worth setting if the token can reach clients this agent has no business touching.

API version safety

The server uses v2 only. Worth knowing why that's enforced rather than assumed: https://app.wingify.com/api/v1/... returns HTTP 200 with a body of {"API_ERROR":"INCORRECT_API_VERSION"}. A client that trusts the status code would read that as success and hand the agent an empty result.

Two guards:

VWO_API_BASE_URL must end in /v2, checked at startup.
The client inspects every 2xx body for VWO's error envelopes (_errors, API_ERROR) and raises a VwoApiError if present. VWO returns errors in-band, so status codes alone are not trustworthy.

Project layout

src/
  index.ts          entry: loads config, serves stdio, handles --verify
  config.ts         env + token-file loading, validation, defaults
  logger.ts         stderr-only logging (stdout is the JSON-RPC channel)
  redact.ts         secret-scrubbing registry
  vwo/
    client.ts       HTTP client: auth header, rate-limit gate, retries, error envelopes
    errors.ts       VwoApiError + agent-facing messages
    accounts.ts     account/workspace directory, name resolution, caching
    verify.ts       shared credential check
  tools/
    index.ts            single registration point for all tools
    shared.ts           ToolContext, accountArgs, resolveAccount, bodyArg, error wrapper
    campaignResource.ts factory for goals/variations/sections (identical CRUD shape)
    diagnostics.ts      vwo_verify_connection
    workspaces.ts       campaigns.ts       drafts.ts
    goals.ts            variations.ts      sections.ts
    labels.ts           metric_reports.ts  tracking_code.ts
    custom_widgets.ts   websites.ts (empty — no website tools requested yet)
  prompts/
    index.ts              single registration point for all prompts
    shared.ts             snapshot fetch, verify/wrap-up sections shared by the 3 workflows
    general.ts            vwo_general_guidance
    abTestWorkflow.ts     vwo_ab_test_workflow — same-page content changes
    splitTestWorkflow.ts  vwo_split_test_workflow — per-variation destination URLs
    webRolloutWorkflow.ts vwo_web_rollout_workflow — no control, no goal
examples/
  mcp.json             Claude Code: drop into a consuming project as .mcp.json
  claude-settings.json Claude Code: permission rules for .claude/settings.json
  vscode-mcp.json       VS Code: save as .vscode/mcp.json
  codex-config.toml     Codex CLI: append to ~/.codex/config.toml
scripts/
  register_mcp_server_claude.js  interactive: build + link + register with
                                  Claude Code and/or Claude Desktop (see GETTING-STARTED.md)
  install_package_locally.sh/.bat  build + `npm link` only, for wiring into
                                     a host's config by hand

Adding a tool

Create src/tools/<area>.ts following campaigns.ts.
Spread accountArgs into the input schema and call await resolveAccount(ctx, args) so every tool targets an account identically and inherits the allow-list check.
Wrap the implementation in toolHandler(name, fn) so VWO errors become readable isError results instead of exceptions.
Call VWO through ctx.client — never construct headers or read the token in tool code.
For anything that mutates state, set annotations.destructiveHint and spread REQUIRES_HUMAN_APPROVAL.
Register it in src/tools/index.ts.

Write descriptions for the agent, not for a human reading API docs: say when to reach for the tool and what it returns, and use annotations.readOnlyHint / destructiveHint honestly so hosts can gate write operations.

Design notes

stdout is sacred. On stdio transport, stdout carries JSON-RPC framing. All logging goes to stderr; console.log must never be used in this project.
Rate limiting is process-wide. VWO allows 1 request/second per token, so one shared gate in VwoClient paces all calls regardless of how many tools fire concurrently.
Retries distinguish "rejected" from "possibly applied." GETs retry on 429, 5xx, and network failures. Writes (POST/PATCH/DELETE) retry on 429 only — a rate limit is refused at the limiter so nothing was applied, making a replay safe even for a non-idempotent write, whereas a 5xx or a dropped connection may mean VWO already made the change and only the response was lost. That distinction is rejectedWithoutSideEffect vs retryable in errors.ts, selected per request by RetryPolicy in client.ts. Backoff honours Retry-After. Verified against a local fake server across all six method/failure combinations.
The rate-limit gate is per-process, so 429s are still reachable. One shared gate paces this process at VWO's 1 req/sec, but another process using the same token spends the same budget — which is exactly how a 429 surfaced during testing. This is why writes retry on 429 rather than assuming the gate makes it impossible.
Errors are written for an agent. VwoApiError.agentMessage tells the model whether a failure is worth retrying — a 401 explicitly says "configuration problem, do not retry".

SDK version pinning

@modelcontextprotocol/server is pinned to an exact beta (2.0.0-beta.3) because v2 is pre-stable and its API is still moving. This project's npm is configured with min-release-age=14, so the newest installable beta lags the newest published one. Bump deliberately:

npm view @modelcontextprotocol/server versions --json
npm install @modelcontextprotocol/server@<next-beta> && npm run build

The surfaces used are McpServer, registerTool, and serveStdio — the most likely breaking changes are in tool-registration and result shapes, both confined to src/tools/.

Available Tools

45 tools

vwo_add_campaign_labelAdd labels to a VWO campaignA

Apply one or more existing labels to a VWO campaign. Labels are organisational only and do not affect what visitors see. Call vwo_list_labels first to get valid label ids.

ParametersJSON Schema

Name	Required	Description
`body`	Yes	The label(s) to apply, typically by id. VWO does not publish a schema for this request body; see https://developers.wingify.com/reference/add-labels-to-a-campaign for the accepted fields. The object is sent to VWO as-is.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`campaignId`	Yes	VWO campaign id. Call vwo_list_campaigns first if you do not have it.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4.2/5.0

Behavior4/5

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

The description states that labels are 'organisational only and do not affect what visitors see,' which adds useful context beyond the annotations. Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description complements them without contradiction.

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

Conciseness5/5

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

The description is two concise sentences: first explains the purpose, second gives a key prerequisite. No wasted words.

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

Completeness4/5

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

Given the complexity (4 params, one is a free-form object) and no output schema, the description provides essential context (prerequisite calls) and references external docs for the body. It could mention the response format, but overall it is fairly complete.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already describes each parameter well. The description only adds a general hint about using vwo_list_labels for valid ids but doesn't elaborate on parameter meaning beyond what the schema provides. Thus, baseline of 3 is appropriate.

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 description clearly states the action 'Apply one or more existing labels to a VWO campaign' using a specific verb and resource. It also clarifies that labels are organizational only, distinguishing this from other labeling operations like vwo_list_campaign_labels or vwo_delete_campaign_label.

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

Usage Guidelines4/5

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

It explicitly provides a prerequisite: 'Call vwo_list_labels first to get valid label ids.' While it doesn't mention when not to use this tool, the clear instruction helps the agent avoid errors. It could be improved by noting that this is only for adding labels, not modifying or removing them.

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

vwo_create_custom_widgetsCreate VWO custom widgets in bulkA

Create several custom widgets in one request. Prefer this over repeated vwo_new_custom_widget calls, since VWO permits only 1 request per second.

ParametersJSON Schema

Name	Required	Description
`body`	Yes	Bulk payload describing the widgets to create. VWO does not publish a schema for this request body; see https://developers.wingify.com/reference/create-bulk-custom-widgets for the accepted fields. The object is sent to VWO as-is.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate this is a write but non-destructive operation (readOnlyHint=false, destructiveHint=false). The description adds the rate limit constraint, which is behavioral context beyond annotations. No contradictions, but could mention failure behavior for partial batch failures.

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

Conciseness5/5

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

Two concise sentences with no wasted words. Front-loaded with action and resource, then provides best practice guidance. Highly efficient.

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

Completeness3/5

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

For a bulk create tool with no output schema, the description covers purpose and rate limit but lacks details on error handling, idempotency, or response format. Given the complexity of the 'body' parameter and the lack of output schema, more context would be valuable but the description is minimally adequate.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The tool description does not add additional parameter-level details beyond what is in the schema. Baseline of 3 is appropriate.

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 description clearly states it creates several custom widgets in one request. The title includes 'in bulk', and the description distinguishes from repeated 'vwo_new_custom_widget' calls, making the purpose specific and well-defined.

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?

Explicitly advises to prefer this tool over repeated single creation calls due to VWO's 1 request per second rate limit. This provides clear when-to-use and when-not-to-use guidance, with a named alternative.

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

vwo_delete_campaign_goalDelete a VWO campaign goalA

DestructiveIdempotent

Permanently delete a goal from a VWO campaign. This cannot be undone. Goals define what the experiment measures, so changing them on a running campaign affects reported results and can invalidate conclusions drawn so far. Confirm the specific goal with the user before calling.

ParametersJSON Schema

Name	Required	Description
`goalId`	Yes	VWO goal id. Call vwo_list_campaign_goals first if you do not have it.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`campaignId`	Yes	VWO campaign id. Call vwo_list_campaigns first if you do not have it.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4.5/5.0

Behavior5/5

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

The description adds important behavioral details beyond annotations: permanence, impact on running campaigns, and the need for user confirmation, while annotations already indicate destructive and non-read-only behavior.

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

Conciseness5/5

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

The description is concise with three sentences, each adding value: action, impact, and instruction. It is front-loaded with the primary purpose.

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?

For a delete tool with full parameter schema and annotations indicating destructiveness, the description is complete, including necessary warnings and user guidance.

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

Parameters3/5

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

The tool description does not add parameter semantics beyond the input schema, which already has 100% coverage and clear descriptions for all parameters.

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 description clearly states the tool 'Permanently delete a goal from a VWO campaign', using a specific verb (delete) and resource (campaign goal), and distinguishes it from siblings like updating or listing goals.

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

Usage Guidelines4/5

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

It warns about the irreversible impact on results and instructs to confirm with the user, providing good usage context, though it doesn't explicitly list alternatives.

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

vwo_delete_campaign_labelRemove a label from a VWO campaignA

DestructiveIdempotent

Remove one label from a VWO campaign. This detaches the label from the campaign; it does not delete the label from the workspace.

ParametersJSON Schema

Name	Required	Description
`labelId`	Yes	Label id to remove. Call vwo_list_campaign_labels if you do not have it.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`campaignId`	Yes	VWO campaign id. Call vwo_list_campaigns first if you do not have it.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4/5.0

Behavior4/5

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

The description adds important context beyond annotations: it clarifies that detaching does not delete the label from the workspace, which is not evident from the annotations alone (destructiveHint=true indicates deletion but here it's a relationship removal). This helps an agent understand the actual scope of the operation.

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

Conciseness5/5

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

Two sentences, zero wasted words. Front-loaded with the core action, followed by a crucial clarification. Every sentence earns its place.

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

Completeness4/5

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

For a simple tool with full schema annotations, the description is adequate. It clarifies the non-destructive nature regarding the label itself and explains the single-label removal. No output schema exists, so return values are not expected; however, a brief note on the result (e.g., success/failure) could enhance completeness.

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

Parameters3/5

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

Schema coverage is 100% and each parameter already has descriptive text (e.g., 'Call vwo_list_campaign_labels if you do not have it'). The tool description does not add further parameter-level detail, but the schema fully covers semantics, so baseline 3 is appropriate.

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 description clearly states the tool removes a label from a VWO campaign, using specific verb 'Remove' and resource 'label from a VWO campaign'. It distinguishes from siblings like vwo_add_campaign_label (adds) and vwo_list_campaign_labels (lists).

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

Usage Guidelines3/5

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

The description implicitly indicates when to use the tool (to detach a label from a campaign) and clarifies what it does not do (delete the label), but it does not explicitly compare with alternatives or provide when-not-to-use guidance.

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

vwo_delete_campaign_sectionDelete a VWO campaign sectionA

DestructiveIdempotent

Permanently delete a section from a VWO campaign. This cannot be undone. Sections determine which page areas the campaign varies, so changes affect what live visitors see and how combinations are reported. Confirm the specific section with the user before calling.

ParametersJSON Schema

Name	Required	Description
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`sectionId`	Yes	VWO section id. Call vwo_list_campaign_sections first if you do not have it.
`campaignId`	Yes	VWO campaign id. Call vwo_list_campaigns first if you do not have it.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the destructiveHint=true annotation, the description explicitly states 'cannot be undone' and explains the real-world effect on visitors and reporting. This adds valuable behavioral context beyond what annotations provide.

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

Conciseness5/5

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

The description is four concise sentences. Each sentence serves a distinct purpose: stating the action, emphasizing irreversibility, explaining impact, and providing usage guidance. No wasted words.

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

Completeness4/5

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

The description covers the key aspects: action, irreversibility, impact on visitors, and user confirmation. While it lacks explicit mention of return value or error handling, the annotations and schema cover safety and parameters adequately.

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

Parameters3/5

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

The input schema already provides 100% coverage with clear descriptions for all parameters. The description does not add new parameter-specific information, so it meets the baseline but does not exceed it.

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 description clearly states the verb 'delete' and the resource 'section from a VWO campaign', and emphasizes permanence. It distinguishes from siblings like vwo_delete_campaign_goal or vwo_update_campaign_section by specifying the exact operation.

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

Usage Guidelines4/5

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

The description explains when to use the tool: to permanently remove a section after user confirmation. It warns about impact on live visitors and reporting, guiding appropriate context. However, it does not explicitly mention alternatives or when not to use it.

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

vwo_delete_campaign_variationDelete a VWO campaign variationA

DestructiveIdempotent

Permanently delete a variation from a VWO campaign. This cannot be undone. Variations are what live visitors actually see, so changes take effect on real traffic and alter the data being collected. Confirm the specific variation with the user before calling.

ParametersJSON Schema

Name	Required	Description
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`campaignId`	Yes	VWO campaign id. Call vwo_list_campaigns first if you do not have it.
`variationId`	Yes	VWO variation id. Call vwo_list_campaign_variations first if you do not have it.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4.4/5.0

Behavior5/5

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

The description discloses the destructive nature ('Permanently delete', 'cannot be undone') and the real-world impact ('Variations are what live visitors actually see... changes take effect on real traffic'), adding value beyond the destructiveHint annotation.

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

Conciseness5/5

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

The description is three short, focused sentences. Every sentence provides essential information: action, permanence, real-world impact, and a usage guideline. No superfluous content.

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

Completeness4/5

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

Given the tool is a delete operation with no output schema, the description covers the core aspects: what it does, its irreversible nature, its effect on live traffic, and the need for user confirmation. It could mention how to retrieve variation IDs, but the schema's parameter descriptions already point to the relevant list tool.

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

Parameters3/5

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

Schema description coverage is 100%, and each parameter already has a detailed description in the schema. The tool description does not add any parameter-specific information, so it meets the baseline expectation.

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 description clearly states the action: 'Permanently delete a variation from a VWO campaign.' The verb 'delete' and resource 'variation' are explicit, and the tool is distinct from other variation tools (e.g., update, new) among siblings.

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

Usage Guidelines4/5

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

The description provides a key guideline: 'Confirm the specific variation with the user before calling.' This indicates when to use the tool and emphasizes caution. It does not explicitly list when not to use or alternatives, but the context is clear.

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

vwo_delete_custom_widgetDelete a VWO custom widgetA

DestructiveIdempotent

Permanently delete a custom widget. This cannot be undone, and will break any campaign still linked to it. Confirm the specific widget with the user first.

ParametersJSON Schema

Name	Required	Description
`widgetId`	Yes	Custom widget (changeset) id. Call vwo_list_custom_widgets if you do not have it.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4.5/5.0

Behavior5/5

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

The description adds significant behavioral context beyond annotations: it specifies the deletion is permanent, irreversible, and will break linked campaigns. This complements the destructiveHint and idempotentHint annotations with concrete details.

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

Conciseness5/5

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

The description is extremely concise (two sentences) with no fluff. Every sentence serves a purpose: stating the action/consequence and providing a usage instruction. Ideal for quick comprehension.

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?

For a deletion tool with clear side effects and no output schema, the description is complete. It covers the essential behavioral details (irreversibility, impact on campaigns, need for confirmation).

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

Parameters3/5

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

Schema description coverage is 100%, so the description does not need to elaborate on parameters. It adds only a brief mention to confirm the widget, but no additional parameter-level meaning beyond what the schema already provides.

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 description clearly states the action ('Permanently delete a custom widget') and the resource, distinguishing it from sibling tools like vwo_new_custom_widget or vwo_update_custom_widget. It also emphasizes the irreversible nature and consequences.

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

Usage Guidelines4/5

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

It instructs to confirm with the user first, ensuring appropriate context. The schema description for widgetId provides guidance to use vwo_list_custom_widgets if needed. However, it does not explicitly exclude scenarios where a soft-disable might be preferred over deletion.

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

vwo_delete_draft_campaignsDelete a VWO draft campaignA

DestructiveIdempotent

Permanently delete a draft campaign. This cannot be undone — confirm the specific draft with the user, by name, before calling.

ParametersJSON Schema

Name	Required	Description
`draftId`	Yes	VWO draft campaign id. Call vwo_list_drafts if you do not have it.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4.2/5.0

Behavior4/5

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

The description reinforces the destructiveHint annotation by stating permanence and irreversibility. It adds user confirmation requirement, which is valuable context beyond the annotations.

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

Conciseness5/5

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

The description is extremely concise (two sentences) with no fluff. It front-loads the purpose and includes essential safety guidance.

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

Completeness4/5

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

Given the tool is a destructive delete with no output schema and annotations cover safety, the description adequately informs the agent to confirm with the user. It could mention potential error states, but overall sufficient.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already explains all parameters. The description adds no extra parameter information; it only references the list_drafts call in the schema description for draftId.

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 description clearly states the tool's action (delete) and target (draft campaign) with the qualifier 'permanently'. It distinguishes from sibling tools like vwo_update_draft_campaigns by specifying deletion.

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

Usage Guidelines4/5

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

The description provides a clear safety guideline: confirm the specific draft with the user by name before calling. However, it does not explicitly state when to use this tool over alternatives, though the destructive nature is implied.

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

vwo_get_campaignGet VWO campaign detailsA

Read-only

Get the full configuration of one campaign: type, status, URLs, goals, variations, and targeting.

ParametersJSON Schema

Name	Required	Description
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`campaignId`	Yes	VWO campaign id. Call vwo_list_campaigns first if you do not have it.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A3.8/5.0

Behavior4/5

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

Annotations (readOnlyHint) already declare safe read. Description adds that it returns type, status, URLs, goals, variations, and targeting, which goes beyond annotations. Adequate behavioral context given annotations.

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

Conciseness5/5

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

Single sentence, front-loaded with key information ('Get the full configuration of one campaign'). No wasted words. Efficient and clear.

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

Completeness4/5

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

For a read-only get tool with annotations and complete schema descriptions, the description is sufficient. It covers the main purpose and data returned. Could add typical usage context but not required.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The tool description does not add parameter details, but param descriptions in schema are already rich. No additional value needed.

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?

Clearly states 'Get the full configuration of one campaign' with specific data points (type, status, URLs, goals, variations, targeting). Distinguishes from siblings like vwo_list_campaigns (list) and vwo_get_campaign_share_link (share link).

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

Usage Guidelines2/5

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

No explicit when-to-use or alternatives in the description. While param descriptions hint at prerequisite calls (e.g., vwo_list_campaigns), the tool description itself lacks usage guidelines.

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

vwo_get_campaign_goalGet VWO campaign goalA

Read-only

Get the full configuration of one goal on a VWO campaign.

ParametersJSON Schema

Name	Required	Description
`goalId`	Yes	VWO goal id. Call vwo_list_campaign_goals first if you do not have it.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`campaignId`	Yes	VWO campaign id. Call vwo_list_campaigns first if you do not have it.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already provide readOnlyHint=true, so the agent knows it's a safe read operation. The description adds no further behavioral context (e.g., what 'full configuration' entails, permissions, or side effects). With annotations covering safety, a score of 3 is acceptable.

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?

Single sentence, no wasted words. It is front-loaded with the main action. Could be slightly more structured (e.g., bullet points) but remains efficient.

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

Completeness2/5

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

No output schema, yet the description does not explain what the returned 'full configuration' contains (e.g., fields, structure). Given the tool returns data and has 4 parameters, this is a notable gap. Sibling tools exist for related operations, but no cross-referencing is provided.

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

Parameters3/5

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

Schema has 100% coverage with detailed parameter descriptions (e.g., how to obtain goalId). The tool description itself adds no extra semantics beyond what the schema provides, so baseline 3 applies.

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?

Description clearly states 'Get the full configuration of one goal on a VWO campaign', specifying the verb and resource. It distinguishes from sibling tools like vwo_list_campaign_goals (which lists goals) and vwo_get_campaign (which gets a campaign).

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

Usage Guidelines3/5

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

No explicit when-to-use or when-not-to-use guidance. The parameter descriptions hint at prerequisites (e.g., call vwo_list_campaign_goals first), but the main description lacks context about when this tool is appropriate versus alternatives.

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

vwo_get_campaign_sectionGet VWO campaign sectionA

Read-only

Get the full configuration of one section on a VWO campaign.

ParametersJSON Schema

Name	Required	Description
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`sectionId`	Yes	VWO section id. Call vwo_list_campaign_sections first if you do not have it.
`campaignId`	Yes	VWO campaign id. Call vwo_list_campaigns first if you do not have it.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the description's 'Get' aligns with being a read operation. It adds context of 'full configuration' but does not disclose additional behaviors like error handling, availability, or permissions. Adequate but not enriching beyond annotations.

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

Conciseness5/5

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

The description is a single, well-structured sentence of 11 words. It is front-loaded with the action and resource, with no wasted words.

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

Completeness4/5

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

For a simple read operation with no output schema, the description explains what the tool returns ('full configuration') and implies its read-only nature. It is complete enough for the agent to understand the tool's purpose and basic behavior, though a note on return format would be nice.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description does not add extra meaning or usage details for parameters beyond what the schema provides. Baseline score of 3 is appropriate.

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 description 'Get the full configuration of one section on a VWO campaign' clearly states the action (get), the resource (section configuration), and scope (one section). It differentiates from sibling tools like vwo_list_campaign_sections (list) and vwo_update_campaign_section (update).

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

Usage Guidelines2/5

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

The description does not provide any guidance on when to use this tool versus alternatives. While the schema notes to call vwo_list_campaign_sections first if missing the sectionId, this is not in the description itself. No explicit when/when-not context.

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

vwo_get_campaign_share_linkGet VWO campaign share linkA

Read-only

Get a shareable report link for a campaign, for sending results to someone without a VWO login.

ParametersJSON Schema

Name	Required	Description
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`campaignId`	Yes	VWO campaign id. Call vwo_list_campaigns first if you do not have it.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true. Description adds that it produces a shareable link and why it's useful (no login needed). No side effects mentioned, but read-only nature is clear.

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

Conciseness5/5

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

Single sentence, no filler. Front-loads the action and purpose.

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

Completeness4/5

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

Adequate for a simple read tool with no output schema. Covers purpose, use case, and required parameters. Could mention return type (URL string) but not essential.

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

Parameters3/5

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

Schema coverage is 100% with detailed descriptions for each parameter. The description does not add parameter-specific info beyond the schema, so baseline score is appropriate.

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?

Clear verb 'Get' + resource 'shareable report link for a campaign' + purpose 'for sending results to someone without a VWO login'. Distinct from siblings like vwo_get_campaign.

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

Usage Guidelines4/5

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

Explicit usage scenario: sharing results with non-login users. No exclusions or alternatives mentioned, but context is clear and distinguishes from other read tools.

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

vwo_get_campaign_variationGet VWO campaign variationA

Read-only

Get the full configuration of one variation on a VWO campaign.

ParametersJSON Schema

Name	Required	Description
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`campaignId`	Yes	VWO campaign id. Call vwo_list_campaigns first if you do not have it.
`variationId`	Yes	VWO variation id. Call vwo_list_campaign_variations first if you do not have it.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already provide readOnlyHint: true and openWorldHint: true, so the description's statement 'Get the full configuration' is consistent. However, the description adds no additional behavioral context beyond what the annotations convey, such as idempotency or caching behavior.

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

Conciseness5/5

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

The description is a single, concise sentence that immediately conveys the tool's purpose. There is no fluff, and it is front-loaded with the key action and resource.

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

Completeness4/5

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

Given the simplicity of the tool (retrieve a variation), the rich schema descriptions, and the lack of an output schema, the description is largely complete. It could benefit from noting that the output is the full configuration object, but the current wording is acceptable for a read-only retrieval tool.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The input schema contains detailed descriptions for all four parameters, including prerequisites (e.g., 'Call vwo_list_campaigns first'). The tool description itself does not add any extra parameter meaning beyond what the schema provides.

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 description 'Get the full configuration of one variation on a VWO campaign' uses a specific verb ('Get') and clearly identifies the resource ('full configuration of one variation on a VWO campaign'). It distinguishes from sibling tools like vwo_list_campaign_variations (list) and vwo_new_campaign_variation (create), making its purpose unambiguous.

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

Usage Guidelines3/5

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

The description does not explicitly state when to use this tool versus alternatives or when not to use it. It implies that it is for retrieving a single variation's full configuration, but lacks explicit context such as prerequisites or exclusions. The input schema hints at calling vwo_list_campaign_variations first for the variationId, but that is not in the description itself.

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

vwo_get_custom_widgetGet VWO custom widgetA

Read-only

Get the full definition of one custom widget in a VWO workspace.

ParametersJSON Schema

Name	Required	Description
`widgetId`	Yes	Custom widget (changeset) id. Call vwo_list_custom_widgets if you do not have it.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=true and openWorldHint=true, so the description's mention of 'Get' reinforces read-only behavior. No additional behavioral details (e.g., what 'full definition' entails) are provided beyond what annotations cover.

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

Conciseness5/5

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

Single sentence of 13 words, front-loaded with verb and resource. No unnecessary words, very efficient.

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

Completeness3/5

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

For a get tool with no output schema, the description does not specify what fields constitute the 'full definition.' While annotations cover read-only and open-world, the description could be more complete by indicating the return structure or typical fields.

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

Parameters3/5

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

Schema description coverage is 100%, with thorough descriptions for all three parameters. The tool description adds no extra meaning beyond the schema, so baseline 3 is appropriate.

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?

Description clearly states 'Get the full definition of one custom widget in a VWO workspace.' It uses a specific verb ('Get') and resource ('full definition of one custom widget'), and distinguishes from siblings like vwo_list_custom_widgets (list) and vwo_new_custom_widget (create).

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

Usage Guidelines2/5

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

The main description provides no guidance on when to use this tool versus alternatives. While the schema parameter descriptions hint at using vwo_list_custom_widgets for unknown IDs, the description itself lacks explicit usage instructions.

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

vwo_get_draftGet VWO draft campaignB

Read-only

Get the full configuration of a single draft campaign.

ParametersJSON Schema

Name	Required	Description
`draftId`	Yes	VWO draft campaign id. Call vwo_list_drafts if you do not have it.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds limited behavioral insight. It mentions 'full configuration,' which implies completeness, but doesn't disclose error conditions, auth needs, or rate limits. With annotations present, this is adequate but not enhanced.

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

Conciseness5/5

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

The description is a single sentence that is front-loaded and contains no extraneous words. Every part earns its place.

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

Completeness3/5

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

With no output schema, the description should clarify return value structure. 'Full configuration' is vague. Given the number of sibling tools, the description is minimally sufficient but could be more specific about prerequisites or return contents.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The tool description adds no parameter details beyond what the schema already provides, such as linking draftId to vwo_list_drafts. No extra semantics are offered.

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

Purpose4/5

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

The description clearly states the tool retrieves the full configuration of a single draft campaign, using a specific verb and resource. It distinguishes from related tools like vwo_list_drafts (lists) and vwo_get_campaign (live campaigns), though it could explicitly mention the draft vs. live distinction.

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

Usage Guidelines2/5

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

The tool description provides no guidance on when to use or alternatives. The schema parameter draftId references vwo_list_drafts, but this is not in the description itself, leaving the agent without usage context.

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

vwo_get_metric_reportGet VWO metric reportA

Read-only

Get the details of one VWO Insights metric report by its id.

ParametersJSON Schema

Name	Required	Description
`reportId`	Yes	Metric report id. Call vwo_list_metric_reports if you do not have it.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A3.7/5.0

Behavior3/5

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

The description states 'get the details', which aligns with the readOnlyHint annotation indicating a safe read operation. No additional behavioral context is provided beyond what the annotations already convey.

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

Conciseness5/5

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

The description is a single concise sentence with no unnecessary words, enabling quick comprehension.

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

Completeness3/5

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

Given the lack of an output schema, the description does not specify what details are returned (e.g., metrics, time range). The description is adequate but could be more informative about the response structure.

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

Parameters3/5

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

Schema description coverage is 100%, with each parameter having a clear description. The tool description adds no further semantic nuance beyond what is already in the schema, so a baseline score applies.

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 description clearly states the verb 'get' and the resource 'details of one VWO Insights metric report by its id', distinguishing it from the sibling tool vwo_list_metric_reports which lists all metric reports.

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

Usage Guidelines3/5

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

The description itself does not provide explicit guidance on when to use this tool vs alternatives. However, the input schema description for reportId instructs to call vwo_list_metric_reports if the id is unknown, providing indirect usage guidance.

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

vwo_get_smartcodeGet VWO SmartCodeA

Read-only

Get the VWO SmartCode tracking snippet for a workspace — the JavaScript that must be installed on the site for campaigns to run. Use this when helping someone verify or install tracking.

ParametersJSON Schema

Name	Required	Description	Default
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already indicate readOnlyHint and openWorldHint. The description adds context that the tool retrieves a JavaScript snippet, which is consistent and helpful, and it does not contradict annotations.

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

Conciseness5/5

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

The description is two short sentences, front-loaded with the main action and purpose, with no unnecessary information.

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?

Given the simple nature of the tool (2 parameters, no output schema), the description adequately explains what it does and when to use it, with annotations covering safety.

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

Parameters3/5

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

Schema coverage is 100% with detailed parameter descriptions. The tool description adds minimal extra meaning beyond mentioning 'for a workspace,' so baseline score of 3 is appropriate.

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 description clearly states 'Get the VWO SmartCode tracking snippet for a workspace' and explains what SmartCode is, distinguishing this tool from sibling tools that handle workspaces, campaigns, etc.

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

Usage Guidelines4/5

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

The description explicitly says 'Use this when helping someone verify or install tracking,' providing a clear use case, though it does not mention when not to use it or alternative tools.

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

vwo_get_workspaceGet VWO workspace detailsA

Read-only

Get details of a single VWO workspace: name, timezone, company info, and whether it is enabled.

ParametersJSON Schema

Name	Required	Description	Default
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4/5.0

Behavior4/5

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

The description adds value beyond annotations: it specifies the exact fields returned (name, timezone, company info, enabled status). The annotations already declare readOnlyHint=true and openWorldHint=true, so the description supplements with concrete output details without contradicting them.

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

Conciseness5/5

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

The description is a single, well-structured sentence of 18 words. It front-loads the action and summarizes what the tool returns without any extraneous information.

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

Completeness4/5

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

For a simple retrieval tool with only two optional parameters and no output schema, the description adequately covers the expected return values. No missing critical details for an agent to understand the tool's function.

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

Parameters3/5

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

Schema documentation covers both parameters fully with detailed descriptions. The tool description does not add new meaning beyond the schema, but it lists the output fields, which is helpful. Baseline of 3 is appropriate given 100% schema coverage.

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 description uses 'Get details of a single VWO workspace' which clearly states the action and resource. It lists specific attributes (name, timezone, company info, enabled status) and the tool name reliably implies retrieval, distinguishing it from sibling tools like vwo_list_workspaces (list) or vwo_new_workspace (create).

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

Usage Guidelines3/5

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

The description does not provide explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. However, the purpose is clear enough that an agent can infer it is for retrieving a single workspace when the identifier is known, distinguishing it from listing or mutation tools.

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

vwo_get_workspace_historyGet VWO workspace timelineA

Read-only

Retrieve the activity timeline (feed) for a workspace — who changed what and when. Use startTime/endTime to narrow the window when investigating a specific change.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of entries.
`offset`	No	Number of items to skip, for paging.
`endTime`	No	Unix timestamp (seconds) for the end of the window.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`startTime`	No	Unix timestamp (seconds) for the start of the window.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds no behavioral traits beyond the annotations (e.g., no mention of rate limits, side effects, or response format). It is consistent but adds no extra value beyond the annotations.

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

Conciseness5/5

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

Two concise sentences: first states purpose, second gives a specific usage tip. No wasted words.

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

Completeness4/5

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

Given the tool has 6 parameters and no output schema, the description explains what the tool returns at a high level ('who changed what and when'). It could be improved by describing the return structure or pagination behavior, but it is mostly sufficient for a simple retrieval tool.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds a minor usage hint about startTime/endTime for narrowing windows, but otherwise does not add meaning beyond 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 description states a clear verb ('Retrieve') and resource ('activity timeline for a workspace'), and specifies what information is returned ('who changed what and when'). It distinguishes from sibling tools like vwo_get_workspace (which gets workspace details) and vwo_list_workspaces (which lists workspaces).

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

Usage Guidelines4/5

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

The description provides guidance on when to use startTime/endTime ('when investigating a specific change'). It does not explicitly exclude alternatives or state when not to use, but the context is clear for a read-only history tool.

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

vwo_list_campaign_goalsList VWO campaign goalsA

Read-only

List the goals configured on a VWO campaign. Use this to discover goal ids.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of items to return.
`offset`	No	Number of items to skip, for paging.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`campaignId`	Yes	VWO campaign id. Call vwo_list_campaigns first if you do not have it.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and openWorldHint. Description adds no extra behavioral context (e.g., about pagination or limits), providing minimal added value beyond annotations.

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?

Single sentence with no fluff. Efficient but could benefit from a bit more context without becoming verbose.

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

Completeness3/5

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

Adequate given complete schema documentation and annotations. Lacks description of return structure, but schema fully covers parameters and annotations indicate read-only and open world.

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

Parameters3/5

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

Schema coverage is 100%, so baseline is 3. Description does not add meaning beyond what the schema already provides for each parameter.

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?

Description clearly states the tool lists goals on a VWO campaign and is used to discover goal IDs. It distinguishes itself from sibling tools like vwo_get_campaign_goal (single goal) and vwo_new_campaign_goal (create).

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

Usage Guidelines4/5

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

Implicitly tells when to use (to discover goal ids). Does not explicitly mention when not to use or alternatives, but sibling tools provide context.

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

vwo_list_campaign_labelsList labels on a VWO campaignA

Read-only

List the labels currently applied to one VWO campaign.

ParametersJSON Schema

Name	Required	Description
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`campaignId`	Yes	VWO campaign id. Call vwo_list_campaigns first if you do not have it.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true, so the read-only nature is clear. The description adds 'currently applied', reinforcing no side effects. No contradictions, and the description provides sufficient transparency given the annotation coverage.

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

Conciseness5/5

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

The description is a single, front-loaded sentence with no wasted words. Every part of it contributes to understanding the tool's purpose.

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

Completeness4/5

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

For a simple read-only list tool with comprehensive schema and annotations, the description is adequate. While it does not specify the return format or error conditions, this is acceptable given the tool's simplicity and the richness of the structured fields.

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

Parameters3/5

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

Schema coverage is 100%, and each parameter is already well-described in the schema. The description does not add additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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 description clearly states the action ('list') and the specific resource ('labels currently applied to one VWO campaign'). It distinguishes this tool from siblings like vwo_list_labels (which likely lists all labels globally) and the add/delete label tools.

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

Usage Guidelines3/5

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

The description implies usage by requiring a campaign ID, but it does not explicitly state when to use this tool versus alternatives like vwo_list_labels for global label listing. No guidance on when not to use it.

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

vwo_list_campaignsList VWO campaignsA

Read-only

List campaigns (experiments) in a VWO workspace. Use this to discover campaign ids before calling any tool that operates on a specific campaign. Filter by type, platform, or label to narrow large accounts.

ParametersJSON Schema

Name	Required	Description
`type`	No	Filter by campaign type. VWO's values are lowercase and hyphenated, not the generic A/B-testing names they resemble: "ab", "split" (Split URL), "multivariate" (not "mvt"), "feature-rollout" (Web Rollout), "feature-test", plus non-testing types like "heatmap", "survey", "recording".
`label`	No	Filter by label name.
`limit`	No	Maximum campaigns to return. VWO caps this endpoint at 25 regardless of what you request, so page through with offset/nextOffset rather than a bigger limit.
`offset`	No	Number of items to skip, for paging.
`status`	No	Filter by campaign status. UPPERCASE only — VWO rejects lowercase with HTTP 400. Omit to get campaigns of every status (which is usually what you want; note that includes DELETED ones, so check each result's own `status` field before reporting a campaign as live). This parameter is absent from VWO's published docs but is real and enforced — the valid values above come from the error message VWO returns for an invalid one.
`platform`	No	Filter by platform: "website", "full-stack", or "mobile-app" (not "WEB"/"FULLSTACK").
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`projectId`	No	Filter by project id.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.
`showDetailedInfo`	No	Return the full campaign objects instead of a summary. Much larger responses.

TDQS

A4.7/5.0

Behavior5/5

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

Discloses API cap at 25, pagination via offset/nextOffset, uppercase-only status parameter, inclusion of deleted campaigns by default, and accountId necessity. All beyond the readOnlyHint and openWorldHint annotations, with no contradictions.

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?

Well-structured with purpose first, then usage, then parameters. All sentences add value, but some parameter descriptions are lengthy; still justified given complexity.

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?

Given 10 parameters, no required ones, no output schema, but annotations cover safety and open world. Description covers usage, pagination, special quirks, and parameter details completely. No missing critical information.

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

Parameters5/5

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

Schema coverage is 100%, but each parameter description adds significant value: explains type value format, status case-sensitivity, limit cap, accountId vs workspaceName usage, and platform values. Provides crucial context not present in 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?

Description clearly states the tool lists campaigns (experiments) in a VWO workspace, specifies it for discovering campaign IDs before using specific campaign tools, and distinguishes from siblings by mentioning filtering capabilities.

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

Usage Guidelines4/5

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

Explicitly recommends using this to discover campaign IDs before specific campaign operations, and advises filtering for large accounts. Implicitly suggests alternatives like get_campaign when IDs are known, but does not explicitly list when not to use.

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

vwo_list_campaign_sectionsList VWO campaign sectionsA

Read-only

List the sections configured on a VWO campaign. Use this to discover section ids.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of items to return.
`offset`	No	Number of items to skip, for paging.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`campaignId`	Yes	VWO campaign id. Call vwo_list_campaigns first if you do not have it.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already provide readOnlyHint=true and openWorldHint=true, covering safety and list dynamism. The description adds no extra behavioral context (e.g., permissions, rate limits, or error handling). It adequately complements annotations without contradiction.

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

Conciseness5/5

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

The description is extremely concise, consisting of two short, front-loaded sentences that directly state the action and purpose, with no unnecessary words or redundancy.

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

Completeness3/5

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

Despite good annotations and schema coverage, the description lacks context about output format, pagination behavior (limit/offset), and what 'sections' are. For a tool with no output schema, more detail would improve completeness. Current is adequate but minimal.

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

Parameters3/5

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

Schema description coverage is 100%; all five parameters have detailed descriptions in the input schema. The tool description does not add parameter-specific meaning beyond what is already documented, so a baseline score of 3 is appropriate.

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 description clearly states the verb 'List' and the resource 'sections configured on a VWO campaign', and provides the specific purpose 'discover section ids', distinguishing it from sibling tools like vwo_list_campaigns or vwo_list_campaign_goals.

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

Usage Guidelines4/5

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

The description gives a clear usage hint ('Use this to discover section ids'), but does not explicitly mention when not to use this tool or alternatives like vwo_get_campaign_section for a single section. The context is clear but lacks exclusions.

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

vwo_list_campaign_variationsList VWO campaign variationsA

Read-only

List the variations configured on a VWO campaign. Use this to discover variation ids.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of items to return.
`offset`	No	Number of items to skip, for paging.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`campaignId`	Yes	VWO campaign id. Call vwo_list_campaigns first if you do not have it.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A3.7/5.0

Behavior3/5

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

Annotations provide readOnlyHint and openWorldHint, so the description only needs to add context beyond those. It mentions 'discover variation ids' which hints at output, but it doesn't describe the return format, pagination behavior, or authentication needs. This is adequate but not rich.

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

Conciseness5/5

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

The description is two sentences, front-loaded with the verb and resource, and contains no unnecessary words. Every sentence adds value.

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

Completeness3/5

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

Given no output schema, the description should explain what the response contains. It only mentions 'variation ids', but the actual output likely includes more fields (e.g., name, weight). This gap makes it incomplete for an agent to fully understand the tool's output.

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

Parameters3/5

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

Schema description coverage is 100%, so the parameter information is fully in the schema. The description adds no additional semantics beyond the schema, so a baseline score of 3 is appropriate.

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 description clearly states the action ('List'), the resource ('variations configured on a VWO campaign'), and the purpose ('discover variation ids'). This distinguishes it from siblings like vwo_get_campaign_variation, which retrieves a single variation.

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

Usage Guidelines3/5

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

The description implies usage for discovering variation ids but does not specify when not to use this tool or mention alternatives among the many variation-related siblings (e.g., new, update, delete). No explicit context is given for choosing this over similar tools.

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

vwo_list_custom_widgetsList VWO custom widgetsA

Read-only

List the custom widgets defined in a VWO workspace, with their ids. Use this to find a widget id before fetching or changing one.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of items to return.
`offset`	No	Number of items to skip, for paging.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4/5.0

Behavior3/5

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

Annotations already provide readOnlyHint=true and openWorldHint=true, so the description's job is reduced. The description adds that the tool returns ids but does not mention pagination behavior (limit/offset exist in schema) or any other operational traits. No contradiction with annotations.

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

Conciseness5/5

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

Two sentences with no wasted words. The first sentence is front-loaded with the tool's purpose, and the second adds a clear use-case hint.

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

Completeness4/5

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

Given full schema documentation and readOnly/openWorld annotations, the description adequately covers the tool's function. It is missing a mention of pagination behavior, but that is minor for a list tool without output schema.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description does not add any additional meaning or context to the parameters beyond what the schema already provides.

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 description states 'List the custom widgets defined in a VWO workspace, with their ids,' which is a specific verb+resource+scope. It clearly distinguishes from siblings like vwo_get_custom_widget (single fetch) and vwo_new_custom_widget (mutation).

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

Usage Guidelines4/5

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

The description explicitly says 'Use this to find a widget id before fetching or changing one,' providing clear when-to-use guidance. It implies when-not-to-use (when id is already known) but does not list alternatives beyond the context.

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

vwo_list_draftsList VWO draft campaignsA

Read-only

List unpublished draft campaigns in a VWO workspace. Drafts are not live and affect no visitors.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of items to return.
`offset`	No	Number of items to skip, for paging.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A3.9/5.0

Behavior3/5

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

The description adds that drafts are non-live and non-impactful, which complements the readOnlyHint annotation. But it does not describe the response format or other behaviors like paging.

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

Conciseness5/5

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

Two sentences with no fluff. Front-loaded with the core action, followed by a clarifying statement.

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

Completeness3/5

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

Given a simple list operation with readOnlyHint and openWorldHint annotations, the description provides basic context. However, it omits output details and paging behavior, which the schema partially covers.

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

Parameters3/5

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

All four parameters have full schema descriptions (100% coverage). The description adds no extra parameter details, so baseline 3 applies.

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 description clearly states the tool lists unpublished draft campaigns, distinguishing it from sibling tools like vwo_list_campaigns (for all campaigns) and vwo_get_draft (for a specific draft).

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

Usage Guidelines4/5

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

The description explains drafts are not live and affect no visitors, implying when to use this tool. However, it does not explicitly exclude usage scenarios or mention alternatives.

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

vwo_list_labelsList VWO labelsA

Read-only

List all labels defined in a VWO workspace, with their ids. Use this to find a label id before applying it to a campaign, or to filter vwo_list_campaigns by label.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of items to return.
`offset`	No	Number of items to skip, for paging.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the description need not restate safety. It adds that labels come with ids, but no behavioral traits beyond what annotations convey. No contradictions.

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

Conciseness5/5

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

Two sentences, front-loaded with the main action. Every word earns its place; no redundancy.

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?

The tool is simple, annotations are present, schema is fully covered. The description, though brief, is complete for the tool's purpose and context.

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

Parameters3/5

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

Schema covers 100% of parameters with descriptions; the description adds no parameter-level info beyond what's in the schema. Baseline score of 3 is appropriate.

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 description clearly states 'List all labels defined in a VWO workspace, with their ids,' which is a specific verb-resource pair. It distinguishes from sibling tools like vwo_list_campaign_labels by mentioning applying to campaigns.

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

Usage Guidelines4/5

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

The description explicitly states when to use this tool: 'find a label id before applying it to a campaign, or to filter vwo_list_campaigns by label.' It provides context but does not list scenarios where it should not be used or compare to all siblings.

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

vwo_list_metric_reportsList VWO metric reportsA

Read-only

List the VWO Insights metric reports configured in a workspace. Use this to find a report id before fetching its details.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of items to return.
`order`	No	Sort order for the results, as accepted by VWO.
`offset`	No	Number of items to skip, for paging.
`status`	No	Filter by report status.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds no additional behavioral context beyond that and does not mention pagination, rate limits, or other traits.

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

Conciseness5/5

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

The description is two sentences long, front-loaded with the core action, and contains zero unnecessary words.

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

Completeness4/5

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

The description effectively conveys the tool's purpose and role in the workflow. However, with no output schema, it could provide more detail about the return format or any limitations, though it remains fairly complete for a list tool.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond what the schema provides, meeting the baseline.

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 description clearly states the tool lists VWO Insights metric reports in a workspace and specifically mentions using it to find a report ID before fetching details, distinguishing it from sibling tools like vwo_get_metric_report.

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

Usage Guidelines4/5

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

The description explicitly says 'Use this to find a report id before fetching its details,' providing clear guidance on when to use it. However, it does not explicitly state when not to use it or mention alternative tools for other scenarios.

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

vwo_list_workspacesList VWO workspacesA

Read-only

List the VWO workspaces (accounts and sub-accounts) this API token can access, with their ids and names. Call this whenever the user refers to a workspace by name and you need its id, or to see what is available. Never guess a workspace id.

ParametersJSON Schema

Name	Required	Description	Default
`status`	No	Filter by workspace status.	all
`includeCurrent`	No	Include the token's own (main) workspace. VWO returns only secondary workspaces when false.

TDQS

A4/5.0

Behavior3/5

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

The description is consistent with the readOnlyHint and openWorldHint annotations, stating that it lists accessible workspaces. It does not add significant behavioral context beyond what the annotations provide, but it also does not contradict them.

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

Conciseness5/5

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

The description is two sentences: the first clearly defines purpose and output, the second provides usage guidelines and a crucial warning. Every sentence adds value, with no wasted words.

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

Completeness4/5

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

For a simple list tool with full schema coverage, the description is nearly complete. It tells what is returned (ids and names) and when to use it. A minor gap is not mentioning that results can be filtered by parameters, but this is mitigated by the schema. Lacks output schema but not essential.

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

Parameters3/5

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

The input schema has 100% coverage with descriptions for both parameters (status, includeCurrent). The description does not add additional semantics for these parameters, so a baseline score of 3 is appropriate.

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 description clearly states the tool's action: listing VWO workspaces accessible by the API token, with ids and names. It also provides specific use cases (resolving workspace names to ids, seeing available workspaces) and a strong negative instruction ('Never guess a workspace id'). This differentiates it from sibling tools like vwo_get_workspace.

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

Usage Guidelines4/5

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

The description explicitly says when to use the tool ('whenever the user refers to a workspace by name and you need its id, or to see what is available') and gives a clear directive to never guess an id. It does not mention alternatives or when not to use it, but the context is sufficient for most scenarios.

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

vwo_new_campaignCreate a VWO campaignA

Create a new campaign (experiment) in a VWO workspace. Creates real state that can affect live traffic once started. Confirm type, URLs, and goals with the user before calling.

ParametersJSON Schema

Name	Required	Description
`name`	No	Campaign name.
`type`	Yes	Campaign type — lowercase, hyphenated. Common values: "ab", "split" (Split URL), "multivariate" (not "mvt"), "feature-rollout" (Web Rollout), "feature-test". Not the generic "AB"/"SPLIT_URL"/"MVT" naming.
`urls`	Yes	URL configuration entries for the campaign, as accepted by VWO.
`goals`	Yes	Goal definitions to create with the campaign.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`primaryUrl`	Yes	Primary URL the campaign runs on.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4.1/5.0

Behavior5/5

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

The description discloses that the tool creates real state affecting live traffic, which adds behavioral context beyond the annotations (readOnlyHint=false, destructiveHint=false). This warning is crucial for safe usage.

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

Conciseness5/5

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

The description is two sentences, concise and front-loaded with the purpose and key behavioral note. No wasted words.

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

Completeness4/5

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

Given the tool has 7 parameters (4 required) and no output schema, the description covers the essential behavioral impact and usage guidance. It could mention response or error handling, but overall it is sufficiently complete.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the importance of confirming type, URLs, and goals, but adds little new meaning beyond what the schema already provides for each parameter.

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

Purpose4/5

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

The description clearly states that the tool creates a new campaign (experiment) in VWO, which is a specific verb+resource. However, it does not explicitly differentiate from siblings like vwo_update_campaign or vwo_new_campaign_goal, though the use of 'new' makes the purpose clear.

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

Usage Guidelines4/5

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

The description advises confirming type, URLs, and goals with the user before calling, providing clear context for when to use. It implies caution due to live traffic impact, but does not mention alternatives or when not to use explicitly.

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

vwo_new_campaign_goalCreate a VWO campaign goalA

Add a new goal to a VWO campaign. Goals define what the experiment measures, so changing them on a running campaign affects reported results and can invalidate conclusions drawn so far.

ParametersJSON Schema

Name	Required	Description
`body`	Yes	Definition of the goal to create. VWO does not publish a schema for this request body; see https://developers.wingify.com/reference/create-a-campaign-goal for the accepted fields. The object is sent to VWO as-is.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`campaignId`	Yes	VWO campaign id. Call vwo_list_campaigns first if you do not have it.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations indicate non-read-only and non-destructive behavior. The description adds beyond this by warning that goals on a running campaign affect reported results and can invalidate conclusions, disclosing side effects.

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

Conciseness5/5

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

Two sentences efficiently convey the main action and an important caveat. No wasted words, and the critical warning is front-loaded.

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

Completeness4/5

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

The description explains the goal's purpose and warns of consequences, but lacks information on the return value (e.g., created goal object). Given no output schema, a brief mention of typical response would improve completeness.

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

Parameters5/5

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

All four parameters are described with schema coverage at 100%. The body parameter points to external docs and explains it's sent as-is. accountId and workspaceName provide usage guidance, and campaignId recommends prior listing.

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?

Description clearly states 'Add a new goal to a VWO campaign,' using a specific verb and resource. It distinguishes from sibling tools like vwo_get_campaign_goal and vwo_delete_campaign_goal by focusing on creation.

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

Usage Guidelines4/5

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

The description warns that changing goals on a running campaign affects results and can invalidate conclusions, providing clear context for cautious use. However, it does not explicitly state when not to use or list alternative tools.

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

vwo_new_campaign_sectionCreate a VWO campaign sectionA

Add a new section to a VWO campaign. Sections determine which page areas the campaign varies, so changes affect what live visitors see and how combinations are reported.

ParametersJSON Schema

Name	Required	Description
`body`	Yes	Definition of the section to create. VWO does not publish a schema for this request body; see https://developers.wingify.com/reference/create-a-campaign-section for the accepted fields. The object is sent to VWO as-is.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`campaignId`	Yes	VWO campaign id. Call vwo_list_campaigns first if you do not have it.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already indicate it's a mutation. The description adds that sections affect live visitors and how combinations are reported, plus the schema note about body being undocumented, adding behavioral context beyond annotations.

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

Conciseness5/5

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

Two sentences with no filler. Front-loads the action and provides meaningful context concisely.

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

Completeness3/5

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

While the description explains the significance of sections, it lacks mention of required dependencies (e.g., campaign must exist) or related tools. It is adequate for a simple create operation but could be more comprehensive.

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

Parameters3/5

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

With 100% schema description coverage, the schema already explains all parameters. The tool description does not add any further parameter details, maintaining a baseline of 3.

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

Purpose4/5

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

The description clearly states the action ('Add a new section to a VWO campaign') and explains the purpose of sections. It distinguishes from CRUD siblings by verb, though not explicitly.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives (e.g., update or delete). No mention of prerequisites or context.

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

vwo_new_campaign_variationCreate a VWO campaign variationA

Add a new variation to a VWO campaign. Variations are what live visitors actually see, so changes take effect on real traffic and alter the data being collected.

ParametersJSON Schema

Name	Required	Description
`body`	Yes	Definition of the variation to create. VWO does not publish a schema for this request body; see https://developers.wingify.com/reference/create-a-campaign-variation for the accepted fields. The object is sent to VWO as-is.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`campaignId`	Yes	VWO campaign id. Call vwo_list_campaigns first if you do not have it.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4.1/5.0

Behavior4/5

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

Beyond annotations (readOnlyHint false, destructiveHint false), the description adds critical context: variations affect real traffic and alter collected data. It honestly states the body is sent as-is. No contradictions.

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

Conciseness5/5

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

Two sentences in the main description efficiently convey purpose and impact. Parameter descriptions are clear and well-structured. No extraneous content.

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

Completeness3/5

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

While the description explains the impact on traffic, it omits return value (e.g., created variation object). No output schema; a brief hint would improve completeness. Adequate but not thorough.

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% with descriptions. The description adds value by clarifying body as sent as-is, cautioning against guessing ids, and explaining workspaceName vs accountId fallback.

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 description clearly states 'Add a new variation to a VWO campaign' with a specific verb and resource. It explains what variations are (live visitors see them) and distinguishes this from update/delete/list siblings.

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

Usage Guidelines3/5

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

The description implies when to use (adding a variation) but does not explicitly say when not to use or mention alternatives like vwo_update_campaign_variation. No exclusionary guidance.

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

vwo_new_custom_widgetCreate a VWO custom widgetC

Create a new custom widget in a VWO workspace.

ParametersJSON Schema

Name	Required	Description
`body`	Yes	Definition of the custom widget to create. VWO does not publish a schema for this request body; see https://developers.wingify.com/reference/create-a-custom-widget for the accepted fields. The object is sent to VWO as-is.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

C2.9/5.0

Behavior2/5

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

Annotations indicate mutation (readOnlyHint=false) but non-destructive (destructiveHint=false). The description adds no behavioral context beyond 'Create a new custom widget'—no mention of side effects, authentication requirements, or rate limits. The openWorldHint=true suggests unknown behaviors, but the description does not clarify.

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 description is a single, clear sentence that efficiently conveys the core purpose. It is not verbose, though it could be slightly expanded without loss of conciseness.

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

Completeness2/5

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

The tool has a nested object parameter and no output schema. The description fails to explain what the response looks like, how to structure the body (beyond a link), or how errors are handled. Given the complexity, more context is needed.

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

Parameters3/5

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

Schema coverage is 100%, and the schema already provides detailed parameter descriptions (e.g., body with link, accountId with exclusions). The tool description adds no extra meaning beyond what the schema offers, so a baseline score of 3 is appropriate.

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

Purpose4/5

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

The title and description clearly state the verb 'Create' and the resource 'custom widget', making it easy to identify the tool's purpose. However, the description does not differentiate from the sibling vwo_create_custom_widgets (batch), which could cause confusion.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like vwo_list_custom_widgets or vwo_create_custom_widgets. There is no mention of prerequisites or context, leaving the agent to infer usage.

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

vwo_new_workspaceCreate a VWO workspaceA

Create a new VWO workspace (sub-account) under the authenticated account. Creates real, potentially billable state — confirm the name with the user first.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Name for the new workspace.

TDQS

A4.4/5.0

Behavior5/5

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

The description adds critical behavioral context beyond annotations: 'Creates real, potentially billable state'. Annotations already indicate write operation (readOnlyHint=false) and non-destructive nature, but billing info is an essential safety warning.

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

Conciseness5/5

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

Two sentences, no redundant information. First sentence states purpose, second adds behavioral warning and usage guideline. Efficient and front-loaded.

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

Completeness4/5

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

For a simple tool with one parameter and no output schema, the description covers purpose, behavioral trait, and a usage guideline. Could mention expect response or error handling, but not essential given simplicity.

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

Parameters3/5

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

Schema covers the single parameter 'name' fully (100% coverage). Description does not add additional semantics about the parameter, only a usage note. Baseline score of 3 is appropriate.

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 description clearly states the verb 'create', resource 'workspace (sub-account)', and context 'under the authenticated account'. It explicitly warns about billable state, distinguishing it from sibling tools like vwo_get_workspace or vwo_update_workspace.

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

Usage Guidelines4/5

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

Provides clear guidance to confirm the name with the user first, implying appropriate use when creating a workspace. Lacks explicit exclusion of when not to use, but context is clear given the creation action.

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

vwo_update_campaignUpdate a VWO campaignA

Destructive

Update the configuration of an existing campaign. Changes can affect a live experiment and its collected data. Pass only the fields you intend to change.

ParametersJSON Schema

Name	Required	Description
`body`	Yes	Fields to change on the campaign. VWO expects these wrapped in a `campaigns` object; this tool adds that wrapper for you, so pass the fields directly. VWO does not publish a schema for this request body; see https://developers.wingify.com/reference/update-a-campaign for the accepted fields. The object is sent to VWO as-is.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`campaignId`	Yes	VWO campaign id. Call vwo_list_campaigns first if you do not have it.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4.5/5.0

Behavior4/5

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

The description adds behavioral context beyond annotations by noting that 'Changes can affect a live experiment and its collected data,' aligning with the destructiveHint annotation. It also implies a partial-update behavior. No contradiction with annotations.

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

Conciseness5/5

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

The description is exceptionally concise: two sentences covering purpose, warning, and usage tip. No redundant or missing information. Every sentence earns its place.

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

Completeness4/5

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

Given the complexity (4 parameters, nested body, no output schema), the description covers key aspects: required fields, partial updates, and risk to live data. It could mention restrictions on field updates or prerequisites (e.g., campaign must exist), but overall it is sufficient for an agent.

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

Parameters5/5

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

Despite 100% schema coverage, the description significantly enriches parameter understanding. For 'body,' it explains the wrapper behavior and directs to external docs. For 'accountId' and 'workspaceName,' it clarifies usage and alternatives (e.g., never guess an id). This goes well beyond the schema's baseline.

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 description clearly states the action: 'Update the configuration of an existing campaign.' It uses a specific verb ('Update') and resource ('existing campaign'), and distinguishes from sibling tools like vwo_update_campaign_status or vwo_update_draft_campaigns by focusing on configuration changes. The warning about affecting live experiments further clarifies scope.

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

Usage Guidelines4/5

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

The description advises to 'Pass only the fields you intend to change,' which is a useful usage tip. However, it does not explicitly specify when to use this tool versus alternatives (e.g., vwo_update_campaign_status). The sibling tool names partially differentiate, but explicit guidance would improve clarity.

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

vwo_update_campaign_goalUpdate a VWO campaign goalA

Destructive

Change an existing goal on a VWO campaign. Goals define what the experiment measures, so changing them on a running campaign affects reported results and can invalidate conclusions drawn so far.

ParametersJSON Schema

Name	Required	Description
`body`	Yes	Fields to change on the goal. VWO does not publish a schema for this request body; see https://developers.wingify.com/reference/update-a-campaign-goal for the accepted fields. The object is sent to VWO as-is.
`goalId`	Yes	VWO goal id. Call vwo_list_campaign_goals first if you do not have it.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`campaignId`	Yes	VWO campaign id. Call vwo_list_campaigns first if you do not have it.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate destructiveHint=true. The description adds context by explaining that changing goals affects reported results and can invalidate conclusions, which goes beyond the annotation alone.

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

Conciseness5/5

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

The description is two sentences, front-loading the purpose and adding a critical behavioral warning. Every word earns its place.

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

Completeness3/5

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

The description covers the mutation's impact but does not describe the return value or response format. Given no output schema, this omission leaves the agent uncertain about what to expect after a successful update.

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 baseline is 3. However, the description adds value for the 'body' parameter by noting that VWO does not publish a schema and the object is sent as-is, and provides guidance for accountId vs workspaceName. This extra context justifies a higher score.

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 description clearly states the action ('Change an existing goal on a VWO campaign') and specifies the resource ('an existing goal on a VWO campaign'). It distinguishes from sibling tools like vwo_new_campaign_goal and vwo_delete_campaign_goal.

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

Usage Guidelines4/5

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

The description explains the impact of changing a goal on a running campaign, which guides when to use caution. However, it does not explicitly compare to alternatives like vwo_new_campaign_goal or explain when updating vs creating is appropriate.

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

vwo_update_campaign_sectionUpdate a VWO campaign sectionA

Destructive

Change an existing section on a VWO campaign. Sections determine which page areas the campaign varies, so changes affect what live visitors see and how combinations are reported.

ParametersJSON Schema

Name	Required	Description
`body`	Yes	Fields to change on the section. VWO does not publish a schema for this request body; see https://developers.wingify.com/reference/update-a-campaign-section for the accepted fields. The object is sent to VWO as-is.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`sectionId`	Yes	VWO section id. Call vwo_list_campaign_sections first if you do not have it.
`campaignId`	Yes	VWO campaign id. Call vwo_list_campaigns first if you do not have it.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already indicate destructiveHint=true and openWorldHint=true. The description adds meaningful context by stating changes 'affect what live visitors see and how combinations are reported', which goes beyond what annotations provide. However, it does not detail specific side effects (e.g., whether changes are immediately applied or require review).

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

Conciseness5/5

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

The description is two sentences (27 words), front-loaded with the core action, and contains no unnecessary words or repetition. It efficiently conveys the purpose and impact.

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

Completeness3/5

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

Given the tool's complexity (5 parameters, nested body object, no output schema), the description provides a high-level effect but lacks details on return values or guidance on parameter usage beyond what the schema already covers. It is adequate but could be more complete.

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

Parameters3/5

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

The input schema has 100% coverage with descriptions for all 5 parameters, so the description's role is minimal. The description does not add meaning beyond the schema, such as clarifying the body parameter's flexibility. Baseline 3 is appropriate.

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 description explicitly states 'Change an existing section on a VWO campaign' and explains that sections determine page areas for variations, clearly distinguishing it from create/delete sibling tools like vwo_new_campaign_section and vwo_delete_campaign_section.

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

Usage Guidelines3/5

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

The description implies use for modifying existing sections but does not explicitly state when to use this tool versus alternatives (e.g., vwo_new_campaign_section to create, vwo_delete_campaign_section to remove). No exclusions or context for when not to use it.

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

vwo_update_campaign_statusUpdate VWO campaign statusA

Destructive

Start, pause, or stop campaigns. This directly changes what live visitors see and can end data collection — always confirm the campaign and target status with the user first. Note this is a bulk endpoint: VWO takes the campaign ids in the body.

ParametersJSON Schema

Name	Required	Description
`body`	Yes	Status change payload, typically the campaign id(s) and the desired status (for example RUNNING, PAUSED, or STOPPED). VWO does not publish a schema for this request body; see https://developers.wingify.com/reference/update-a-campaign-1 for the accepted fields. The object is sent to VWO as-is.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations indicate destructiveHint=true, and the description adds context by stating it 'directly changes what live visitors see and can end data collection,' which aligns with and expands on the destructive nature. No contradictions with annotations.

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

Conciseness5/5

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

The description is two short, front-loaded sentences. Every sentence adds value: the first states the core action and impact, the second provides usage context on bulk endpoint behavior.

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

Completeness4/5

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

Given the destructive nature, the description adequately covers the effect on live visitors and data collection. No output schema exists, but for a mutation tool this is acceptable. The description is complete enough for an agent to decide usage.

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

Parameters3/5

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

Schema coverage is 100% and the description does not add significant details beyond the schema. It mentions 'VWO takes the campaign ids in the body,' which is a minor addition, but the schema already describes the body as opaque. Baseline 3 is appropriate.

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 description starts with 'Start, pause, or stop campaigns,' which is a specific verb-resource combination clearly indicating the tool's action on campaigns. This distinguishes it from sibling tools like vwo_update_campaign or vwo_new_campaign.

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

Usage Guidelines4/5

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

The description explicitly advises confirming campaign and target status with the user before use, providing a clear when-to context. It also notes the bulk endpoint behavior, though it does not explicitly list alternatives for when not to use.

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

vwo_update_campaign_variationUpdate a VWO campaign variationA

Destructive

Change an existing variation on a VWO campaign. Variations are what live visitors actually see, so changes take effect on real traffic and alter the data being collected.

ParametersJSON Schema

Name	Required	Description
`body`	Yes	Fields to change on the variation. VWO does not publish a schema for this request body; see https://developers.wingify.com/reference/update-a-campaign-variation for the accepted fields. The object is sent to VWO as-is.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`campaignId`	Yes	VWO campaign id. Call vwo_list_campaigns first if you do not have it.
`variationId`	Yes	VWO variation id. Call vwo_list_campaign_variations first if you do not have it.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already indicate write (readOnlyHint: false) and destructive (destructiveHint: true) behavior. The description adds value by explaining that changes take effect on real traffic and alter collected data, which goes beyond the annotations. No contradictions found.

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

Conciseness5/5

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

Two succinct sentences that front-load the purpose and immediately convey the impact on live traffic. Every sentence earns its place without unnecessary detail.

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

Completeness4/5

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

Given the tool's complexity (5 parameters, nested body, no output schema), the description covers purpose, behavioral impact, and essential parameter guidance. It could optionally mention return value expectations, but since no output schema exists, this is acceptable. Almost complete.

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

Parameters5/5

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

With 100% schema coverage, the baseline is 3. The description adds significant meaning: it explains the body parameter's undocumented nature and provides a link, warns against guessing accountId, and advises listing endpoints for campaignId and variationId. This far exceeds schema-only information.

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 description clearly states the verb 'Change' and the resource 'existing variation on a VWO campaign'. It distinguishes from sibling tools like vwo_new_campaign_variation (create) and vwo_delete_campaign_variation (delete) by implying this is the update operation.

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

Usage Guidelines4/5

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

The description provides clear context by noting that changes affect live visitors and real traffic, implying caution. However, it does not explicitly state when not to use this tool or provide alternatives like creating vs. deleting variations, though the sibling tools list makes this implicit.

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

vwo_update_custom_widgetUpdate a VWO custom widgetA

Destructive

Change an existing custom widget. Widgets can be linked to live campaigns, so edits may affect what visitors see.

ParametersJSON Schema

Name	Required	Description
`body`	Yes	Fields to change on the custom widget. VWO does not publish a schema for this request body; see https://developers.wingify.com/reference/update-a-custom-widget for the accepted fields. The object is sent to VWO as-is.
`widgetId`	Yes	Custom widget (changeset) id. Call vwo_list_custom_widgets if you do not have it.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already indicate destructiveHint=true. The description adds valuable context that edits may affect visitor experience, going beyond the annotation. No contradiction.

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

Conciseness5/5

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

Two sentences, front-loaded with purpose, no filler. Every sentence adds value.

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

Completeness4/5

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

Given no output schema, the description covers the core function, side effects, and parameter guidance. Referencing external docs compensates for the body schema absence. Adequate for a mutation tool.

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

Parameters5/5

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

All 4 parameters have descriptions in the schema (100% coverage). The description adds references to external docs for the body, and provides cross-tool guidance for widgetId and accountId/workspaceName, greatly aiding parameter understanding.

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 description clearly states 'Change an existing custom widget,' specifying the verb and resource. The warning about live campaigns distinguishes it from creation or deletion tools.

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

Usage Guidelines4/5

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

The description implies use for modifying existing widgets, but does not explicitly compare to siblings like vwo_new_custom_widget or vwo_delete_custom_widget. The live campaign warning provides context for when to be cautious.

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

vwo_update_custom_widgetsUpdate VWO custom widgets in bulkA

Destructive

Change several custom widgets in one request. Widgets can be linked to live campaigns, so edits may affect what visitors see. CAUTION: the endpoint for this operation is inferred, not confirmed — VWO's docs page for it points at an unrelated attribute-list endpoint. Verify the result of the first call before relying on it, and report back if it fails.

ParametersJSON Schema

Name	Required	Description
`body`	Yes	Bulk payload describing the widget changes. VWO does not publish a schema for this request body; see https://developers.wingify.com/reference/update-bulk-custom-widgets for the accepted fields. The object is sent to VWO as-is.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4.5/5.0

Behavior5/5

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

The description discloses important behavioral traits beyond annotations: widgets may be linked to live campaigns so edits can affect visitors, and the endpoint is inferred and unconfirmed. This adds significant context that annotations (destructiveHint=true, openWorldHint=true) do not fully capture, helping the agent understand risks.

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 description is concise with two sentences plus a caution. It is well-structured and front-loaded with purpose. However, the caution is somewhat lengthy and could be more succinct.

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

Completeness4/5

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

Given the tool's complexity (bulk update, live campaigns, inferred endpoint, no output schema), the description appropriately covers key risks and usage caveats. It lacks information about return values or error handling, but that is partially excused by missing output schema.

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%, and the description adds meaning for the body parameter (explaining it's a bulk payload with unclear schema and pointing to external docs) and for accountId/workspaceName (not to guess id). This adds value beyond the schema descriptions, though the schema already provides good baseline.

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 title and description clearly state the tool's purpose: 'Update VWO custom widgets in bulk' and 'Change several custom widgets in one request.' This distinguishes it from sibling tools like vwo_update_custom_widget (single) and vwo_create_custom_widgets (create).

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

Usage Guidelines4/5

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

The description provides context about potential impact on live campaigns and advises caution, including verifying the first call due to an inferred endpoint. It does not explicitly state when not to use this tool or list alternatives, but the caution and bulk nature imply appropriate usage.

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

vwo_update_draft_campaignsUpdate a VWO draft campaignA

Destructive

Update a draft campaign's configuration. Drafts are not live, so this does not affect visitors, but it does overwrite the saved draft.

ParametersJSON Schema

Name	Required	Description
`body`	Yes	Fields to change on the draft campaign. VWO does not publish a schema for this request body; see https://developers.wingify.com/reference/update-draft-of-current--sub-account for the accepted fields. The object is sent to VWO as-is.
`draftId`	Yes	VWO draft campaign id. Call vwo_list_drafts if you do not have it.
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds that overwriting a draft does not affect visitors, which is useful safety context. Still, it omits other behavioral details like required permissions, reversibility, or side effects, so it only moderately supplements the annotations.

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

Conciseness5/5

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

The description is two concise sentences with no redundancy. It front-loads the core action and provides a clarifying safety note, making every word earn its place.

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

Completeness4/5

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

Given the tool's moderate complexity (4 params, 1 nested object) and lack of output schema, the description adequately covers core behavior and safety. It does not explain return values or error scenarios, but that is not essential for an update tool with comprehensive schema descriptions.

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

Parameters3/5

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

Schema coverage is 100% with detailed descriptions (e.g., body links to external docs, draftId references vwo_list_drafts, accountId/workspaceName handling). The tool description adds no new parameter information beyond the schema. At high coverage, baseline 3 is appropriate.

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 description explicitly states 'Update a draft campaign's configuration,' using a specific verb and resource. It distinguishes from siblings like vwo_update_campaign (for live campaigns) and vwo_delete_draft_campaigns, making the tool's unique purpose clear.

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

Usage Guidelines4/5

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

The description clarifies drafts are not live and 'does not affect visitors,' implying safe use for draft-only updates. The schema guidance to call vwo_list_drafts for the draft ID provides implicit context. However, it lacks explicit comparisons to other update tools (e.g., vwo_update_campaign) or when not to use it.

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

vwo_update_workspaceUpdate a VWO workspaceA

Destructive

Update a VWO workspace's name, timezone, company details, or enabled state. Only the fields you pass are changed. Disabling a workspace stops its campaigns.

ParametersJSON Schema

Name	Required	Description
`name`	No	New workspace name.
`company`	No	Company metadata for the workspace.
`enabled`	No	Whether the workspace is enabled.
`timezone`	No	Timezone string, e.g. "Asia/Kolkata".
`accountId`	No	Numeric VWO workspace (account) id to operate on. Required unless the server has a default workspace configured. If the user referred to a workspace by name, either pass workspaceName instead or call vwo_list_workspaces to look up the id — never guess an id.
`workspaceName`	No	Workspace name to resolve to an id, as an alternative to accountId. Must match exactly one visible workspace, otherwise an error lists the candidates.

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already indicate mutability (readOnlyHint=false) and destructiveness (destructiveHint=true). The description adds value by specifying that disabling a workspace stops its campaigns, which is a critical behavioral trait. No contradiction with annotations.

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

Conciseness5/5

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

The description is three concise sentences, front-loading the core action and progressively adding behavioral detail. Every sentence serves a purpose with no wasted words.

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

Completeness3/5

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

The description covers the essential behavior and key side effect (disabling stops campaigns), but given the complexity (6 params, nested objects, no output schema), it lacks guidance on prerequisites (e.g., needing a workspace ID) and potential consequences beyond disabling. Adequate but with gaps.

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

Parameters3/5

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

Schema coverage is 100%, so parameter descriptions are already provided. The tool description adds only a general note on partial updates. It does not enhance understanding of complex parameters like the nested 'company' object beyond what the schema offers. Baseline 3 is appropriate.

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 description clearly states the verb ('Update') and resource ('a VWO workspace'), and specifies the updatable fields (name, timezone, company details, enabled state). It distinguishes from siblings like vwo_new_workspace (create) and vwo_list_workspaces (list) by focusing on mutation of an existing workspace.

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

Usage Guidelines3/5

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

The description implies usage for updating an existing workspace, and notes partial update behavior ('Only the fields you pass are changed'). However, it does not explicitly state when to choose this tool over alternatives (e.g., vwo_new_workspace for creation) or provide exclusion guidance. The destructive hint is mentioned via disabling but without explicit alternatives.

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

vwo_verify_connectionVerify VWO connectionA

Read-only

Check that the VWO MCP server is correctly configured and its API token works, by making one lightweight authenticated request. Returns the base URL, token source, and a token fingerprint — never the token itself. Call this first when other VWO tools return authorization errors.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.9/5.0

Behavior5/5

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

The description adds value beyond annotations: it specifies that it makes one lightweight authenticated request, returns specific fields (base URL, token source, token fingerprint), and states it never returns the token itself. No contradictions with annotations.

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

Conciseness5/5

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

The description is two sentences, both front-loaded with the verb 'Check'. It contains no redundant words and efficiently conveys purpose, behavior, output, and usage tip.

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?

Given no parameters and no output schema, the description fully covers what the tool does, what it returns, and when to use it. It is complete for a simple diagnostic tool.

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?

The input schema has no parameters, so the description cannot add parameter detail. However, it does describe the output, which aids understanding. Baseline for 0 params is 4.

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 description clearly states the tool's purpose: checking VWO MCP server configuration and API token validity. It uses specific verbs like 'check' and 'verify' and distinguishes itself from sibling tools by being a diagnostic tool, not a data operation tool.

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 description explicitly instructs to call this tool first when other VWO tools return authorization errors, providing clear contextual guidance. It implies usage for debugging connections.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

45 tool updatesv0.1.0Jul 28, 2026
- First observedvwo_add_campaign_label
- First observedvwo_create_custom_widgets
- First observedvwo_delete_campaign_goal
- First observedvwo_delete_campaign_label
- First observedvwo_delete_campaign_section
- First observedvwo_delete_campaign_variation
- First observedvwo_delete_custom_widget
- First observedvwo_delete_draft_campaigns
- First observedvwo_get_campaign
- First observedvwo_get_campaign_goal
- First observedvwo_get_campaign_section
- First observedvwo_get_campaign_share_link
- First observedvwo_get_campaign_variation
- First observedvwo_get_custom_widget
- First observedvwo_get_draft
- First observedvwo_get_metric_report
- First observedvwo_get_smartcode
- First observedvwo_get_workspace
- First observedvwo_get_workspace_history
- First observedvwo_list_campaign_goals
- First observedvwo_list_campaign_labels
- First observedvwo_list_campaign_sections
- First observedvwo_list_campaign_variations
- First observedvwo_list_campaigns
- First observedvwo_list_custom_widgets
- First observedvwo_list_drafts
- First observedvwo_list_labels
- First observedvwo_list_metric_reports
- First observedvwo_list_workspaces
- First observedvwo_new_campaign
- First observedvwo_new_campaign_goal
- First observedvwo_new_campaign_section
- First observedvwo_new_campaign_variation
- First observedvwo_new_custom_widget
- First observedvwo_new_workspace
- First observedvwo_update_campaign
- First observedvwo_update_campaign_goal
- First observedvwo_update_campaign_section
- First observedvwo_update_campaign_status
- First observedvwo_update_campaign_variation
- First observedvwo_update_custom_widget
- First observedvwo_update_custom_widgets
- First observedvwo_update_draft_campaigns
- First observedvwo_update_workspace
- First observedvwo_verify_connection

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a unique combination of resource (workspace, campaign, goal, variation, etc.) and action (list, get, new, update, delete), with no apparent overlap. Even similar tools like vwo_list_campaigns and vwo_list_drafts are clearly distinguished by their descriptions.

Naming Consistency4/5

All tools follow a consistent 'vwo_verb_noun' pattern (e.g., vwo_list_workspaces, vwo_get_campaign). Minor deviation: batch creation uses 'create' instead of 'new' (vwo_create_custom_widgets vs vwo_new_custom_widget), but still highly predictable.

Tool Count3/5

45 tools is on the high side, but the VWO platform has many resources (workspaces, campaigns, drafts, goals, variations, sections, labels, custom widgets, metric reports, smartcode) each needing CRUD operations. The count is justified, though slightly heavy for typical MCP servers.

Completeness4/5

The tool set covers most lifecycle operations for workspaces, campaigns, drafts, goals, variations, sections, labels, and custom widgets. Notable missing features include deleting live campaigns (only drafts can be deleted) and campaign result reports beyond metric reports, but core management is well-covered.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2

Related MCP Servers

agentforge
Agent Orchestration AI & Machine Learning
doggychip
F
license
A
quality
F
maintenance
MCP server that exposes 300+ AI agents as tools via a single API key. Supports listing agents, invoking any agent with chat-completion style messages, checking agent health, and retrieving platform statistics.
Updated 5 months ago (2026-04-21 17:13 UTC)
5
3
-
VoIPbin MCP Serverofficial
Communication Email
voipbin
A
license
B
quality
C
maintenance
An MCP server that enables AI assistants to interact with the VoIPbin CPaaS platform, exposing tools for managing calls, flows, messaging, conferencing, and more.
Updated 5 months ago (2026-04-06 18:03 UTC)
52
1
MIT
mcp-meta-marketing
Marketing Social Media
pauloFroes
F
license
A
quality
D
maintenance
MCP server that wraps the Meta Marketing API (Graph API v25.0) as semantic tools for LLM agents.
Updated 5 months ago (2026-03-29 13:36 UTC)
18
1
-
Adobe Target MCP
Marketing Developer Tools
scottehastings16
A
license
B
quality
D
maintenance
An unofficial MCP server that enables natural language management of Adobe Target activities, offers, audiences, response tokens, and reporting through 33 integration tools.
Updated 9 months ago (2025-12-05 14:29 UTC)
32
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nextafter-michael/unofficial-vwo-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

unofficial-vwo-mcp-server

Tools

Where the docs and the live API disagree

Collection response shapes are not consistent

Two more undocumented /campaigns behaviors

Campaign-resource writes need a plural wrapper

Variation changes: write changes, read editorData

A newly created campaign is not a valid test yet

Deleting a campaign

Request bodies

Account listing must pass includeCurrent

Prompts

Prompts: what they are and their limits

Verifying a change in a browser

Quick start

Configuring the API token

Option A — .mcp.json in the consuming project, with variable expansion (recommended)

Option A2 — .claude/settings.local.json to supply the variable

Option B — a token file (better isolation)

Option C — reading from an OS keychain at spawn time

Option D — .env for local development only

Why the token is not a tool parameter

If you later expose this over HTTP instead of stdio

All configuration

Which tools auto-run and which need approval

Running alongside other MCP servers

Choosing which VWO account a tool acts on

So does the LLM ask, or look it up?

Pick the setup that matches your usage

API version safety

Project layout

Adding a tool

Design notes

SDK version pinning

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

VoIPbin MCP Serverofficial

Latest Blog Posts

MCP directory API

Two more undocumented `/campaigns` behaviors

Variation changes: write `changes`, read `editorData`

Account listing must pass `includeCurrent`

Option A — `.mcp.json` in the consuming project, with variable expansion (recommended)

Option A2 — `.claude/settings.local.json` to supply the variable

Option D — `.env` for local development only