Amplitude Experiment connector for AI agents

Tools your experimentation agent reaches for on Amplitude Experiment, scoped per tenant.

CALL ANY TOOL

Feature flags and experiments in one toolkit: flags, variants, cohort and user targeting, mutex groups, holdouts, and deployments. The bearer token stays vaulted.

amplitudeexperimentmanagement_list_all_versions

List all versions

List version history across all flags and experiments the api key can access, in one global, paginated feed: distinct from amplitudeexperimentmanagement_list_flag_versions and amplitudeexperimentmanagement_list_experiment_versions, which return the version history for one specific flag or experiment and do not support start/end/limit/cursor pagination. this global endpoint does support all four. confirmed from amplitude's docs: versions are ordered by creation time, descending, and the response follows {"nextcursor": number, "versions": [{"createdat": iso 8601 string, "createdby": userid number, "version": number, "flagconfig": {...full flag config snapshot...}}]}. unconfirmed: amplitude's docs only show flagconfig in the example, despite this endpoint's description explicitly covering both flags and experiments: whether experiment-type version entries carry an analogous experimentconfig key (or something else) instead of flagconfig is not confirmed by the docs and has not been independently verified. no default value for limit is documented, and no maximum time range for start/end is documented. this org has confirmed feature experimentation entitlement (verified via live-tested list flags and list experiments calls). rate limit: 100 requests/second and 100,000/day, shared across the whole experiment management api (not per-endpoint). confirmed (live-tested on eu, resolves a previously-open question): experiment-type version entries use the exact same "flagconfig" key as flag-type entries: there is no separate "experimentconfig" key. distinguish the two only by the snapshot's own shape (e.g. presence of variants[].payload mutation objects) or by cross-referencing the id against list_experiments.

Parameters

Name

Type

Required

Description

cursor

string

Optional

Opaque pagination token from a previous response's nextCursor field. Don't construct this value yourself: pass back exactly what a prior call returned.

end

string

Optional

ISO 8601 formatted end time of versions to return (exclusive). Not explicitly marked required/optional by Amplitude's docs; treated as optional for consistency with limit/cursor on this same endpoint.

limit

integer

Optional

Maximum number of versions to return, capped at 1000. No documented default: omit to use Amplitude's own default page size.

start

string

Optional

ISO 8601 formatted start time of versions to return (inclusive). Not explicitly marked required/optional by Amplitude's docs; treated as optional for consistency with limit/cursor on this same endpoint.

amplitudeexperimentmanagement_get_experiment

Get experiment

amplitudeexperimentmanagement_create_deployment

Create deployment

amplitudeexperimentmanagement_update_deployment

Update deployment

amplitudeexperimentmanagement_bulk_delete_experiment_variant_cohorts

Bulk delete experiment variant cohorts

amplitudeexperimentmanagement_add_experiment_variant_cohorts

Add experiment variant cohorts

amplitudeexperimentmanagement_remove_all_experiment_variant_users

Remove all experiment variant users

amplitudeexperimentmanagement_list_deployments

List deployments

amplitudeexperimentmanagement_get_experiment_variant

Get experiment variant

amplitudeexperimentmanagement_create_experiment

Create experiment

