Skip to main content
Glama
Sign In

Autario

by com.autario
OverviewDiscussionsAdmin

copy_experiments

ADMIN/CURATOR ONLY, the copy experiments (spec 2026-11-08-copy-experiments): every mail subject autario sends is an experiment with several variants held as data. Recipients are allocated by Thompson sampling on use after send (the person used their data within the window after the mail: a connector run such as Shopify or GA4, or a data read from Claude or ChatGPT over MCP; clicks only while a young experiment has no matured sends), a new variant gets a floor share while it is young, a variant clearly below half of the champion is retired and the best becomes champion, and the worker writes at most five new variants a day inside the fixed structure, each through hard gates (only facts from the fact list, every number a token, no em-dash, no superiority word, English, no near-duplicate; a failure is stored as rejected with its reason and never sent). Five actions: list returns every experiment with champion, rounds, sends, use rate with its 95 % interval and every variant (status, text, generation, share, use and click rates, why it was retired or rejected); pause stops allocation changes and generation for one experiment (the champion keeps rendering); resume undoes it; retire_variant retires one variant by hand; add_variant adds a variant by hand, through the same gates as a generated one. The mail kinds and their kill switches are NOT here (utils/mailPolicy). Requires the connector to be OAuth-authorized as the autario curator account | any other caller gets a permission error. Use when asked "which subject line wins", "pause the onboarding test", "add this subject as a variant".

Tool call template

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

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "copy_experiments"
  }
}

Input Schema

NameRequiredDescriptionDefault
textNoadd_variant only: the new copy, inside the structure of the surface (a mail subject line).
actionYeslist = every experiment with its variants and rates; pause / resume = one experiment; retire_variant = one variant by hand; add_variant = a new variant by hand (gated).
formatNoOutput wire format for this MCP call. Default 'toon' (Token-Oriented Notation, fewest tokens, best for tabular rows). 'compact' = minified JSON. 'json' = pretty JSON for readability. The REST API always returns JSON regardless.
variantNoretire_variant only: the variant key (A, B, C ...).
experimentNoThe experiment id (its surface, e.g. mail:onboarding_csv:subject). Required for every action except list.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior4/5

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

Annotations only declare the mutation/idempotency profile; the description adds substantive behavior: pause stops allocation changes and generation but the champion keeps rendering, add_variant passes the same hard gates as generated copy (fact list, numeric tokens, no em-dash, no superiority words, English, no near-duplicate), failures are stored as rejected and never sent, and the generator writes at most five variants a day. Much of the Thompson-sampling and floor-share prose describes the system rather than this tool's call behavior, which dilutes the otherwise strong disclosure.

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

Conciseness2/5

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

A single dense block that spends most of its length on allocation mechanics, retirement thresholds and generation quotas that do not help an agent select or invoke the tool, while the five actions and their per-action requirements are buried mid-paragraph. The useful call-relevant facts (auth, action list, gates, use cases) would fit in a third of the space.

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

Completeness4/5

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

With no output schema, the description usefully summarizes what list returns (champion, rounds, sends, use rate with 95% interval, per-variant status, text, generation, share, use/click rates, rejection reason), and it covers auth, per-action scope, and gating. It is complete for correct invocation, though the noise makes it harder to extract than it should be.

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

Parameters3/5

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

Schema coverage is 100% and the schema already states that experiment is required for every action except list and what text and variant mean, so the description's parameter notes largely restate it. The one genuine addition is that add_variant's text must pass the same gates as generated variants, which the schema does not say.

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

Purpose4/5

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

The description names the resource (mail subject-line experiments, each a set of variants) and enumerates five concrete actions (list, pause, resume, retire_variant, add_variant), so an agent knows exactly what surface it operates on. It is weakened only by a long preamble about the allocation algorithm that delays the actual purpose until mid-description.

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

Usage Guidelines5/5

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

It gives explicit trigger phrasing ("which subject line wins", "pause the onboarding test", "add this subject as a variant"), states a hard prerequisite (OAuth-authorized as the autario curator account, otherwise a permission error), and explicitly excludes adjacent functionality (mail kinds and kill switches live in utils/mailPolicy). That is when-to-use, prerequisite, and when-not-to-use in one place.

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

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources