SplitLaunch

goals_create

Create or reactivate a conversion goal and return the goal record. Browser pixel events with the same eventName count as conversions; monetary value is stored only on plans with revenue tracking.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Human-readable goal name, e.g. Lead or Purchase.
`value`	No	Optional default monetary value. Ignored when the plan does not include revenue tracking.
`eventName`	Yes	Exact event name the browser pixel will fire.
`projectId`	No	Optional project ID. Omit only when the API key is project-scoped or the account has a clear default project.

TDQS

A4.1/5.0

Behavior4/5

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

Annotations are minimal, so the description adds value by explaining that monetary value is ignored without revenue tracking and that browser pixel events count as conversions. This goes beyond the boolean flags. However, it doesn't detail what 'reactivate' entails or potential 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.

Conciseness4/5

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

The description is two sentences, front-loading the core action. It is concise and contains no fluff, though it could be slightly more structured (e.g., separate lines for each 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 no output schema, it states the return value ('return the goal record'). It covers key behaviors (creation, reactivation, value handling). Missing details: what happens if goal already exists, permission requirements, rate limits. Still, adequate for a simple creation 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?

Input schema covers all parameters with descriptions (100% coverage). The description adds context for the 'value' parameter (ignored without revenue tracking) and clarifies that 'eventName' is exact. This adds 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 clearly states the tool creates or reactivates a conversion goal, specifying the verb and resource. It distinguishes from siblings like goals_deactivate and goals_list by focusing on creation/reactivation.

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 provides context about browser pixel events and revenue tracking but does not explicitly state when to use this tool vs alternatives like goals_deactivate or goals_list. No explicit usage or non-usage guidance is given.

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

All SplitLaunch tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct resource and action combination (e.g., domains_add, experiments_create, goals_deactivate, reports_experiment_chart). There is no overlap or ambiguity; even the three report tools serve clearly different purposes (totals, time-series, channel breakdown).

Naming Consistency4/5

The vast majority of tools follow a resource_action snake_case pattern (domains_add, experiments_list). A couple deviate (billing_portal, usage_summary) but still place the resource first, making the pattern predictable and easy to parse.

Tool Count5/5

With 23 tools covering projects, domains, experiments, goals, reports, billing, health, and usage, the count is well-scoped for a split-testing platform. Each tool addresses a specific need without ballooning into excessive granularity.

Completeness4/5

The tool surface provides CRUD-like operations for core entities (projects, experiments, goals, domains) and essential report types. Minor gaps exist (no goal update tool, no experiment delete—only archive) but these are reasonable trade-offs for the domain.

Resources

Need Help?