Create a new amplitude experiment. required: project_id, key. name is technically optional per this tool (amplitude's docs disagree), but supply it anyway: every documented example includes it. deliverymethod and rolloutpercentage are not create-time fields: only projectid, key, name, description, variants, bucketingkey, rolloutweights, targetsegments, deployments, evaluationmode, experimenttype are documented as create-time fields. confirmed (live-tested both regions): created experiments default deliverymethod to "feature" (visible via get_experiment/list_experiments): real "web"-delivery experiments only come from amplitude's visual editor and behave differently on update_experiment/create_experiment_deployment (see those tools). set rolloutpercentage afterward via update_experiment. complex nested fields (variants, rollout_weights, target_segments) are json-encoded strings, not native objects: parsed before sending. `parent_dependencies` looks settable by shape but is confirmed (live-tested) rejected outright with 400 "parentdependencies is not allowed": don't send it, it's read-only/derived. confirmed (live-tested both regions): `variants`, `rollout_weights`, `target_segments`, `deployments` (a real deployment id), `bucketing_key`, and `evaluation_mode` all work correctly together in one call with the default `a-b-test` experiment_type. `experiment_type: "multi-arm-bandit"` instead is gated by a third, distinct permission scope: 403 "user does not have permission (experiment_multi_armed_bandit)": separate from `experimentation` and `experiment_groups`. response: 200 {id, url}. rate limit: 100 req/s, 100,000/day, shared across the whole api.

Parameters

Name

Type

Required

Description

key

string

Required

Unique experiment key (slug-like identifier) used to reference this experiment.

project_id

string

Required

The Amplitude project ID this experiment belongs to.

bucketing_key

string

Optional

User property Amplitude uses to consistently bucket the same user into the same variant (e.g. amplitude_id, user_id, device_id, or a custom property).

deployments

array

Optional

Deployment IDs to attach this experiment to at creation time.

description

string

Optional

Human-readable experiment description.

evaluation_mode

string

Optional

Where variant assignment is evaluated: remote (Amplitude's servers) or local (in your SDK).

experiment_type

string

Optional

The experiment's statistical design. No confirmed documented default: Amplitude's own create example uses a-b-test.

name

string

Optional

Human-readable experiment name. Amplitude's docs disagree on whether this is required; this tool treats it as optional but you should supply it.

parent_dependencies

string

Optional

JSON-encoded object describing parent dependency relationships (e.g. mutex group or holdout membership): observed on live experiment objects via list_experiments but NOT documented anywhere in Amplitude's Create or Update Experiment request schemas. Exposed here defensively for advanced use; Amplitude may ignore or reject this field since it looks read-only/derived rather than settable. Verify behavior with a real call before relying on it.

rollout_weights

string

Optional

JSON-encoded object mapping each variant key to its relative distribution weight, e.g. '{"control": 1, "treatment": 1}' for an equal 50/50 split. Keys must match the variants[].key values above. Pass as a JSON-encoded STRING, not a native object.

target_segments

string

Optional

JSON-encoded array of target segment objects that define who is included in this experiment and at what percentage, evaluated in order. Documented shape per segment: {"name": string (required), "conditions": [{"type": "property" (fixed value), "prop": string, "op": one of is|is not|contains|does not contain|less|less or equal|greater|greater or equal|set is|set is not|set contains|set does not contain|glob match|glob does not match, "values": string[]}] (required), "percentage": number (required), "rolloutWeights": object (required, same shape as rollout_weights above)}. Cohort-based targeting is not supported. Pass as a JSON-encoded STRING, not a native array.

variants

string

Optional

JSON-encoded array of variant objects to bucket users into. Amplitude's documented shape per variant: {"key": string (required), "payload": any JSON (optional), "name": string (optional), "description": string (optional)}. A live-tested list_experiments call against this org showed a richer real-world payload shape for feature-flag-backed experiments: "payload": [{"data": {"mutations": [...]}, "action": "mutate"}] instead of a bare value: use whichever shape matches your use case. Pass as a JSON-encoded STRING, not a native array; this tool parses it before sending. Omit to use Amplitude's own default variant set (unconfirmed what that default is).

amplitudeexperimentmanagement_update_experiment

Update experiment

Update an existing amplitude experiment: partial update; only provided fields change (except end_date, see below). editable fields: name, description, bucketing_key, bucketing_salt, bucketing_unit, evaluation_mode (remote|local), rollout_percentage (0-100), target_segments (json-encoded string, replaces the segment list entirely, no cohort support), enabled, archive, experiment_type (a-b-test|multi-arm-bandit), sticky_bucketing, start_date, end_date (iso 8601; send null explicitly to clear it), exposure_event (json-encoded string, shape undocumented by amplitude), tags (unconfirmed whether this replaces or diffs the existing list), decision, decision_reason, rolled_out_variant. state is not directly settable: amplitude derives it from enabled (planning→running), archive (a separate axis), and decision: "rollout" ramps rollout_percentage to 100 favoring rolled_out_variant and disables sticky_bucketing; "rollback" zeroes rollout; "continue-running" pairs with a new end_date. this model is inferred from docs, not live-confirmed by a real patch: verify the returned state in practice. complex fields (target_segments, exposure_event) are json-encoded strings, not native objects. rate limit: 100 req/s, 100,000/day, shared across the whole api. confirmed (live-tested, reproduced 4x): returns 403 "user does not have permission (experimentation)": a role/permission scope on the amplitude user, not an org-wide gate (list_experiments and create_experiment work fine with the same credentials). confirmed (live-tested both regions): a real "web"-delivery experiment instead fails with 400 "web experiments are not supported by management api yet": checked before the permission wall, so check deliverymethod (via get_experiment/list_experiments) before assuming a failure here is the 403.

Parameters

Name

Type

Required

Description

string

Required

The experiment's ID to update.

tags

array

Optional

Tags for this experiment. Amplitude's docs disagree on whether this replaces the full tag list or diffs against it (adds/deletes): see the tool description's NOTE on tags. Verify actual behavior with a real call.

target_segments

string

Optional

JSON-encoded array of target segment objects that REPLACES the experiment's existing segment list entirely. Documented shape per segment: {"name": string (required), "conditions": [{"type": "property" (fixed value), "prop": string, "op": one of is|is not|contains|does not contain|less|less or equal|greater|greater or equal|set is|set is not|set contains|set does not contain|glob match|glob does not match, "values": string[]}] (required), "percentage": number (required), "rolloutWeights": object mapping variant key to weight (required)}. Cohort-based targeting is not supported. Pass as a JSON-encoded STRING, not a native array.

amplitudeexperimentmanagement_bulk_delete_experiment_variant_users

Bulk delete experiment variant users

Remove a specific set of users or devices (by id) from an experiment variant's inclusion list, leaving all other included users untouched. this is distinct from the remove-all-users tool, which wipes the entire inclusion list regardless of which ids exist. limited to 100 user/device ids per request per amplitude's docs: split larger lists across multiple calls. confirmed directly from amplitude's official docs (exact curl example: --data '{"users":["id1", "id2", "id3"]}'): despite this being a delete request, the target ids are sent as a json request body, not a query parameter. delete-with-body is unusual, but it is exactly what amplitude's docs show, and this tool sends the request the same way. a successful call returns 200 ok with the literal text 'ok' (not a json body); this tool reports success from the status code, not from parsing a response payload. this org has confirmed feature experimentation entitlement (live-tested via the list endpoints); the request/response shape below is per amplitude's published docs and has not been independently live-tested for this specific write endpoint. rate limit: 100 requests/second and 100,000/day, shared across the whole experiment management api (not per-endpoint). fixed (was broken, now live-tested): this field is json-encoded per its schema, but was previously mapped via a plain body_json_mapping template that sent the raw string instead of a parsed array/object: amplitude rejected it (e.g. "\"inclusions\" must be an array"). now uses a jsonnet_template with std.parsejson() to correctly convert it before sending, matching the pattern the experiments-side tools already used. confirmed working end-to-end live.

Parameters

Name

Type

Required

Description

string

Required

The experiment's ID. Find it in the URL of the experiment in the Amplitude app.

user_ids

array

Required

User or device IDs to remove from the variant's inclusion list. Sent as a JSON request body (confirmed from Amplitude's docs) under the field name 'users'. Limited to 100 per request.

variant_key

string

Required

The variant's key.

amplitudeexperimentmanagement_add_experiment_variant_users

Add experiment variant users

amplitudeexperimentmanagement_remove_all_flag_variant_users

Remove all flag variant users

amplitudeexperimentmanagement_list_experiment_deployments

List experiment deployments

amplitudeexperimentmanagement_get_experiment_variant_cohorts

Get experiment variant cohorts

amplitudeexperimentmanagement_create_experiment_deployment

Create experiment deployment

amplitudeexperimentmanagement_update_experiment_variant

Update experiment variant

Edit an existing experiment variant: rename its key, or update name, description, payload, or rolloutweight. all body fields are optional; omit a field to leave its current value unchanged. confirmed from raw page source (not just visible rendered text): this endpoint is patch, not post: verified directly in amplitude's rendered doc source, where both the section heading's one-line method summary and the full curl example agree: 'patch .../experiments//variants/'. note that the equivalent flags api doc page has a genuine docs bug for this same operation: its one-line method summary says post, but the curl example directly beneath it uses patch: if you've seen post associated with 'edit variant' elsewhere, that's this docs inconsistency, not a different real endpoint; the detailed curl example is the reliable source in both places, and it says patch on both the flags and experiments pages. payload replaces the entire existing payload (it is not merged); pass it as a json-encoded string, e.g. the shape confirmed live on this org: [{"data":{"mutations":[]},"action":"mutate"}]. rolloutweight has no documented numeric range in amplitude's docs. a successful call returns 200 ok with the literal text "ok", not a json body. rate limit: 100 requests/second and 100,000/day, shared across the whole experiment management api (not per-endpoint).

Parameters

Name

Type

Required

Description

string

Required

The experiment's ID.

variant_key

string

Required

The variant's key.

description

string

Optional

Description for the variant.

key

string

Optional

New variant key, if you want to rename this variant. Can only contain letters, numbers, underscores (_), and hyphens (-).

name

string

Optional

Display name for the variant.

payload

string

Optional

Payload for the variant, as a JSON-encoded string. Must be a valid JSON element (object, array, or primitive). This value REPLACES the existing payload entirely: it is not merged. A real variant payload confirmed live on this org looked like [{"data":{"mutations":[]},"action":"mutate"}].

rollout_weight

number

Optional

Rollout weight for non-targeted users. Amplitude's docs don't document a numeric range or scale for this value.

amplitudeexperimentmanagement_bulk_delete_flag_variant_cohorts

Bulk delete flag variant cohorts

amplitudeexperimentmanagement_add_flag_variant_cohorts

Add flag variant cohorts

Add specific cohorts as inclusions on a variant of an amplitude experiment feature flag: explicitly assigning these cohorts to this variant regardless of the variant's rollout weight. unconfirmed: unlike the users endpoint, amplitude's docs don't mention any documented maximum on the number of cohort inclusions per variant, nor whether this call is additive or replaces the existing cohort list: treat both as unconfirmed until independently live-tested. confirmed (live-tested): this org has feature experimentation entitlement. per amplitude's docs, a successful call returns a 200 ok response with the literal text "ok" as the body: not a json object: so the tool treats the response as raw text rather than parsing it as json. rate limit: 100 requests/second and 100,000/day, shared across the whole experiment management api (not per-endpoint). fixed (was broken, now live-tested): this field is json-encoded per its schema, but was previously mapped via a plain body_json_mapping template that sent the raw string instead of a parsed array/object: amplitude rejected it (e.g. "\"inclusions\" must be an array"). now uses a jsonnet_template with std.parsejson() to correctly convert it before sending, matching the pattern the experiments-side tools already used. confirmed working end-to-end live. confirmed (live-tested): a well-formed request with a syntactically valid cohort_id that does not correspond to a real, existing amplitude cohort returns a generic http 400 "internal server error" from amplitude, not a clean validation error: unlike user_ids, which accept arbitrary/free-form identifiers without requiring them to pre-exist. use a real cohort id from this amplitude project's cohorts, or expect this error.

Parameters

Name

Type

Required

Description

cohort_ids

string

Required

JSON-encoded array of cohort IDs to add as inclusions on this variant.

string

Required

The flag's ID (not its key): find it in the URL of the flag's page in the Amplitude app.

variant_key

string

Required

The key of the variant to add cohort inclusions to.

amplitudeexperimentmanagement_remove_experiment_variant_user

Remove experiment variant user

amplitudeexperimentmanagement_list_experiment_variants

List experiment variants

amplitudeexperimentmanagement_get_experiment_variant_users

Get experiment variant users

amplitudeexperimentmanagement_create_experiment_variant

Create experiment variant

Add a new variant to an experiment. confirmed from amplitude's official docs (verified against the page's raw rendered source, not just its visible text): post /api/1/experiments/{id}/variants with body {key, name, description, payload, rolloutweight}: key is the only required field and can only contain letters, numbers, underscores (_), and hyphens (-). payload is passed here as a json-encoded string (any valid json element: object, array, or primitive); amplitude's own docs example shows a bare object, but this org's live-tested data shows a real experiment variant payload shaped like [{"data":{"mutations":[]},"action":"mutate"}]: an array of mutation objects: so don't assume payload is always a plain object. rolloutweight has no documented numeric range or scale in amplitude's docs (unclear if it's 0-100, a relative share among variants, or something else): match the scale your experiment's other variants already use. a successful call returns 200 ok with the literal text "ok", not a json body, so this tool does not attempt to parse the response as json. rate limit: 100 requests/second and 100,000/day, shared across the whole experiment management api (not per-endpoint). confirmed (live-tested, reproduced 4x): this specific operation returns http 403 "user does not have permission (experimentation)" for this connected account, even though list_experiments (no id) and create_experiment both work fine with the same credentials. this looks like a role/permission scope on the amplitude user tied to this management api key, not an org-wide entitlement gate (contrast with the profile api's different "org does not have access" 401): check the amplitude user's experiment role/permissions if you hit this.

Parameters

Name

Type

Required

Description

string

Required

The experiment's ID.

key

string

Required

The variant key. Can only contain letters, numbers, underscores (_), and hyphens (-).

description

string

Optional

Description for the variant.

name

string

Optional

Display name for the variant.

payload

string

Optional

Optional payload for the variant, as a JSON-encoded string. Must be a valid JSON element (object, array, or primitive). A real variant payload confirmed live on this org looked like [{"data":{"mutations":[]},"action":"mutate"}]: an array of mutation objects: rather than a bare object, so don't assume the shape without checking your own flag/experiment configuration.

rollout_weight

number

Optional

Rollout weight for non-targeted users. Amplitude's docs don't document a numeric range or scale for this value.

amplitudeexperimentmanagement_update_flag

Update flag

Edit an existing amplitude experiment feature flag: partial update, only provided fields change. confirmed editable: name, description, bucketingkey, bucketingsalt, bucketingunit, evaluationmode, rolloutpercentage, targetsegments, enabled, archive, tags. confirmed not editable: variants, deployments, projectid, key, the flag-level rolloutweights object (only the copy nested inside each targetsegments entry is patchable), and parentdependencies. `archive: true`/`false` is the write-side counterpart of the flag's read-only `deleted` field. unconfirmed whether array fields (targetsegments, tags) replace vs. merge on patch: treat as full replacement until shown otherwise. confirmed (live-tested): `archive` must be sent alone: combining it with any other field fails with "cannot edit archived flag", even on an unarchived flag. confirmed (live-tested both regions, full field sweep): `enabled: true` fails with 400 "cannot activate without deployments" unless the flag already has one attached. `bucketing_unit` must name a real, configured group type: an arbitrary string fails 400 "invalid bucketing unit". all other fields (`bucketing_key`, `bucketing_salt`, `evaluation_mode`, `rollout_percentage`, `tags`, `target_segments`) confirmed working together in one call: `tags` is a native array, not a json string like `target_segments`. rate limit: 100 req/s, 100,000/day, shared across the whole api.

Parameters

Name

Type

Required

Description

string

Required

The flag's ID, as shown in the Amplitude app URL for the flag.

tags

array

Optional

Tags for the flag. Amplitude's docs don't confirm whether this replaces the full tag list or merges with existing tags on PATCH: treat it as a full replacement unless testing shows otherwise.

target_segments

string

Optional

JSON-encoded string (not native JSON) describing target segments evaluated before the default rollout. Must decode to an array of objects: [{"name": "segment name", "conditions": [{"type": "property", "prop": "user property name", "op": "is", "values": ["value1"]}], "percentage": 100, "bucketingKey": "optional user property", "rolloutWeights": {"control":50,"treatment":50}}]. `name`, `conditions`, and `percentage` are required per segment; `bucketingKey` is optional. CORRECTION (live-tested both regions): `rolloutWeights` is NOT optional despite how this reads: omitting it fails validation with `"targetSegments[0].rolloutWeights" is required"`. Always include it, matching the sibling Experiments-side tools which document this correctly. Documented `op` values: is, is not, contains, does not contain, less, less or equal, greater, greater or equal, set is, set is not, set contains, set does not contain, glob match, glob does not match, version less than, version less than or equal to, version greater than, version greater than or equal to. Amplitude's docs don't confirm whether sending this replaces the full segment list or merges with existing segments: treat it as a full replacement unless testing shows otherwise.

amplitudeexperimentmanagement_bulk_delete_flag_variant_users

Bulk delete flag variant users

amplitudeexperimentmanagement_add_flag_variant_users

Add flag variant users

Add specific users, devices, or emails as individual inclusions on a variant of an amplitude experiment feature flag: explicitly assigning these identities to this variant regardless of the variant's rollout weight. amplitude allows up to 2,000 total inclusions per variant; exceeding that limit returns a 400 error (per amplitude's docs, verbatim: "you can have up to 2,000 inclusions per variant. if you exceed this limit, amplitude returns a 400 error."). unconfirmed: the docs don't explicitly state whether this call is purely additive (merges with the existing inclusion list) or could replace it outright: the endpoint is titled and described as adding inclusions "to a flag's variant", which implies additive behavior, but this has not been independently live-tested. confirmed (live-tested): this org has feature experimentation entitlement. per amplitude's docs, a successful call returns a 200 ok response with the literal text "ok" as the body: not a json object: so the tool treats the response as raw text rather than parsing it as json. rate limit: 100 requests/second and 100,000/day, shared across the whole experiment management api (not per-endpoint). fixed (was broken, now live-tested): this field is json-encoded per its schema, but was previously mapped via a plain body_json_mapping template that sent the raw string instead of a parsed array/object: amplitude rejected it (e.g. "\"inclusions\" must be an array"). now uses a jsonnet_template with std.parsejson() to correctly convert it before sending, matching the pattern the experiments-side tools already used. confirmed working end-to-end live.

