LiveVariant

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

The description reveals behaviors annotations do not convey: the stats secret is returned once and unrecoverable, only its hash is stored, no registration occurs by default, registration failure is only a warning, and editing a variant creates a new test with empty history. These are exactly the non-obvious traits an agent must know. There is no conflict with 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?

Four topically organized paragraphs: core promise, variants-vs-slots, registration/identity, and secret lifecycle. It is long, but every sentence carries a caveat or decision that would otherwise be missing, and the most important return semantics are front-loaded. This is appropriately sized for a 9-parameter tool with nested objects.

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 high-complexity tool with rich schema and output schema, the description covers the critical hidden behaviors: one-time secret, identity hashing, registration warning, and test replacement on edit. The one notable gap is that it never explicitly states that at least one of variants or slots is required, despite the schema listing zero required parameters. Because of that, an agent could attempt a meaningless empty build.

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 100% of parameters, so the baseline is 3; the description adds conceptual meaning by framing slots as combination optimization, variants as single-element control tests, and publishableKey as an optional registration side-effect. It also clarifies that the config/URLs are the test and identity is a hash, which gives semantic weight to name, variants, and context. It does not duplicate schema field descriptions, which is appropriate at full coverage.

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 first sentence names the operation (creates), the object (LiveVariant test), and the payload (URLs + stats secret), which is immediately informative. The later paragraphs clarify the no-registration default and optional publishableKey registration, so it can be told apart from a pure registration tool. It never explicitly names a sibling alternative, so it stops short of full 5.

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 gives explicit selection guidance for variants vs slots, explaining when each is appropriate and that both run the same joint model. It also states the exact condition for registration (pass publishableKey on an account-enabled deployment) and that failure degrades to a warning. It does not enumerate alternative sibling tools or state a when-not-to-use condition, so it lacks explicit exclusionary guidance.

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

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

Beyond the annotations, the description discloses the capping, pseudo-observations, the response's washout count, the fact that priors sit outside the identity hash, and the stronger claim of an every-visitor belief. This is substantial behavioral context and is consistent with the read-only/idempotent 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 most important idea is in the first sentence, and each following paragraph adds necessary behavior that is not in the schema or annotations. It is a bit long, but every sentence earns its place for a nuanced operation.

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 5-parameter tool with an output schema and rich annotations, the description covers why, when, segment scope, risk, and persistence behavior. Nothing essential for an agent to select and call it correctly appears missing.

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 (80%), so the baseline is 3, but the description adds real meaning: it explains `when` as a one-segment limitation and contrasts it with the 'much stronger' every-visitor claim, and explains that `beliefs` are guesses converted via arithmetic and capping. This justifies above baseline.

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 opens with a specific verb and resource: it 'takes YOUR estimate ... and converts it into the prior the model starts from,' and later clarifies the capping and washout behavior. It does not explicitly distinguish this from siblings like build_test or variant_brief, but the function is clear.

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 context is clear: use it when you already have an estimate and want to avoid spending early visitors rediscovering it, and the `when` paragraph tells when the one-segment variant applies. No alternatives are named and there is no explicit when-not-to-use, so it stops short of 5.

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

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 substantial behavioral context beyond that: it requires the stats secret, explains that the manage URL fragment automatically supplies it, and details the statistical outputs including probabilities and expected stopping cost. It also discloses multi-slot per-slot marginals. This is a thorough and honest behavioral picture with 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.

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

The description is front-loaded with the core purpose and organized into clear blocks: output interpretation, multi-slot behavior, and authentication. The middle section is slightly wordy—the 2/10-vs-1/10 example and 'most common mistake' phrasing reinforce the warning but are somewhat redundant. Overall, each major idea earns its place, but there is minor rhetorical fat.

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 read-only stats tool with a rich output schema and strong annotations, the description covers input flexibility, output semantics, multi-slot extras, and the secret/auth nuance. An agent has everything it needs to select and invoke the tool correctly without guessing. The output schema excuses the description from listing return fields, and nothing important is missing.

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 baseline is 3. The description adds a little useful context about the stats secret and fragment handling, and it explains the high-level purpose of the test parameter through the tool's behavior. But it does not substantially extend the parameter meanings beyond what the schema already documents. It meets the baseline without exceeding it.

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 leads with a specific verb and resource ('Fetches a test's results') and adds the interpretive scope ('works out what they mean'), which clearly defines the tool's purpose. This separates it from siblings like list_tests, get_test_status, and inspect_test without needing to name them. The opening sentence is unambiguous and specific.

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 you need statistical interpretation of test results—and warns against eyeballing conversion rates. However, it never explicitly states when to prefer this tool over siblings like get_test_status or inspect_test, nor does it offer any exclusions or alternative routing. The context is enough to infer usage but not enough to fully guide tool selection.

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

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

Beyond the readOnly/idempotent/destructive annotations, the description discloses important runtime behavior: unverified destinations work but show a continue screen, verified:false triggers a domain verification workflow, unclaimed tests can be claimed via the manage URL, and the stats secret is required unless included in the manage URL fragment. This materially helps an agent predict side effects and prerequisites.

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 longer than average but well-structured: first a precise statement of results, then behavioral implications and user guidance, then authentication notes. Each section earns its place, and the first sentence front-loads the core 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?

With an output schema present and annotations covering read-only/identity, the description completes the picture by covering the shared secret, the manage-URL fragment behavior, what to do about verified:false, and what unclaimed means. No required information for a correct call is missing.

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 a baseline of 3 applies. The description adds value by explaining that statsSecret is required, can be omitted when a manage URL carries it, and that the test parameter can be an encoded config or several URL forms. This goes beyond the raw schema 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 purpose is explicit: 'Reports what the deployment's registry knows about a test' with specific dimensions (account claim, organization, verified redirect domains). It clearly distinguishes this from sibling tools like get_stats by naming the exact kind of status being checked.

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 gives clear context for when to call this tool: to check account claim and domain verification status. It also notes the shared stats-secret requirement with get_stats and how a manage URL fragment supplies it automatically. It does not explicitly state when not to use it, but the alternatives are not needed because the purpose is well-scoped.

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

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

Annotations already mark the tool as readOnly, idempotent, and non-destructive. The description adds valuable behavioral context: it lints for campaign-time-only mistakes and accepts multiple input forms (encoded configs, LiveVariant URLs, query-parameter serve URLs). This goes well beyond the structured annotations and clarifies what the operation actually does.

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 compact and front-loaded: the first sentence states the core function, the second explains the linting value-add, and the closing sentence gives usage context. Every sentence earns its place with no 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?

For a two-parameter read-only tool with full schema coverage, rich annotations, and an output schema, the description covers the essential operational context: what it inspects, what it checks for, and when to invoke it. Nothing critical is missing for an agent to select and call it 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%, and the schema already documents both parameters in detail, including accepted formats and the alias relationship between test and config. The description itself adds no additional parameter-level semantics, so the baseline 3 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 uses a specific verb ('Decodes') and resource ('a test'), and clearly states what it produces: slots, variants, context, redirect-servability, and lint findings. It also distinguishes its role from siblings like build_test or get_test_status by framing it as the pre-send inspection step and the answer to 'what is this link?'.

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 explicitly says 'Use this before sending anything, and to answer "what is this link?"', giving clear situational guidance. It does not name sibling alternatives or state when not to use it, but the use-before-sending context is strong enough to guide an agent.

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

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

Annotations already mark the operation as read-only, idempotent, and non-destructive, so the bar is lower. The description adds valuable behavioral context beyond annotations: newest-first ordering, cursor pagination, optional case-insensitive filtering, deployment caveat, and the caller-identity constraint. It also discloses that each entry carries an encoded config usable by other tools.

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 dense sentences with no filler. The core behavior is front-loaded, followed by the scoping caveat and the downstream compatibility note. 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?

The description is complete for a read-only list operation with an output schema available. It explains scope, ordering, pagination, filtering, deployment prerequisites, caller identification, and how the returned config can be used downstream. Nothing essential is missing.

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 67% with q and cursor already described in the schema. The description reinforces q as a case-insensitive name filter and mentions cursor pagination, but does not add significant new meaning beyond the schema, especially for the 'limit' parameter which relies solely on its numeric constraints.

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 ('Lists') with a clear resource ('tests registered to the signed-in account') and adds ordering and pagination details. It also distinguishes itself from siblings by noting that unlike other tools, the account scope cannot be expressed as an argument.

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?

It clearly states this tool only works on deployments with accounts and only for an identified caller, which sets the context for when it applies. It also mentions downstream tools that accept the returned config, implying a workflow, though it does not explicitly name alternatives or when-not-to-use conditions.

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

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

Annotations already indicate a non-read-only, non-idempotent, non-destructive write, so the description goes beyond them by explaining the registration effect, the requirement that the stats secret match the config hash, and the fact that a listed test can be removed from the dashboard while continuing to serve. It does not cover duplicate-registration behavior, but that gap is acceptable given the annotations and output schema.

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?

Every sentence earns its place: the first states the core purpose, the second gives precise usage conditions, the third references the preferred alternative, the fourth excludes keyless tests with reasoning, and the fifth notes a relevant behavioral nuance. It is information-dense without redundancy, and the most important facts are 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?

The description is complete for a three-parameter tool with a 100% schema, annotations, and an output schema. It covers when to use, the effect, the exclusion case, and post-registration behavior. Minor omissions such as error scenarios for mismatched secrets are not critical given the output schema handles return values.

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 baseline is 3. The description adds meaningful constraint semantics by stating the stats secret 'must match the hash inside the config' and that the publishable key 'identifies the organization to register into,' which deepens the parameter explanations beyond the schema's 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 opens with a clear, specific action: 'Registers a test you built earlier to the organization a publishable key belongs to,' and immediately explains the outcome (appears under My tests, dashboard-readable without the secret). It also distinguishes itself from the sibling build_test by explicitly noting that passing publishableKey there registers in one step. This leaves no ambiguity about what the tool does or how it relates to nearby 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 gives an explicit usage condition: 'Use this only when the user provides both the test's stats secret and a publishable key for an organization they administer.' It also names the alternative (build_test with publishableKey) and states a clear exclusion for keyless tests. This is textbook when-to-use guidance with no inference required.

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

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

The description is rich in behavioral disclosure: the returned URL is not directly fetchable, assets use short-lived signatures, storage is content-addressed, SVG is refused, and asset hosting may be unavailable. However, it explicitly states that uploading the same image twice is harmless and returns the same URL, which implies idempotent behavior, while the annotations declare idempotentHint=false. This is an annotation contradiction, so the score must be 1 per the rubric.

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 front-loaded with the core purpose, then layers constraints and caveats in compact, purposeful sentences. Every sentence adds meaningful behavior or usage context, and nothing feels redundant or padding.

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 two fully documented parameters, a rich output schema, and detailed annotations, the description covers return value usage, URL fetchability caveats, content-addressing behavior, format restrictions, and the deployment-dependent asset-hosting failure mode. Nothing essential for invoking the tool correctly is missing.

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%, and the schema already documents data as base64-encoded bytes (not a data URL, maxLength 8000000) and contentType as an enum of raster formats. The description adds useful context about content addressing and raster-only enforcement, but it does not materially expand parameter-level semantics beyond the schema, so the 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 opens with a specific verb and resource: 'Uploads an image to the deployment's asset store and returns its URL.' It also explains the intended consumption context ('for use as a variant's image (email tests) or url'), which makes the purpose unmistakable and distinct from the sibling tool set.

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 clearly states when the tool is relevant: when an image URL is needed for a variant's image or url field. It does not explicitly name alternatives or exclusions, but none of the sibling tools are alternative uploaders, so the context is sufficient for an agent to select it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context: the tool returns constraints rather than variants themselves, and it encodes the 'one idea per slot' rule. It does not discuss auth or rate limits, but the annotations cover the safety profile.

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 four sentences, front-loaded with the core function, then the single most important constraint, and then the correct call timing. Every sentence earns its place with no filler or 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?

With an output schema present, annotations covering safety, and a description that states the key design rule and workflow position, the tool is well covered. Minor gaps are the unexplained 'slot' concept and the vague phrase 'whether a test can be read at all,' but these do not block correct invocation.

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 60%, and the existing descriptions for goal, format, and audience carry most of the parameter meaning; count has explicit min/max/default and channel has an enum. The description adds no parameter-specific detail beyond mentioning email/web, so it does not compensate for the two undocumented parameters or add new semantic value.

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 function: it 'Returns the constraints to write or generate test variants against, for email or web' and also mentions rules for whether a test can be read. This distinguishes it from siblings like build_test or register_test by role, though it never names a sibling explicitly.

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?

It gives explicit workflow placement: 'Ask for this before drafting variants, then produce them yourself against what it returns.' This tells the agent when to call it, but it does not mention when not to call it or point to alternative tools.

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