MCP server for agent-run URL A/B testing. Create projects, allowlist domains, launch URL experiments, track conversions, and retrieve performance reports for customer-owned sites.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4/5 across 22 of 23 tools scored. Lowest: 3.2/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).
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.
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.
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.
billing_portalAInspectCreate a billing portal link for subscription management. Use only after the user asks to manage billing.
| Name | Required | Description | Default |
|---|---|---|---|
| returnUrl | No | Optional return URL accepted by the public API contract. SplitLaunch may use the dashboard billing return path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and readOnly hints. Description adds little behavioral context beyond 'Create,' but does not contradict annotations. The parameter description mentions potential SplitLaunch usage, adding minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy: first states purpose, second provides usage guideline. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with one optional parameter and no output schema. Description and schema together fully cover purpose, usage, and parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so description's param info adds no value over schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create a billing portal link for subscription management,' specifying the action and resource. Distinct from sibling tools which cover domains, experiments, projects, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use only after the user asks to manage billing,' providing clear when-to-use guidance. Does not list alternatives, but sibling tools are unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
domains_addAInspectAllowlist a customer-owned hostname so SplitLaunch pixel and redirect experiments can run safely on that domain.
| Name | Required | Description | Default |
|---|---|---|---|
| hostname | Yes | Hostname only, e.g. example.com, not a full URL. | |
| projectId | No | Optional project ID. Omit only when the API key is project-scoped or the account has a clear default project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by explaining the safety reason for allowlisting, but does not disclose behavioral traits such as whether the operation is idempotent or if there are side effects beyond adding the domain. Annotations already indicate non-readOnly and non-destructive, so description adds moderate value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and resource. Every word earns its place, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains the tool's function for its complexity level, but could be improved by mentioning expected outcomes (e.g., confirmation of add) given that no output schema is provided. Still, it covers the core purpose well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters well-described. The tool description does not add additional parameter semantics beyond what the schema provides, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Allowlist' and clearly identifies the resource (customer-owned hostname) and the purpose (to run SplitLaunch pixel and redirect experiments safely). It effectively distinguishes this tool from its siblings (domains_list, domains_remove) by indicating the action of adding a domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when needing to allowlist a domain for experiments), but does not explicitly state when not to use it or mention alternatives like domains_list or domains_remove. Guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
domains_listAList customer-owned domains allowlisted for pixel and redirect safety on a SplitLaunch project.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | No | Optional project ID. Omit only when the API key is project-scoped or the account has a clear default project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already confirm the tool is read-only and idempotent. The description adds no extra behavioral details beyond the basic listing behavior, so its contribution is minimal but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words, directly conveys the tool's function. It is optimally concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple with one optional parameter, the description omits return value details and potential pagination. Given the absence of an output schema, slightly more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with a description for projectId. The tool description does not reference the parameter or add any semantics beyond the schema, maintaining a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 resource (customer-owned domains allowlisted for pixel and redirect safety on a SplitLaunch project). It effectively distinguishes from sibling tools like domains_add and domains_remove by specifying the listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description simply states what it does without instructing on appropriate contexts or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
domains_removeARemove a customer-owned hostname from the project whitelist and return the removed domain record. Future pixel loads and redirects from that hostname are rejected.
| Name | Required | Description | Default |
|---|---|---|---|
| hostname | Yes | Hostname only, e.g. example.com, not a full URL. | |
| projectId | No | Optional project ID. Omit only when the API key is project-scoped or the account has a clear default project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive (destructiveHint=true). The description adds value by stating that the removed domain record is returned and that future pixel loads and redirects are rejected, providing context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, with no extraneous words. The structure is logical: state the action and return value, then the consequence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema) and the presence of annotations covering destructiveness, the description is fairly complete. It could mention irreversibility, but that is implied by destructiveHint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 both parameters. The description does not add significant new meaning beyond what the parameter descriptions provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'remove', the resource 'customer-owned hostname from the project whitelist', and the consequence (future requests rejected). It effectively distinguishes from sibling tools like domains_add and domains_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use (when removing a domain) but does not provide explicit guidance on when not to use or alternatives. The context from sibling tools provides differentiation, but no exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
experiments_archiveAArchive an experiment by ending it and returning the updated experiment. Historical exposures, conversion events, and reports remain available.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | No | Optional project ID. Omit only when the API key is project-scoped or the account has a clear default project. | |
| experimentId | Yes | Experiment ID returned by experiments_create or experiments_list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the experiment is ended and returns the updated experiment, and that historical data persists, adding context beyond the destructiveHint annotation. However, it does not specify permissions or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words; front-loaded with the main action and return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two simple parameters and no output schema, the description adequately covers the operation, though the return value structure could be elaborated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no new parameter information; baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Archive an experiment by ending it') and the resource ('experiment'), and clarifies that historical data remains available, distinguishing it from other experiment tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finalizing an experiment while preserving data, but does not explicitly contrast with alternatives like experiments_set_status 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.
experiments_createAInspectCreate a draft external URL A/B test and return the created experiment. Use controlUrl and variationUrl for the two destinations, trafficAllocation for the variation share, targeting for optional filters, and experiments_set_status after user approval to launch.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| projectId | No | Optional project ID. Omit only when the API key is project-scoped or the account has a clear default project. | |
| targeting | No | Optional targeting object. Device and visitor targeting are available on all plans; trafficFilters and geoFilters require Plus or Pro. Use documented pixel metadata keys such as utm_source, utm_medium, utm_campaign, device, browser, or geo fields. | |
| controlUrl | Yes | Existing customer-owned URL for the control experience. | |
| variationUrl | Yes | Existing customer-owned URL for the variation experience. | |
| urlPatternRules | No | Optional Pro-only URL pattern rules for advanced matching across multiple paths. Prefer simple controlUrl/variationUrl first. | |
| trafficAllocation | No | Traffic sent to the variation. Accepts 0-1 or 0-100; default is 50%. | |
| preserveRedirectParams | No | Default: true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the experiment is created as a draft and that a separate call to set_status is needed to launch. Annotations already indicate a non-read-only, non-destructive operation. The description adds the draft lifecycle context but omits details on authorization requirements or side effects beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose and key parameters without unnecessary words. It is well-structured for quick comprehension, though slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, nested objects, and no output schema, the description provides minimal guidance on the return value (only 'return the created experiment'). It lacks details on error cases, authentication, or what fields the returned experiment contains, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (88%), and the description mostly paraphrases the schema (e.g., 'use controlUrl and variationUrl for the two destinations'). It does not add significant new meaning beyond what the schema already provides, so the baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a draft external URL A/B test and returns the experiment. It specifies the resource ('experiment') and the action ('create'), and distinguishes from sibling tools like experiments_update or experiments_set_status by noting the draft nature and subsequent approval step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool (to create a draft experiment) and mentions the follow-up step of using experiments_set_status after approval. While it does not explicitly exclude alternative tools, it effectively guides the agent on the creation workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
experiments_getAReturn one experiment by ID, including status, URLs, allocation, targeting filters, URL pattern rules, and timestamps. Use this before updating or archiving when the user names a specific experiment.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | No | Optional project ID. Omit only when the API key is project-scoped or the account has a clear default project. | |
| experimentId | Yes | Experiment ID returned by experiments_create or experiments_list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds no further behavioral context (e.g., rate limits, side effects). It's adequate given rich annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first lists the returned data, second gives usage guidance. Every word earns its place. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description covers key return fields. Given 2 parameters, high schema coverage, and strong annotations, the description is complete. Could add a hint about response structure, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds value by stating that experimentId comes from experiments_create or experiments_list, but this is minor beyond the schema's own descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns one experiment by ID with detailed fields (status, URLs, allocation, targeting filters, rules, timestamps). It distinguishes from siblings like experiments_list (returns multiple) and update/archive tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Use this before updating or archiving when the user names a specific experiment.' This helps the agent decide when to invoke. Could strengthen by noting when NOT to use (e.g., when listing is needed), but it's clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
experiments_listAList experiments for a SplitLaunch project, optionally filtered by lifecycle status. Results are paginated and ordered newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Default: 1. | |
| status | No | Optional lifecycle status filter. | |
| perPage | No | Default: 25. Maximum: 100. | |
| projectId | No | Optional project ID. Omit only when the API key is project-scoped or the account has a clear default project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context: pagination and ordering 'newest first', which are not in the schema or annotations. It does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and includes essential details (scoping, filtering, pagination, ordering). No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters (all documented in schema) and no output schema, the description provides a clear overview of the tool's behavior. It lacks explicit mention of return format, but the purpose and key behaviors are sufficiently covered for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 description mentions 'optionally filtered by lifecycle status', which is already in the schema, and does not add significant meaning beyond the schema for other parameters like page, perPage, or projectId.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'experiments for a SplitLaunch project', with optional filtering and pagination details. It effectively distinguishes from sibling tools like experiments_get (singular) and experiments_archive (modification).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (list experiments) and mentions optional filtering. While it does not explicitly state when not to use or list alternatives, the context of sibling tools makes the usage clear. The lack of explicit exclusions or prerequisites is acceptable given the low complexity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
experiments_set_statusAMove an experiment through draft, running, paused, and ended states, then return the updated experiment. Only call after the user approves launching, pausing, or ending the experiment.
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | Target lifecycle status. running starts the experiment; paused stops assignment without ending; ended records an end time. | |
| projectId | No | Optional project ID. Omit only when the API key is project-scoped or the account has a clear default project. | |
| experimentId | Yes | Experiment ID returned by experiments_create or experiments_list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive behavior (destructiveHint=true), so the description's addition of returning the updated experiment adds modest context. No contradictions with annotations are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently cover purpose, return value, and usage condition without redundancy. The description is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-transition tool with three parameters and no output schema, the description covers the core behavior and precondition. It could expand on allowed transitions or error scenarios, but the schema's enum descriptions partially compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with detailed descriptions for all three parameters, including enum semantics for status. The description does not add any parameter-specific information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as moving an experiment through lifecycle states (draft, running, paused, ended) and returning the updated experiment. It effectively distinguishes from sibling tools like experiments_update, which handles other modifications, though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance: 'Only call after the user approves launching, pausing, or ending the experiment.' This sets a precondition but does not mention when not to use or list alternatives, leaving room for improvement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
experiments_updateAInspectPartially update an existing experiment and return the updated experiment. Send only fields that should change; use experiments_set_status for lifecycle changes. Plus and Go cannot set URL pattern rules, and Go cannot set geo or traffic-source filters.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| projectId | No | Optional project ID. Omit only when the API key is project-scoped or the account has a clear default project. | |
| targeting | No | Optional targeting object. Device and visitor targeting are available on all plans; trafficFilters and geoFilters require Plus or Pro. Use documented pixel metadata keys such as utm_source, utm_medium, utm_campaign, device, browser, or geo fields. | |
| controlUrl | No | Replacement control URL. Omit to keep the current value. | |
| experimentId | Yes | Experiment ID returned by experiments_create or experiments_list. | |
| variationUrl | No | Replacement variation URL. Omit to keep the current value. | |
| urlPatternRules | No | Optional Pro-only URL pattern rules for advanced matching across multiple paths. Prefer simple controlUrl/variationUrl first. | |
| trafficAllocation | No | Replacement variation share. Accepts 0-1 or 0-100. | |
| preserveRedirectParams | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). Description adds value by specifying partial update behavior, return of updated object, and plan-specific constraints 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then usage tip and plan limitations. No fluff, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers basic behavior, return value, and plan restrictions. Lacks explanation of response structure (no output schema), but experiments_get likely provides that context. Adequate for complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (78%), so baseline is 3. Description adds plan context for urlPatternRules and targeting, but does not elaborate on individual parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'partially update an existing experiment' with a specific verb and resource, and distinguishes from sibling 'experiments_set_status' for lifecycle changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use for partial updates, avoid for lifecycle changes (use experiments_set_status), and notes plan limitations (Plus/Go cannot set URL pattern rules; Go cannot set geo/traffic-source filters).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
goals_createAInspectCreate 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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
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.
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.
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.
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.
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.
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.
goals_deactivateADeactivate a conversion goal by goal ID or event name and return the updated goal. Historical conversion events and reports remain available.
| Name | Required | Description | Default |
|---|---|---|---|
| goalId | No | Goal ID returned by goals_create or goals_list. | |
| eventName | No | Conversion event name to deactivate when goalId is not available. | |
| projectId | No | Optional project ID. Omit only when the API key is project-scoped or the account has a clear default project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds that the return value is the updated goal and that historical data remains available, which are important behavioral clarifications beyond the annotation. No contradiction detected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, with two sentences that front-load the core action and result, and a second sentence addressing a common concern (historical data preservation). No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, method, result, and side effect on history. It lacks details on reversibility or permissions, but given the annotations and schema, it is largely sufficient for a deactivation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so baseline is 3. The description mentions 'by goal ID or event name', which aligns with the anyOf constraint but adds minimal extra meaning. The projectId parameter is not described, but its schema description covers it. No significant additional insight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (deactivate a conversion goal), the resource (conversion goal), and the methods (by goal ID or event name). It also specifies that it returns the updated goal, distinguishing it from creation (goals_create) and listing (goals_list). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor does it mention exclusions or prerequisites. It implies usage when deactivation is needed, but lacks guidance on choosing between goalId and eventName or comparing to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
goals_listAList conversion goals available for SplitLaunch experiments and reports. Use active=false to inspect inactive goals; omitted active returns both active and inactive goals.
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | Optional filter. true returns active goals; false returns inactive goals. | |
| projectId | No | Optional project ID. Omit only when the API key is project-scoped or the account has a clear default project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds context about scope (experiments and reports) and parameter behavior, enhancing transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with the purpose, then brief usage detail. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but for a simple list tool with complete parameter guidance and annotations covering safety, the description is adequate. Could mention return fields but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but description adds value by clarifying the behavior of the active parameter when omitted and explaining the purpose of projectId.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists conversion goals for SplitLaunch experiments and reports. It distinguishes from sibling tools like goals_create and goals_deactivate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on using the active parameter: 'Use active=false to inspect inactive goals; omitted active returns both active and inactive goals.' No direct comparison with siblings, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
projects_archiveAArchive a SplitLaunch project and return the archived project. The public pixel stops serving experiments and accepting new events for that project, while historical usage and reports remain stored.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | Required project ID. Use projects_list or projects_get first when the user has not provided it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides specific behavioral details beyond the destructiveHint annotation: it clarifies that public pixel stops serving experiments and accepting new events, but historical data remains stored. This adds valuable context about what the tool does and does not destroy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences that immediately convey the action and consequences. No unnecessary words, each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return value and behavioral effects well. Given no output schema, it covers the essential context. Minor omission: no mention of idempotency or error states, but acceptable for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers the parameter description 100% with guidance on obtaining the projectId. The tool description does not add additional meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Archive a SplitLaunch project'), the return value ('return the archived project'), and the effect on the project ('stops serving experiments and accepting new events...'). It distinguishes itself from sibling tools like experiments_archive by focusing on the project level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like projects_delete or projects_update. However, the input schema provides guidance for the projectId parameter ('Use projects_list or projects_get first'), implying a prerequisite but not comparative usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
projects_createAInspectCreate a SplitLaunch project/client workspace, allocate a public pixel ID, and optionally allowlist initial customer-owned domains. Requires an account-level API key.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| allowedDomains | No | Optional hostnames to allowlist, e.g. example.com. Do not send full page URLs here. | |
| attributionModel | No | Optional attribution model. Default: last_touch. | |
| reportingTimezone | No | Optional IANA timezone. Default: UTC. | |
| attributionWindowDays | No | Optional attribution window in days. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=false), the description reveals side effects: allocation of a public pixel ID. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and key details. No redundant or excessive wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, prerequisites, and a side effect. Lacks explicit mention of return values, but given no output schema and existence of projects_get, it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80% (4 of 5 parameters have descriptions in schema). The description adds only partial context for allowedDomains ('optionally allowlist...'). For other parameters, schema descriptions suffice. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a concrete action: 'Create a SplitLaunch project/client workspace, allocate a public pixel ID, and optionally allowlist initial customer-owned domains.' It clearly distinguishes from siblings like projects_list, projects_update, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States when to use and a prerequisite ('requires an account-level API key'). Does not explicitly exclude alternatives or mention when not to use, but context with sibling tools makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
projects_getAReturn the selected SplitLaunch project, public pixel ID, domain whitelist, attribution settings, and masked API-key context.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | No | Optional project ID. Omit only when the API key is project-scoped or the account has a clear default project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds no new behavioral traits beyond what's returned, which is consistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently states purpose and key return fields. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single optional parameter and rich annotations, the description adequately lists return types. Missing error conditions but not critical for a simple get operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a detailed parameter description. The tool description adds no additional semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns a specific project with listed data fields (public pixel ID, domain whitelist, etc.), distinguishing it from list/create/update siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives like projects_list. Usage is implied but not formalized.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
projects_listAList SplitLaunch projects available to the authenticated account, including each public pixel ID. Results are paginated and ordered by creation time.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Default: 1. | |
| perPage | No | Default: 25. Maximum: 100. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds behavioral details beyond annotations, such as pagination and ordering by creation time, enhancing transparency 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core purpose. Every sentence adds value; no redundant or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, parameters (pagination), and key output detail (public pixel IDs). It lacks explicit return shape, but for a list endpoint, the description is sufficiently complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 (page, perPage). The description does not add meaning beyond what the schema provides; 'paginated' is implied by the parameter names. Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('SplitLaunch projects'), and the scope ('available to the authenticated account'). It also mentions key details like including public pixel IDs and pagination, distinguishing it from siblings like projects_get or projects_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use (listing projects, paginated, ordered by creation time) but does not explicitly state when not to use or suggest alternatives among siblings. The context is sufficient for an 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.
projects_updateBInspectUpdate project name, domain whitelist, or attribution settings. Use only after the user approves changing project configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| projectId | No | Optional project ID. Omit only when the API key is project-scoped or the account has a clear default project. | |
| allowedDomains | No | Optional full replacement list of allowed hostnames for the project. | |
| attributionModel | No | ||
| attributionWindowDays | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it's a mutation (readOnlyHint false) but not destructive. The description adds the important context that user approval is required. However, it doesn't disclose what happens to omitted fields (e.g., do they remain unchanged or reset?) or whether the operation has side effects, leaving gaps 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—just two sentences that front-load the action. Every word adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 cover return values or success indicators, but it doesn't. It also omits how partial updates work (e.g., whether providing only name leaves other fields unchanged). More context is needed for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (40%), so the description should compensate. It does group fields into categories but provides no additional meaning for attributionWindowDays or the behavior of projectId beyond the schema. This is insufficient given that 60% of parameters lack descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates specific fields: name, domain whitelist, and attribution settings. It effectively distinguishes from sibling tools like create or archive by focusing on existing project modifications, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a key condition: use only after user approval. However, it lacks guidance on when not to use it (e.g., creating a new project) and does not mention alternative tools like projects_create or projects_update in different contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reports_experiment_channelsBReturn acquisition-channel performance using collected UTMs, click IDs, referrers, browser context, and variant assignments. Revenue is zero when the plan does not include revenue tracking.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional ISO-8601 end date/time or YYYY-MM-DD date. | |
| from | No | Optional ISO-8601 start date/time or YYYY-MM-DD date. | |
| goal | No | Optional conversion event name to filter report results. | |
| projectId | No | Optional project ID. Omit only when the API key is project-scoped or the account has a clear default project. | |
| experimentId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds the behavioral note that revenue is zero when the plan lacks revenue tracking, which provides useful 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence states the purpose directly, and the second adds a relevant behavioral note. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and no output schema, the description is adequate but lacks details on the return structure, pagination, or field explanations. The behavioral note and annotations partially compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so the schema already provides meaning for most parameters. The description does not add additional semantic value for the parameters beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns acquisition-channel performance using specific data sources (UTMs, click IDs, etc.). It distinguishes from sibling report tools like reports_experiment_chart and reports_experiment_details by focusing on channels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, limitations, or scenarios where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reports_experiment_chartAReturn time-series experiment conversion data for agent analysis and summaries. Use this after reports_experiment_details when the user needs trend timing.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional ISO-8601 end date/time or YYYY-MM-DD date. | |
| from | No | Optional ISO-8601 start date/time or YYYY-MM-DD date. | |
| goal | No | Optional conversion event name to filter report results. | |
| interval | No | Default: day. | |
| projectId | No | Optional project ID. Omit only when the API key is project-scoped or the account has a clear default project. | |
| experimentId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive. Description adds that it returns time-series data, but no further behavioral details like rate limits or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second gives usage guidance. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema and doesn't explain return format beyond 'time-series data'. With 6 parameters and no output schema, more contextual detail on response shape would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83% (high), so baseline 3. Description does not add new meaning beyond what the schema provides for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns time-series experiment conversion data, which is specific and distinguishes from siblings by mentioning use after reports_experiment_details for trend timing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('after reports_experiment_details when the user needs trend timing'), providing a clear alternative. Could mention more siblings but sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reports_experiment_detailsAReturn experiment totals by variant: exposures, visitors, conversions, revenue when available, and conversion rate. Revenue is zero when the plan does not include revenue tracking.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional ISO-8601 end date/time or YYYY-MM-DD date. | |
| from | No | Optional ISO-8601 start date/time or YYYY-MM-DD date. | |
| goal | No | Optional conversion event name to filter report results. | |
| projectId | No | Optional project ID. Omit only when the API key is project-scoped or the account has a clear default project. | |
| experimentId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds that revenue may be zero based on plan, which is useful behavioral context beyond annotations. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. Front-loaded with main purpose and outputs. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description explains the key output fields and a special case (revenue). It could mention date range behavior or goal filtering, but overall it provides sufficient context for a summary report tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (80%), so description adds no additional parameter details. It explains the output but not the parameters themselves, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns experiment totals by variant, listing specific fields (exposures, visitors, conversions, revenue, conversion rate). It distinguishes from sibling tools like reports_experiment_channels and reports_experiment_chart which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description mentions a condition (revenue zero when plan lacks tracking) but does not explicitly guide when to use this tool vs siblings like reports_experiment_channels or reports_experiment_chart. Usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
splitlaunch_healthcheckAVerify SplitLaunch MCP connectivity and return the authenticated API-key context without exposing the secret key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds value by stating it returns authenticated API-key context without exposing the secret key, providing extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys purpose and constraints without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a healthcheck with no parameters and no output schema, the description fully explains what the tool does and what it returns, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so baseline is 4. The description does not need to add parameter details, as there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies connectivity and returns authenticated context, with a specific verb and resource. It is distinct from sibling tools which focus on specific operations like experiments or billing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking connectivity and retrieving context, but does not explicitly state when to use versus alternatives. However, given the tool's simplicity and zero parameters, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
usage_summaryAReturn billing usage such as sessions, events, exposures, and active experiments for the selected project.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional YYYY-MM-DD usage end date. | |
| from | No | Optional YYYY-MM-DD usage start date. | |
| projectId | No | Optional project ID. Omit only when the API key is project-scoped or the account has a clear default project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds specific data types returned, which is helpful 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, under 20 words, no redundancy. Efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the core return type with examples. Could be improved by mentioning default behavior for missing dates, but adequate for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
100% schema coverage means baseline is 3. Description adds little extra meaning beyond the schema descriptions for 'to', 'from', and 'projectId'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool returns billing usage (sessions, events, etc.) for a selected project, differentiating it from siblings like experiments or reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for retrieving billing usage, but no explicit when-to-use or when-not-to-use guidance, nor comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