Parameters

Name

Type

Required

Description

string

Required

The flag's ID (not its key): find it in the URL of the flag's page in the Amplitude app.

user_ids

string

Required

JSON-encoded array of user IDs, device IDs, or email addresses to add as individual inclusions on this variant. Max 2,000 total inclusions per variant across all calls: see the tool description for the 400 error behavior.

variant_key

string

Required

The key of the variant to add user/device inclusions to.

amplitudeexperimentmanagement_remove_flag_variant_user

Remove flag variant user

amplitudeexperimentmanagement_list_experiment_versions

List experiment versions

amplitudeexperimentmanagement_get_experiment_version

Get experiment version

For more tools, view docs.

Build your Agent

Drop the toolkit in, point it at the tenant, and your agent can audit flags and roll variants from the first run.

import { ScalekitClient } from "@scalekit-sdk/node";
import { DynamicStructuredTool } from "@langchain/core/tools";
import { createReactAgent } from "@langchain/langgraph/prebuilt";
import { z } from "zod";

const sk = new ScalekitClient(envUrl, clientId, clientSecret);

const { tools } = await sk.tools.listScopedTools("user_123", {
  filter: { connectionNames: ["amplitudeexperimentmanagement"], toolNames: ["amplitudeexperimentmanagement_list_flags", "amplitudeexperimentmanagement_get_experiment", "amplitudeexperimentmanagement_update_flag"] },
  pageSize: 100,
});

const lcTools = tools.map((t) => new DynamicStructuredTool({
  name: t.tool.definition.name,
  description: t.tool.definition.description,
  schema: z.object({}).passthrough(),
  func: async (args) => {
    const { data } = await sk.tools.executeTool({
      toolName: t.tool.definition.name,
      identifier: "user_123",
      params: args,
    });
    return JSON.stringify(data);
  },
}));

const agent = createReactAgent({ llm, tools: lcTools });

import { ScalekitClient } from "@scalekit-sdk/node";
import OpenAI from "openai";

const sk = new ScalekitClient(envUrl, clientId, clientSecret);
const openai = new OpenAI();

const { tools } = await sk.tools.listScopedTools("user_123", {
  filter: { connectionNames: ["amplitudeexperimentmanagement"], toolNames: ["amplitudeexperimentmanagement_list_flags", "amplitudeexperimentmanagement_get_experiment", "amplitudeexperimentmanagement_update_flag"] },
  pageSize: 100,
});

const llmTools = tools.map((t) => ({
  type: "function",
  function: {
    name: t.tool.definition.name,
    description: t.tool.definition.description,
    parameters: t.tool.definition.input_schema,
  },
}));

const resp = await openai.responses.create({
  model: "gpt-4o", input: prompt, tools: llmTools,
});

import { ScalekitClient } from "@scalekit-sdk/node";
import Anthropic from "@anthropic-ai/sdk";

const sk = new ScalekitClient(envUrl, clientId, clientSecret);
const anthropic = new Anthropic();

const { tools } = await sk.tools.listScopedTools("user_123", {
  filter: { connectionNames: ["amplitudeexperimentmanagement"], toolNames: ["amplitudeexperimentmanagement_list_flags", "amplitudeexperimentmanagement_get_experiment", "amplitudeexperimentmanagement_update_flag"] },
  pageSize: 100,
});

const llmTools = tools.map((t) => ({
  name: t.tool.definition.name,
  description: t.tool.definition.description,
  input_schema: t.tool.definition.input_schema,
}));

const msg = await anthropic.messages.create({
  model: "claude-sonnet-4-6", max_tokens: 1024,
  tools: llmTools,
  messages: [{ role: "user", content: prompt }],
});

import { Agent } from "@google/adk/agents";
import {
  MCPToolset, StreamableHTTPConnectionParams,
} from "@google/adk/tools/mcp";

const toolset = new MCPToolset({
  connectionParams: new StreamableHTTPConnectionParams({
    url: "https://mcp.scalekit.com/amplitudeexperimentmanagement",
    headers: { Authorization: `Bearer ${userScopedToken}` },
  }),
});

const agent = new Agent({
  name: "agent", model: "gemini-2.0-flash",
  tools: await toolset.getTools(),
});

Try these prompts

Paste any prompt into your agent to start managing Amplitude experiments from your workflows.

Flag hygiene

Copy the prompt

Copied

List flags that have been at 100% rollout for more than 30 days.

Copy the prompt

Copied

Which flags have no owner or description set?

Copy the prompt

Copied

Show every flag active in the production deployment.

Experiment operations

Copy the prompt

Copied

Which experiments are running past their planned end date?

Copy the prompt

Copied

Add cohort [cohort_id] to the treatment variant of [experiment_key].

Copy the prompt

Copied

Roll [flag_key] to 25% and confirm the new allocation.

Targeting

Copy the prompt

Copied

List users individually targeted into variants on [flag_key].

Copy the prompt

Copied

Show mutex groups and which experiments share each one.

Copy the prompt

Copied

Remove the holdout on [experiment_key] and report the new state.

SEE HOW AUTH WORKS

Your users connect once. Their Amplitude Experiment Management credentials stay vaulted, every call is scope-checked, and every action is logged.

Authorize

Your user connects

Amplitude Experiment Management

once. We tie it to their identity and the meetings they approved — no shared bot account, no org-wide access

Who:

user ‘A’

when:

Once per user

access:

Limited to user

Store

Their

Amplitude Experiment Management

token lives in a vault scoped to them. User A's meetings are never reachable by an agent acting for user B, even on the same connection

vault:

encrypted

scope:

per-user

tokens:

auto-refreshed

Resolve

When your agent calls a

Amplitude Experiment Management

tool, we fetch the right token server-side. It never touches your agent, never appears in the LLM context, never shows up in your logs

speed:

~40ms

check:

before every call

seen by:

nobody

Audit

Every

Amplitude Experiment Management

tool call is logged — who triggered it, which meeting was fetched, what came back. 90 days of history, tied to the user who authorized it

history:

90 days

export:

SIEM-ready

logged:

every call

Test other agents

See the same per-user auth pattern across other connectors.

SALES

Deal intelligence agent

Score Gong call risk with an LLM, cross-reference the Attio record, and DM each owner their at-risk deals in Slack.

ENGINEERING

Engineering standup agent

Pull commits from GitHub and GitLab, track Jira issue movement, and post a per-engineer standup brief to Slack.

Why Scalekit

Secure your agent's access. Connectors ship in minutes

Other connector libraries treat auth as a demo afterthought. Scalekit starts with user identity, scope enforcement, and audit.

01.

Shared tokens break per-user analytics

A shared token looks fine in a demo. In production every call looks like a service account. Scalekit resolves the real user credential so attribution, audit, and scope stay accurate.

// shared token
audit → bot_service_account
user_filter → broken

// scalekit
audit → user_abc
scope → enforced ✓

02.

Authentication is not authorization

03.

Multi-tenancy is architectural

04.

Amplitude Experiment Management today. Others tomorrow.

“Our agents act across Salesforce, Gong, Google Drive, and more, on behalf of every customer. Scalekit behind the scenes meant we can keep adding tools without ever rebuilding how credentials or tool calling work.”

Venu Madhav Kattagoni

Head of Engineering / Von

FAQs

Frequently Asked Questions

Does the agent access Amplitude Experiment Management as the user or as a shared key?

As the user. Each workspace member authorizes once and Scalekit resolves their credential at request time. Audit logs attribute every action to that user, not a shared service account.

Where is the Amplitude Experiment Management bearer token stored?

In Scalekit's managed AES-256 token vault, namespaced per tenant. Refresh is automatic. Revocation is a single dashboard action. Tokens never appear in prompts, logs, or LLM context.

Can I limit what the agent is allowed to do in Amplitude Experiment Management?

Yes. Pass a tool name filter to listScopedTools so the analytics agent only sees the subset you authorize. Pre-API-call scope checks block out-of-policy actions before the request reaches Amplitude Experiment Management.

What happens when a user revokes Amplitude Experiment Management access?

The connection is invalidated on the next tool call. Subsequent requests for that user fail closed with a clear error. Other users in the tenant remain unaffected. The event is logged for audit.

Can the agent change a live rollout without review?

Only if the write tools are in scope. Flag and variant updates are separate tools from the list and get tools, so an audit agent stays read only while a release agent keeps write access. Each write is scope-checked before the Amplitude call and logged with the acting user.

On this page

Tool and actions Framework Compatibility Starter Prompt Auth Lifecycle Try Other Agents Why Scalekit