What can you do with this server?

Kit MCP Server exposes 85 MCP/CLI tools (38 reads, 47 writes) to manage a Kit email marketing account, with confirmation and safety guards for sensitive actions. * Account: read account, colors, creator profile, growth/email stats; update colors. * Broadcasts: list/get/create/update/delete, stats and clicks, draft/schedule newsletters. * Subscribers: list/search/filter, get/create/update/unsubscribe, location, stats, tags; bulk create (OAuth). * Tags/custom fields: list/create/update/delete tags and custom fields; tag/untag subscribers, bulk tag operations (OAuth for some). * Forms/sequences: list forms/subscribers, add subscribers to forms/sequences, manage sequences and sequence emails (CRUD). * Snippets/posts/segments/templates/purchases: list snippets, posts, segments, email templates; OAuth-only purchase reads/writes. * Webhooks: list/create/update/delete endpoints and legacy webhooks; rotate/revoke signing secrets (saved privately). * Safety/ops: named private accounts, OAuth token refresh, bounded pagination, CLI commands, read-only mode, confirm guard for destructive/delivery/audience changes.

Which integrations are available for this server?

Provides tools for interacting with the Kit API v4 (newsletter/email marketing platform), covering 85 operations: reading account identity, growth and email statistics; drafting, scheduling, updating and deleting broadcasts with click breakdowns; creating, updating, filtering, unsubscribing and tagging subscribers; managing tags, forms, sequences and individual sequence emails; CRUD on snippets and templates; reading posts and segments; OAuth-only purchase endpoints and asynchronous bulk jobs; and configuring signed webhook endpoints with secret rotation.

How do I use Kit MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Kit MCP Server draft a newsletter broadcast about our spring sale and schedule it for tomorrow" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Kit MCP Server

by thenavidm

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Kit MCP Server & CLI

npm License YouTube LinkedIn

Kit MCP server and CLI for Claude Code, Codex and AI agents. 85 tools: 38 reads and 47 writes for account data, newsletters, subscribers, tags, forms, sequences, snippets, statistics, bulk work and webhooks.

One package gives you two ways in: kit-mcp connects the tools to your AI app, and kit-cli makes the same tools shell commands. Claude Desktop also has a bundled .mcpb extension. The 40 audience, delivery, deletion and signing-secret operations require explicit confirmation.

Built and maintained by Navid Moazzez. Built on Slipway, which turns one definition of each tool into the MCP server and the CLI. The installation guide is in INSTALL.md; the full matching navid.me guide is saved as a CMS draft and awaits publication.

The terminal illustrates shipped tool names and the requested draft workflow. It is a presentation preview, not a live account transcript.

You need a Kit v4 API key or an authorized OAuth session. Some endpoints require OAuth; account permissions and plan eligibility still apply. The wrapper is free software under AGPL-3.0-or-later. Kit service charges remain separate. This is a community integration, not a Kit-endorsed product.

Kit already has an official account MCP with v4 reads and writes. This package adds a task CLI, private named accounts, bounded cursor aggregation, private token refresh and a desktop bundle. It does not claim more API coverage or measured token savings over the official server.

Validation: build, typecheck, 40 behavior/CLI checks, public npm installation and desktop protocol discovery are checked. Live account writes and actual desktop GUI installation remain unverified; section 7 has the measured token costs.

Two ways to use it

Command line

npm install -g @thenavidm/kit-mcp-cli@latest
kit-cli
kit-cli list-broadcasts --help
kit-cli schema create-broadcast
kit-cli get-account --agent
kit-cli list-broadcasts --per-page 5 --agent
kit-cli create-broadcast --subject "This week's creator notes" --content '<p>Your newsletter content.</p>' --confirm --agent

Configure credentials privately first. Draft creation defaults private and unscheduled. --confirm authorizes the requested operation; --agent and --yes never bypass that guard.

MCP server, for your AI app

claude mcp add --scope user kit -- npx -y @thenavidm/kit-mcp-cli@latest

Then ask: "Draft my next newsletter privately. Show me the draft and leave it unscheduled." Confirm only the requested account action.

All client configurations and operating-system steps are in INSTALL.md.

Which one

Where you work	What to use
Claude Code, Codex, Cursor or another agent with a terminal	MCP, CLI or both
Claude Desktop chat	The local MCP server or desktop extension
Scripts, cron or CI	CLI commands, or MCP through an MCP client
A web client that accepts only a remote MCP URL	Kit's official hosted MCP; this package exposes local stdio

Related MCP server: kit-mcp

Features

Capability	CLI command	MCP tool
Account and growth	`kit-cli get-account` / `get-growth-stats`	`get_account` / `get_growth_stats`
Recent newsletters	`kit-cli list-broadcasts`	`list_broadcasts`
Draft and schedule	`kit-cli create-broadcast` / `update-broadcast`	`create_broadcast` / `update_broadcast`
Newsletter statistics	`kit-cli get-broadcast-stats` / `get-broadcast-clicks`	`get_broadcast_stats` / `get_broadcast_clicks`
Subscriber lookup	`kit-cli search-subscribers`	`search_subscribers`
Subscribers and tags	`kit-cli list-subscribers` / `list-tags` / `tag-subscriber`	`list_subscribers` / `list_tags` / `tag_subscriber`
Sequences	`kit-cli list-sequences`	`list_sequences`
Templates	`kit-cli list-email-templates`	`list_email_templates`
Signed webhook endpoints	`kit-cli create-webhook-endpoint`	`create_webhook_endpoint`
Private named accounts	`kit-cli list-accounts`	`list_accounts`
Diagnose setup	`kit-cli doctor`	CLI utility

Number	Section	What it covers
1	What you can ask it	Practical prompts, coverage and validation
2	Quick install	Install, discover and authenticate
3	Set up Kit access	API keys, OAuth and revocation
4	Connect your client	Every client and desktop route
5	Check it works	Doctor and the first account read
6	Output, flags and exit codes	Scripts, JSON and nested bodies
7	MCP or CLI and token cost	Surface choices and measurement
8	Every tool and argument	All 85 tools and their arguments
9	Newsletter and subscriber workflows	Draft, review, schedule and manage audiences
10	Pagination, bulk work and webhooks	Cursors, asynchronous jobs and private secrets
11	Several private accounts	Account selection and isolation
12	Writing safely	Confirmation, read-only and retries
13	How it works	Shared handlers, schemas and development
14	Your data	Credentials, local files and privacy
15	Environment variables	Credentials, safety and tuning
16	Updates and removal	npm, desktop, disconnecting and migration
17	Troubleshooting	Symptoms and fixes
18	API coverage and comparisons	Official and community alternatives
19	Versions	Component versions, releases and history
20	FAQ	Common questions

1. What you can ask it

Show my latest five newsletters and their statistics.
Draft my next newsletter privately and leave it unscheduled.
Find this subscriber by exact email and show their tags.
Read the current audience before applying the tag I requested.
List available sequences and templates.
Create the requested signed webhook and save its signing secret privately.

The pinned official API v4 snapshot contains 83 operations. This server exposes each one, plus list_accounts and the search_subscribers compatibility alias. The snapshot source, date, hash and reviewed corrections are in api-source.json.

Area	Examples
Account	Identity, creator profile, growth statistics, email statistics and colors
Broadcasts	Draft, read, update, delete, statistics and click breakdowns
Subscribers	Create, update, unsubscribe, filter, location, statistics and tags
Tags, forms, sequences	Read resources, subscribe to a form or sequence, tag and untag
Sequence emails	Read, create, edit and delete individual emails
Snippets and templates	Reusable content CRUD supported by the API; list email templates
Posts and segments	Read published posts and segment metadata
Purchases and bulk	OAuth-only purchase endpoints and asynchronous bulk jobs
Webhook endpoints	Signed endpoints, secret rotation and previous-secret revocation
Legacy webhooks	Older webhook API preserved separately

The API does not provide all Kit UI actions. This package does not promise visual automation editing, automatic duplication of a designed broadcast, a block editor, a webhook receiver, a hosted scheduler or a browser session. A successful bulk submission is not proof that its asynchronous job has completed.

What was actually checked

Check	Status for 3.0.0
Official API snapshot	83 operations, pinned on 2026-10-02
Real local MCP discovery	85 tools, or 38 with read-only enabled
Behavior and shared CLI	38 checks passed against controlled HTTP fixtures
TypeScript	Build and typecheck passed
Production dependency audit	Zero findings at review time
Live account reads and writes	Pending a configured v4 key or authorized OAuth session
Actual Claude Desktop installation	Pending a GUI check; archive and protocol checked separately
Matched MCP versus CLI model-token task	Measured against 2.0.3 in README section 7

Fixture tests check request construction and guards. They do not establish that a particular Kit account or email template accepts a live write. Release artifact checks are reported in the release notes when completed.

2. Quick install

Install Node.js 22 or newer, then:

npm install -g @thenavidm/kit-mcp-cli@latest
kit-cli --version
kit-cli
kit-cli list-broadcasts --help
kit-cli schema create-broadcast
kit-cli login

Discovery, help and schemas work before authentication. login prints setup instructions. It does not open a browser, exchange an OAuth code or save credentials. Configure a v4 API key privately as KIT_API_KEY, then:

kit-cli doctor
kit-cli doctor --network
kit-cli get-account --agent
kit-cli list-broadcasts --per-page 10 --agent --select broadcasts.id,broadcasts.subject,pagination

The local doctor checks configuration. The network doctor reads the default account and reports authentication success without returning account details. It never sends a newsletter or changes subscribers.

For a single invocation without a global install:

npx -y --package @thenavidm/kit-mcp-cli@latest kit-cli tools

INSTALL.md covers Node/PATH on macOS, Windows and Linux, private account setup, every client, updates and removal. No .env file is loaded automatically.

3. Set up Kit access

Personal v4 API key

Open Kit's Developer settings, click Add a new key, name it and save the value privately when shown. Kit does not let you view that value again afterwards. Set KIT_API_KEY in your local shell or client settings. The server sends it in X-Kit-Api-Key, never a URL query string. Old v3 API secrets are not interchangeable.

Kit documents 120 requests over a rolling 60 seconds per API key and 600 for OAuth API access. The official hosted MCP separately documents 120/minute per token. This wrapper spaces calls per account by 550 ms for keys and 110 ms for OAuth. Other processes using the same credential also count against Kit's limits.

OAuth for full endpoint eligibility

Bulk and purchase endpoints in the tool table are marked OAuth-only. Create your own Kit app and enable API access, then implement the official OAuth authorization flow or Kit's Node example. Keep the app's secret on a private confidential backend. Use the callback URI exactly as registered, a cryptographically random state verified on callback, and HTTPS for a hosted callback.

The current authorization and token endpoints are https://api.kit.com/v4/oauth/authorize and https://api.kit.com/v4/oauth/token. There is no built-in OAuth consent service in this package. The old source's app.kit.com/oauth/token examples are obsolete. Follow Kit's current registered-app instructions; do not invent unsupported fine-grained OAuth scopes from operation-schema security labels.

A private token file can contain:

{
  "access_token": "YOUR_OAUTH_ACCESS_TOKEN",
  "refresh_token": "YOUR_OAUTH_REFRESH_TOKEN",
  "client_id": "YOUR_OWN_KIT_APP_CLIENT_ID",
  "client_secret": "YOUR_OWN_KIT_APP_CLIENT_SECRET",
  "created_at": 1790899200,
  "expires_in": 7200
}

These are placeholders; use actual issued expiry metadata. Point KIT_TOKENS_FILE at an absolute private path outside the checkout. It must be a regular JSON file, at most 64 KB; symlinks are refused. Restrict access to your OS user. If expiry metadata is available, refresh happens one minute before expiry. Concurrent refreshes within the same process are deduplicated. Updated tokens are written atomically with mode 0600. On Windows, protect the enclosing folder using user-only ACLs; POSIX mode bits are not a complete Windows access policy.

Alternatively set KIT_ACCESS_TOKEN, KIT_REFRESH_TOKEN, KIT_CLIENT_ID and KIT_CLIENT_SECRET privately. Without a token file, refresh state lasts only in that process. Without refresh credentials, renew an expired access token yourself. An OAuth access token takes precedence over an API key for the selected account.

4. Connect your client

The full commands and private configurations are in INSTALL.md. Common registrations, after privately configuring account credentials:

claude mcp add --scope user kit -- npx -y @thenavidm/kit-mcp-cli@latest
claude mcp list
codex mcp add kit -- npx -y @thenavidm/kit-mcp-cli@latest
codex mcp list

Claude Desktop can install the .mcpb release or use manual JSON. Cursor, Windsurf and Gemini CLI use their user MCP settings; VS Code supports secure prompted inputs; Zed uses context_servers. Local Cline/Roo-style clients accept the same stdio command through their MCP setup UI. A local stdio process is not a public HTTP connector for ChatGPT on the web. Kit's official hosted MCP is the appropriate remote option there.

Desktop settings accept a sensitive API key or a private OAuth token-file path. API-key authentication cannot use OAuth-only bulk and purchase endpoints. Custom extension availability depends on your installed host and organization policy.

Let an agent guide setup

Help me install Kit MCP Server & CLI using INSTALL.md. Check Node and the binary, let me configure my account credentials privately, then run discovery and doctor --network. Do not send email or change subscribers during setup.

For shell agents, make SKILL.md available through the client's supported skills location. npm installation does not register the skill automatically.

5. Check it works

kit-cli --version
kit-cli doctor
kit-cli doctor --network
kit-cli get-account --agent
kit-cli list-broadcasts --per-page 1 --agent

Local discovery works without credentials. The local doctor checks configuration; the network doctor reads account identity without returning private account details. It never sends email or changes subscribers. A successful read does not establish every endpoint's eligibility or template compatibility.

6. Output, flags and exit codes

Tool names become dashed commands: get_broadcast becomes kit-cli get-broadcast. Both exact underscore tool names and dashed forms are accepted. Argument names have dashed aliases: broadcast_id is --broadcast-id. Use help and schema to discover each operation's current input.

kit-cli tools
kit-cli get-broadcast --help
kit-cli schema get-broadcast
kit-cli get-broadcast --broadcast-id 123 --agent

Flag	Behavior
`--help`	Current schema-derived arguments and defaults
`--json`	Structured JSON output
`--compact`	Compact JSON on one line
`--agent`	Compact JSON and no prompts; never confirms a write
`--select a,b.c`	Keep selected fields; dotted paths descend through objects and arrays
`--no-color`	No terminal colors
`--no-input`	No interactive prompts
`--yes`	Accepted for scripts written for other tools; never substitutes for `--confirm`
`--confirm`	Explicit confirmation for the requested guarded operation
`--account NAME`	Select a configured local account on API tools
`--payload JSON`	Complete request body as one JSON object
`--payload-file PATH`	Complete request body from a local regular JSON file, at most 5 MB

Body flags and payload/payload_file are mutually exclusive. Path and query flags remain separate. Objects take JSON; array flags repeat once per array item. Do not pass an array to a flag that expects a single item:

kit-cli list-subscribers --include tags --include stats --per-page 10 --agent
kit-cli create-broadcast --payload-file /absolute/private/path/newsletter.json --confirm --agent

Null is meaningful

A shell flag such as --send-at null is the string null, not JSON null. Use the complete body form to return a scheduled broadcast to draft:

kit-cli update-broadcast --broadcast-id 123 --payload '{"send_at":null}' --confirm --agent

The same applies to nullable text, thumbnail and other nullable fields. In an MCP call, send an actual JSON null. Avoid mixing the nullable complete body with individual body flags.

Exit codes

Code	Meaning	A script's next step
0	Success	Use the returned data
1	Unexpected error	Report it with the command that caused it
2	Usage, validation or safety refusal, an unknown command or a hidden write	Correct inputs or obtain the requested authorization
3	Not found	Verify the resource ID
4	Authentication or permission failure	Check key, OAuth state or endpoint eligibility
5	Other API or transport failure	Inspect account state before repeating a write
7	Rate limit	Wait; mutating requests are not automatically retried
10	Missing or invalid local configuration	Repair private configuration

Errors are JSON on stderr. On success, field selection shapes output only; it does not limit Kit's original response or its API processing.

7. MCP or CLI and token cost

Surface	How it runs	Suitable for
`kit-mcp`	Local stdio server launched by an MCP client	Natural language account work in a compatible AI app
`kit-cli`	Schema-derived commands with machine-readable output	Scripts, CI and agents with shell access
`kit-3.0.0.mcpb`	Local MCP server with bundled production dependencies	Claude Desktop custom extensions
Official Kit MCP	Hosted `https://app.kit.com/mcp` with Kit OAuth	Remote connections and browser-only AI clients

Slipway builds the MCP server, over stdio or --http, and the CLI from each tool's one definition, with the same schemas, validation, handlers and safety guards. Separate handwritten CLI request logic cannot drift from the MCP path.

An MCP client may send tool schemas or deferred tool names into model context. A shell agent instead needs the skill, help, commands and results. Both consume tokens; neither surface guarantees lower total cost for every task.

kit-cli with no arguments lists commands. kit-mcp with no arguments starts stdio and does not print a banner. Avoid launching an interactive banner on an MCP server's stdout.

Measuring the context and task cost

Measured on 2026-10-05 against 2.0.3, with Claude Code 2.1.286 on Claude Opus 5.5 (one short prompt with and without the server connected, the difference read from the API's own usage figures) and Codex 0.159.3 on gpt-6.1-sol:

Cost	2.0.3	3.0.0
Claude Code, every tool loaded, every message	55,242	46,158
Claude Code's default, tool search, every message	1,516	1,518
`SKILL.md`, read once	1,430	1,566
Codex over the CLI, one task, median of five	84,497	83,147
Codex over MCP, the same task, median of five	77,336	77,462

The task was "find the command that tags a subscriber, and the flags it requires". Every tool loaded costs less because parts that several tools repeated are written once. Over the CLI, every 3.0.0 run asked which, a 568-character answer, where every 2.0.3 run read the 6,245-character command list. Over MCP, Codex prints only part of a tool list this long and 3.0.0's part takes a few more tokens to say, so the median rose by 126, while two 3.0.0 runs answered from a shorter printout, against one 2.0.3 run, and the average fell from 70,923 to 64,738. SKILL.md costs 136 more because it says how approval works over MCP and how which finds a command, and lists every exit code.

Tool-list bytes or characters divided by four are not API usage, and no other offering was measured.

8. Every tool and argument

The following catalog is generated from the actual tools/list result. Body-required fields are enforced within payload or individual body arguments at execution; path/query requirements appear in each input schema. schema <command> is the exact machine-readable reference. OAuth-only labels come from the pinned operation security definitions.

Tool	API	Mode	OAuth only
`get_account`	`GET /v4/account`	Read	No
`list_colors`	`GET /v4/account/colors`	Read	No
`update_colors`	`PUT /v4/account/colors`	Write	No
`get_creator_profile`	`GET /v4/account/creator_profile`	Read	No
`get_email_stats`	`GET /v4/account/email_stats`	Read	No
`get_growth_stats`	`GET /v4/account/growth_stats`	Read	No
`list_broadcasts`	`GET /v4/broadcasts`	Read	No
`create_broadcast`	`POST /v4/broadcasts`	Write, confirms	No
`list_broadcast_stats`	`GET /v4/broadcasts/stats`	Read	No
`get_broadcast_clicks`	`GET /v4/broadcasts/{broadcast_id}/clicks`	Read	No
`get_broadcast_stats`	`GET /v4/broadcasts/{broadcast_id}/stats`	Read	No
`delete_broadcast`	`DELETE /v4/broadcasts/{id}`	Write, confirms	No
`get_broadcast`	`GET /v4/broadcasts/{id}`	Read	No
`update_broadcast`	`PUT /v4/broadcasts/{id}`	Write, confirms	No
`bulk_create_custom_fields`	`POST /v4/bulk/custom_fields`	Write	Yes
`bulk_update_subscriber_custom_field_values`	`POST /v4/bulk/custom_fields/subscribers`	Write, confirms	Yes
`list_custom_fields`	`GET /v4/custom_fields`	Read	No
`create_custom_field`	`POST /v4/custom_fields`	Write	No
`delete_custom_field`	`DELETE /v4/custom_fields/{id}`	Write, confirms	No
`update_custom_field`	`PUT /v4/custom_fields/{id}`	Write	No
`list_email_templates`	`GET /v4/email_templates`	Read	No
`bulk_add_subscribers_to_forms`	`POST /v4/bulk/forms/subscribers`	Write, confirms	Yes
`list_forms`	`GET /v4/forms`	Read	No
`list_subscribers_for_form`	`GET /v4/forms/{form_id}/subscribers`	Read	No
`add_subscriber_to_form`	`POST /v4/forms/{form_id}/subscribers`	Write, confirms	No
`add_subscriber_to_form_by_id`	`POST /v4/forms/{form_id}/subscribers/{id}`	Write, confirms	No
`list_posts`	`GET /v4/posts`	Read	No
`get_post`	`GET /v4/posts/{id}`	Read	No
`list_purchases`	`GET /v4/purchases`	Read	Yes
`create_purchase`	`POST /v4/purchases`	Write, confirms	Yes
`get_purchase`	`GET /v4/purchases/{id}`	Read	Yes
`list_segments`	`GET /v4/segments`	Read	No
`list_sequence_emails`	`GET /v4/sequences/{sequence_id}/emails`	Read	No
`create_sequence_email`	`POST /v4/sequences/{sequence_id}/emails`	Write, confirms	No
`delete_sequence_email`	`DELETE /v4/sequences/{sequence_id}/emails/{id}`	Write, confirms	No
`get_sequence_email`	`GET /v4/sequences/{sequence_id}/emails/{id}`	Read	No
`update_sequence_email`	`PUT /v4/sequences/{sequence_id}/emails/{id}`	Write, confirms	No
`list_sequences`	`GET /v4/sequences`	Read	No
`create_sequence`	`POST /v4/sequences`	Write, confirms	No
`delete_sequence`	`DELETE /v4/sequences/{id}`	Write, confirms	No
`get_sequence`	`GET /v4/sequences/{id}`	Read	No
`update_sequence`	`PUT /v4/sequences/{id}`	Write, confirms	No
`list_subscribers_for_sequence`	`GET /v4/sequences/{sequence_id}/subscribers`	Read	No
`add_subscriber_to_sequence`	`POST /v4/sequences/{sequence_id}/subscribers`	Write, confirms	No
`add_subscriber_to_sequence_by_id`	`POST /v4/sequences/{sequence_id}/subscribers/{id}`	Write, confirms	No
`list_snippets`	`GET /v4/snippets`	Read	No
`create_snippet`	`POST /v4/snippets`	Write, confirms	No
`get_snippet`	`GET /v4/snippets/{id}`	Read	No
`update_snippet`	`PUT /v4/snippets/{id}`	Write, confirms	No
`bulk_create_subscribers`	`POST /v4/bulk/subscribers`	Write, confirms	Yes
`list_subscribers`	`GET /v4/subscribers`	Read	No
`create_subscriber`	`POST /v4/subscribers`	Write, confirms	No
`filter_subscribers`	`POST /v4/subscribers/filter`	Read	No
`get_subscriber`	`GET /v4/subscribers/{id}`	Read	No
`update_subscriber`	`PUT /v4/subscribers/{id}`	Write, confirms	No
`unsubscribe`	`POST /v4/subscribers/{id}/unsubscribe`	Write, confirms	No
`delete_subscriber_location`	`DELETE /v4/subscribers/{subscriber_id}/location`	Write, confirms	No
`update_subscriber_location`	`PATCH /v4/subscribers/{subscriber_id}/location`	Write, confirms	No
`pin_subscriber_location`	`POST /v4/subscribers/{subscriber_id}/location`	Write, confirms	No
`get_subscriber_stats`	`GET /v4/subscribers/{subscriber_id}/stats`	Read	No
`list_subscriber_tags`	`GET /v4/subscribers/{subscriber_id}/tags`	Read	No
`bulk_delete_tags`	`DELETE /v4/bulk/tags`	Write, confirms	Yes
`bulk_create_tags`	`POST /v4/bulk/tags`	Write	Yes
`bulk_remove_tags_from_subscribers`	`DELETE /v4/bulk/tags/subscribers`	Write, confirms	Yes
`bulk_tag_subscribers`	`POST /v4/bulk/tags/subscribers`	Write, confirms	Yes
`list_tags`	`GET /v4/tags`	Read	No
`create_tag`	`POST /v4/tags`	Write	No
`update_tag_name`	`PUT /v4/tags/{id}`	Write	No
`untag_subscriber_by_email`	`DELETE /v4/tags/{tag_id}/subscribers`	Write, confirms	No
`list_subscribers_for_tag`	`GET /v4/tags/{tag_id}/subscribers`	Read	No
`tag_subscriber`	`POST /v4/tags/{tag_id}/subscribers`	Write, confirms	No
`untag_subscriber`	`DELETE /v4/tags/{tag_id}/subscribers/{id}`	Write, confirms	No
`tag_subscriber_by_id`	`POST /v4/tags/{tag_id}/subscribers/{id}`	Write, confirms	No
`list_webhook_endpoints`	`GET /v4/webhook_endpoints`	Read	No
`create_webhook_endpoint`	`POST /v4/webhook_endpoints`	Write, confirms	No
`delete_webhook_endpoint`	`DELETE /v4/webhook_endpoints/{id}`	Write, confirms	No
`get_webhook_endpoint`	`GET /v4/webhook_endpoints/{id}`	Read	No
`update_webhook_endpoint`	`PATCH /v4/webhook_endpoints/{id}`	Write, confirms	No
`revoke_previous_webhook_secret`	`POST /v4/webhook_endpoints/{id}/revoke_previous_secret`	Write, confirms	No
`rotate_webhook_secret`	`POST /v4/webhook_endpoints/{id}/rotate_secret`	Write, confirms	No
`list_webhooks`	`GET /v4/webhooks`	Read	No
`create_webhook`	`POST /v4/webhooks`	Write, confirms	No
`delete_webhook`	`DELETE /v4/webhooks/{id}`	Write, confirms	No
`search_subscribers`	Alias for GET /v4/subscribers with exact email	Read	No
`list_accounts`	Local labels only	Read	No

Shared input rules

Every API tool accepts optional account. Writes accept confirm; the 40 guarded operations require it to be true. Pagination controls are included only on tools whose schema supports cursor pagination. Body tools accept either their individual body fields or payload/payload_file. list_accounts accepts no arguments.

Complete arguments

get_account

Get current account. Read-only.

kit-cli get-account --help

Argument

Type

Required

Meaning

list_colors

List colors. Read-only.

kit-cli list-colors --help

Argument

Type

Required

Meaning

update_colors

Update colors. Reversible configuration write.

kit-cli update-colors --help

Argument	Type	Required	Meaning
`colors`	array	Body	An array of up to 10 color hex codes

get_creator_profile

Get Creator Profile. Read-only.

kit-cli get-creator-profile --help

Argument

Type

Required

Meaning

get_email_stats

Get email stats. Read-only.

kit-cli get-email-stats --help

Argument

Type

Required

Meaning

get_growth_stats

Get growth stats. Read-only.

kit-cli get-growth-stats --help

Argument	Type	Required	Meaning
`ending`	string	No	See the exact input schema.
`starting`	string	No	See the exact input schema.

list_broadcasts

List broadcasts. Read-only.

kit-cli list-broadcasts --help

Argument	Type	Required	Meaning
`after`	schema	No	See the exact input schema.
`before`	schema	No	See the exact input schema.
`include_total_count`	boolean	No	See the exact input schema.
`per_page`	schema	No	See the exact input schema.
`sent_after`	schema	No	See the exact input schema.
`sent_before`	schema	No	See the exact input schema.
`slim`	boolean	No	See the exact input schema.
`status`	string	No	Values: `draft`, `scheduled`, `sending`, `completed`, `aborted`.
`all_pages`	boolean	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	integer	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.

create_broadcast

Create a broadcast. Requires confirmation.

kit-cli create-broadcast --help

Argument	Type	Required	Meaning
`email_template_id`	integer	No	Id of the email template to use. Uses the account's default template if not provided. 'Starting point' template is not supported.
`email_address`	string/null	No	The sending email address to use. Uses the account's sending email address if not provided.
`content`	string	No	The HTML content of the email. On a `Classic` template this is the body, and the template adds the design around it when the broadcast is sent. On a `Starting point` template the design lives in the body, so this is the complete email: keep the wrappers, images, inline styles and Liquid tags, including `{{ unsubscribe_url }}` and `{{ address }}`. Without an unsubscribe link the broadcast can't be sent. A read returns the string that was written, so `GET`, `PUT`, `GET` round-trips, apart from Kit's own "Built with Kit" badge, which a `Starting point` write takes out of the body and re-applies when the email renders. A broadcast built in Kit's editor reads back as Kit's rendered HTML instead, and writing that back replaces its individually-editable blocks with one HTML block. Sending `content` in the same request as a `Starting point` `email_template_id` also needs `allow_starting_point: true`. Omit `content` and name a `Starting point` template in `email_template_id` to create the broadcast with that template's own design.
`description`	string	No	See the exact input schema.
`public`	boolean	No	`true` to publish this broadcast to the web. The broadcast will appear in a newsletter feed on your Creator Profile and Landing Pages.
`published_at`	string	No	The published timestamp to display in ISO8601 format. If no timezone is provided, UTC is assumed.
`send_at`	string/null	No	The scheduled send time for this broadcast in ISO8601 format. If no timezone is provided, UTC is assumed.
`thumbnail_alt`	string/null	No	See the exact input schema.
`thumbnail_url`	string/null	No	See the exact input schema.
`preview_text`	string	No	See the exact input schema.
`subject`	string	Body	See the exact input schema.
`subscriber_filter`	array	No	Filters your subscribers. At this time, we only support using only one filter group type via the API (e.g. `all`, `any`, or `none` but no combinations). If nothing is provided, will default to all of your subscribers.
`allow_starting_point`	boolean	No	Explicitly allow replacing a Starting point template body, as described in Kit’s current content-field documentation. Review the complete rendered HTML first.

Body alternatives: content; email_template_id.

list_broadcast_stats

Get stats for a list of broadcasts. Read-only.

kit-cli list-broadcast-stats --help

Argument	Type	Required	Meaning
`after`	schema	No	See the exact input schema.
`before`	schema	No	See the exact input schema.
`include_total_count`	boolean	No	See the exact input schema.
`per_page`	schema	No	See the exact input schema.
`sent_after`	schema	No	See the exact input schema.
`sent_before`	schema	No	See the exact input schema.
`status`	string	No	Values: `draft`, `scheduled`, `sending`, `completed`, `aborted`.
`all_pages`	boolean	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	integer	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.

get_broadcast_clicks

Get link clicks for a broadcast. Read-only.

kit-cli get-broadcast-clicks --help

Argument	Type	Required	Meaning
`broadcast_id`	schema	Yes	Positive broadcast id.

get_broadcast_stats

Get stats for a broadcast. Read-only.

kit-cli get-broadcast-stats --help

Argument	Type	Required	Meaning
`broadcast_id`	schema	Yes	Positive broadcast id.

delete_broadcast

Delete a broadcast. Requires confirmation.

kit-cli delete-broadcast --help

Argument	Type	Required	Meaning
`broadcast_id`	schema	Yes	Positive broadcast id.

get_broadcast

Get a broadcast. Read-only.

kit-cli get-broadcast --help

Argument	Type	Required	Meaning
`broadcast_id`	schema	Yes	Positive broadcast id.

update_broadcast

Update a broadcast. Requires confirmation.

kit-cli update-broadcast --help

Argument	Type	Required	Meaning
`broadcast_id`	schema	Yes	Positive broadcast id.
`email_template_id`	integer	No	Id of the email template to use. Uses the account's default template if not provided. 'Starting point' template is not supported.
`email_address`	string/null	No	The sending email address to use. Uses the account's sending email address if not provided.
`content`	string	No	The HTML content of the email. On a `Classic` template this is the body, and the template adds the design around it when the broadcast is sent. On a `Starting point` template the design lives in the body, so this is the complete email: keep the wrappers, images, inline styles and Liquid tags, including `{{ unsubscribe_url }}` and `{{ address }}`. Without an unsubscribe link the broadcast can't be sent. A read returns the string that was written, so `GET`, `PUT`, `GET` round-trips, apart from Kit's own "Built with Kit" badge, which a `Starting point` write takes out of the body and re-applies when the email renders. A broadcast built in Kit's editor reads back as Kit's rendered HTML instead, and writing that back replaces its individually-editable blocks with one HTML block. Sending `content` in the same request as a `Starting point` `email_template_id` also needs `allow_starting_point: true`.
`description`	string	No	See the exact input schema.
`public`	boolean	No	`true` to publish this broadcast to the web. The broadcast will appear in a newsletter feed on your Creator Profile and Landing Pages.
`published_at`	string	No	The published timestamp to display in ISO8601 format. If no timezone is provided, UTC is assumed.
`send_at`	string/null	No	The scheduled send time for this broadcast in ISO8601 format. If no timezone is provided, UTC is assumed.
`thumbnail_alt`	string/null	No	See the exact input schema.
`thumbnail_url`	string/null	No	See the exact input schema.
`preview_text`	string	No	See the exact input schema.
`subject`	string	No	See the exact input schema.
`subscriber_filter`	array	No	Filters your subscribers. At this time, we only support using only one filter group type via the API (e.g. `all`, `any`, or `none` but no combinations). If nothing is provided, will default to all of your subscribers.
`allow_starting_point`	boolean	No	Explicitly allow replacing a Starting point template body, as described in Kit’s current content-field documentation. Review the complete rendered HTML first.

bulk_create_custom_fields

Bulk create custom fields. OAuth-only. Reversible configuration write.

kit-cli bulk-create-custom-fields --help

Argument	Type	Required	Meaning
`custom_fields`	array	Body	See the exact input schema.
`callback_url`	string/null	No	See the exact input schema.

bulk_update_subscriber_custom_field_values

Bulk update subscriber custom field values. OAuth-only. Requires confirmation.

kit-cli bulk-update-subscriber-custom-field-values --help

Argument	Type	Required	Meaning
`custom_field_values`	array	Body	See the exact input schema.
`callback_url`	schema	Body	See the exact input schema.

list_custom_fields

List custom fields. Read-only.

kit-cli list-custom-fields --help

Argument	Type	Required	Meaning
`after`	schema	No	See the exact input schema.
`before`	schema	No	See the exact input schema.
`include_total_count`	boolean	No	See the exact input schema.
`per_page`	schema	No	See the exact input schema.
`all_pages`	boolean	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	integer	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.

create_custom_field

Create a custom field. Reversible configuration write.

kit-cli create-custom-field --help

Argument	Type	Required	Meaning
`label`	string	Body	See the exact input schema.

delete_custom_field

Delete custom field. Requires confirmation.

kit-cli delete-custom-field --help

Argument	Type	Required	Meaning
`custom_field_id`	schema	Yes	Positive custom field id.

update_custom_field

Update a custom field. Reversible configuration write.

kit-cli update-custom-field --help

Argument	Type	Required	Meaning
`custom_field_id`	schema	Yes	Positive custom field id.
`label`	string	Body	See the exact input schema.

list_email_templates

List email templates. Read-only.

kit-cli list-email-templates --help

Argument	Type	Required	Meaning
`after`	schema	No	See the exact input schema.
`before`	schema	No	See the exact input schema.
`include_total_count`	boolean	No	See the exact input schema.
`per_page`	schema	No	See the exact input schema.
`all_pages`	boolean	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	integer	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.

bulk_add_subscribers_to_forms

Bulk add subscribers to forms. OAuth-only. Requires confirmation.

kit-cli bulk-add-subscribers-to-forms --help

Argument	Type	Required	Meaning
`additions`	array	Body	See the exact input schema.
`callback_url`	string/null	No	See the exact input schema.

list_forms

List forms. Read-only.

kit-cli list-forms --help

Argument	Type	Required	Meaning
`after`	schema	No	See the exact input schema.
`before`	schema	No	See the exact input schema.
`include_total_count`	boolean	No	See the exact input schema.
`per_page`	schema	No	See the exact input schema.
`status`	string/null	No	Values: `active`, `archived`, `trashed`, `all`.
`type`	schema	No	See the exact input schema.
`include`	string	No	See the exact input schema.
`all_pages`	boolean	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	integer	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.

list_subscribers_for_form

List subscribers for a form. Read-only.

kit-cli list-subscribers-for-form --help

Argument	Type	Required	Meaning
`added_after`	string/null	No	See the exact input schema.
`added_before`	string/null	No	See the exact input schema.
`after`	schema	No	See the exact input schema.
`before`	schema	No	See the exact input schema.
`created_after`	string/null	No	See the exact input schema.
`created_before`	string/null	No	See the exact input schema.
`form_id`	schema	Yes	Positive form id.
`include_total_count`	boolean	No	See the exact input schema.
`per_page`	schema	No	See the exact input schema.
`slim`	boolean	No	See the exact input schema.
`status`	string	No	Values: `active`, `inactive`, `bounced`, `complained`, `cancelled`, `all`.
`all_pages`	boolean	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	integer	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.

add_subscriber_to_form

Add subscriber to form by email address. Requires confirmation.

kit-cli add-subscriber-to-form --help

Argument	Type	Required	Meaning
`form_id`	schema	Yes	Positive form id.
`email_address`	string	Body	See the exact input schema.
`referrer`	string/null	No	See the exact input schema.

add_subscriber_to_form_by_id

Add subscriber to form. Requires confirmation.

kit-cli add-subscriber-to-form-by-id --help

Argument	Type	Required	Meaning
`form_id`	schema	Yes	Positive form id.
`subscriber_id`	schema	Yes	Positive subscriber id.
`referrer`	string	Body	See the exact input schema.

list_posts

List posts. Read-only.

kit-cli list-posts --help

Argument	Type	Required	Meaning
`after`	schema	No	See the exact input schema.
`before`	schema	No	See the exact input schema.
`include_content`	boolean	No	See the exact input schema.
`include_total_count`	boolean	No	See the exact input schema.
`per_page`	schema	No	See the exact input schema.
`all_pages`	boolean	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	integer	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.

get_post

Get a post. Read-only.

kit-cli get-post --help

Argument	Type	Required	Meaning
`post_id`	schema	Yes	Positive post id.

list_purchases

List purchases. OAuth-only. Read-only.

kit-cli list-purchases --help

Argument	Type	Required	Meaning
`after`	schema	No	See the exact input schema.
`before`	schema	No	See the exact input schema.
`include_total_count`	boolean	No	See the exact input schema.
`per_page`	schema	No	See the exact input schema.
`all_pages`	boolean	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	integer	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.

create_purchase

Create a purchase. OAuth-only. Requires confirmation.

kit-cli create-purchase --help

Argument	Type	Required	Meaning
`purchase`	object	Body	See the exact input schema.

get_purchase

Get a purchase. OAuth-only. Read-only.

kit-cli get-purchase --help

Argument	Type	Required	Meaning
`purchase_id`	schema	Yes	Positive purchase id.

list_segments

List segments. Read-only.

kit-cli list-segments --help

Argument	Type	Required	Meaning
`after`	schema	No	See the exact input schema.
`before`	schema	No	See the exact input schema.
`include_total_count`	boolean	No	See the exact input schema.
`per_page`	schema	No	See the exact input schema.
`all_pages`	boolean	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	integer	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.

list_sequence_emails

List sequence emails. Read-only.

kit-cli list-sequence-emails --help

Argument	Type	Required	Meaning
`after`	schema	No	See the exact input schema.
`before`	schema	No	See the exact input schema.
`include_content`	schema	No	See the exact input schema.
`include_total_count`	boolean	No	See the exact input schema.
`per_page`	schema	No	See the exact input schema.
`sequence_id`	schema	Yes	Positive sequence id.
`include`	string	No	See the exact input schema.
`all_pages`	boolean	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	integer	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.

create_sequence_email

Create a sequence email. Requires confirmation.

kit-cli create-sequence-email --help

Argument	Type	Required	Meaning
`sequence_id`	schema	Yes	Positive sequence id.
`subject`	string	Body	Subject line of the email
`preview_text`	string/null	No	Preview text shown in email clients before the email is opened
`content`	string/null	No	HTML body content of the email
`delay_value`	integer	Body	Number of days or hours to wait before sending this email after the previous one
`delay_unit`	string	Body	Unit for the send delay. Use `days` for schedule-aware delivery, `hours` for a fixed hourly delay Values: `days`, `hours`.
`email_template_id`	integer/null	No	ID of the email template to use for layout and styling
`published`	boolean	No	Whether the email is active and will be sent to subscribers. Defaults to `false` (draft)
`send_days`	array/null	No	Days of the week this email may be sent. Defaults to all 7 days (inherits the sequence schedule). Pass a subset to restrict delivery, or `null` to reset to all days
`position`	integer/null	No	Zero-based position of the email in the sequence. Assigned automatically after the last email if omitted

delete_sequence_email

Delete a sequence email. Requires confirmation.

kit-cli delete-sequence-email --help

Argument	Type	Required	Meaning
`email_id`	schema	Yes	Positive email id.
`sequence_id`	schema	Yes	Positive sequence id.

get_sequence_email

Get a sequence email. Read-only.

kit-cli get-sequence-email --help

Argument	Type	Required	Meaning
`email_id`	schema	Yes	Positive email id.
`sequence_id`	schema	Yes	Positive sequence id.
`include`	string	No	See the exact input schema.

update_sequence_email

Update a sequence email. Requires confirmation.

kit-cli update-sequence-email --help

Argument	Type	Required	Meaning
`email_id`	schema	Yes	Positive email id.
`sequence_id`	schema	Yes	Positive sequence id.
`subject`	string	No	New subject line for the email
`preview_text`	string/null	No	New preview text shown in email clients before the email is opened
`content`	string/null	No	New HTML body content of the email
`delay_value`	integer	No	New delay value
`delay_unit`	string	No	New delay unit. Use `days` for schedule-aware delivery, `hours` for a fixed hourly delay Values: `days`, `hours`.
`email_template_id`	integer/null	No	New email template ID for layout and styling. Pass `null` to clear
`published`	boolean	No	Pass `true` to publish a draft email or `false` to unpublish it
`send_days`	array/null	No	Days of the week this email may be sent. Pass a subset to restrict delivery, or `null` to reset to all days (inherits the sequence schedule)
`position`	integer/null	No	New zero-based position of the email in the sequence

list_sequences

List sequences. Read-only.

kit-cli list-sequences --help

Argument	Type	Required	Meaning
`after`	schema	No	See the exact input schema.
`before`	schema	No	See the exact input schema.
`include_total_count`	boolean	No	See the exact input schema.
`per_page`	schema	No	See the exact input schema.
`include`	string	No	See the exact input schema.
`all_pages`	boolean	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	integer	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.

create_sequence

Create a sequence. Requires confirmation.

kit-cli create-sequence --help

Argument	Type	Required	Meaning
`name`	string	No	The name of the sequence.
`email_address`	string	No	The sending email address to use. Uses the account's sending email address if not provided.
`email_template_id`	integer	No	Id of the email template to use.
`send_days`	array	No	The days of the week to send the sequence on. Must be one of: `monday`, `tuesday`, `wednesday`, `thursday`, `friday`, `saturday`, `sunday`.
`send_hour`	integer	No	The hour of the day to send the sequence at. Must be an integer between 0 and 23.
`time_zone`	string	No	The timezone to use for the sequence. Must be a valid IANA timezone string.
`active`	boolean	No	`true` to activate the sequence, `false` to deactivate it.
`repeat`	boolean	No	When `true`, subscribers can restart the sequence multiple times.
`hold`	boolean	No	When `true`, subscribers added via Visual Automations stay in the sequence after receiving the last email.
`exclude_subscriber_sources`	array	No	The subscriber sources to exclude from the sequence.

delete_sequence

Delete a sequence. Requires confirmation.

kit-cli delete-sequence --help

Argument	Type	Required	Meaning
`sequence_id`	schema	Yes	Positive sequence id.

get_sequence

Get a sequence. Read-only.

kit-cli get-sequence --help

Argument	Type	Required	Meaning
`sequence_id`	schema	Yes	Positive sequence id.
`include`	string	No	See the exact input schema.

update_sequence

Update a sequence. Requires confirmation.

kit-cli update-sequence --help

Argument	Type	Required	Meaning
`sequence_id`	schema	Yes	Positive sequence id.
`name`	string	No	The name of the sequence.
`email_address`	string	No	The sending email address to use. Uses the account's sending email address if not provided.
`email_template_id`	integer	No	Id of the email template to use.
`send_days`	array	No	The days of the week to send the sequence on. Must be one of: `monday`, `tuesday`, `wednesday`, `thursday`, `friday`, `saturday`, `sunday`.
`send_hour`	integer	No	The hour of the day to send the sequence at. Must be an integer between 0 and 23.
`time_zone`	string	No	The timezone to use for the sequence. Must be a valid IANA timezone string.
`active`	boolean	No	`true` to activate the sequence, `false` to deactivate it.
`repeat`	boolean	No	When `true`, subscribers can restart the sequence multiple times.
`hold`	boolean	No	When `true`, subscribers added via Visual Automations stay in the sequence after receiving the last email.
`exclude_subscriber_sources`	array	No	The subscriber sources to exclude from the sequence.

list_subscribers_for_sequence

List subscribers for a sequence. Read-only.

kit-cli list-subscribers-for-sequence --help

Argument	Type	Required	Meaning
`added_after`	string/null	No	See the exact input schema.
`added_before`	string/null	No	See the exact input schema.
`after`	schema	No	See the exact input schema.
`before`	schema	No	See the exact input schema.
`created_after`	string/null	No	See the exact input schema.
`created_before`	string/null	No	See the exact input schema.
`include_total_count`	boolean	No	See the exact input schema.
`per_page`	schema	No	See the exact input schema.
`sequence_id`	schema	Yes	Positive sequence id.
`status`	string	No	Values: `active`, `inactive`, `bounced`, `complained`, `cancelled`, `all`.
`all_pages`	boolean	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	integer	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.

add_subscriber_to_sequence

Add subscriber to sequence by email address. Requires confirmation.

kit-cli add-subscriber-to-sequence --help

Argument	Type	Required	Meaning
`sequence_id`	schema	Yes	Positive sequence id.
`email_address`	string	Body	See the exact input schema.

add_subscriber_to_sequence_by_id

Add subscriber to sequence. Requires confirmation.

kit-cli add-subscriber-to-sequence-by-id --help

Argument	Type	Required	Meaning
`subscriber_id`	schema	Yes	Positive subscriber id.
`sequence_id`	schema	Yes	Positive sequence id.

list_snippets

List snippets. Read-only.

kit-cli list-snippets --help

Argument	Type	Required	Meaning
`after`	schema	No	See the exact input schema.
`archived`	schema	No	See the exact input schema.
`before`	schema	No	See the exact input schema.
`include_content`	boolean	No	See the exact input schema.
`include_total_count`	boolean	No	See the exact input schema.
`per_page`	schema	No	See the exact input schema.
`snippet_type`	schema	No	See the exact input schema.
`all_pages`	boolean	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	integer	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.

create_snippet

Create a snippet. Requires confirmation.

kit-cli create-snippet --help

Argument

Type

Required

Meaning

get_snippet

Get a snippet. Read-only.

kit-cli get-snippet --help

Argument	Type	Required	Meaning
`snippet_id`	schema	Yes	Positive snippet id.

update_snippet

Update a snippet. Requires confirmation.

kit-cli update-snippet --help

Argument	Type	Required	Meaning
`snippet_id`	schema	Yes	Positive snippet id.

bulk_create_subscribers

Bulk create subscribers. OAuth-only. Requires confirmation.

kit-cli bulk-create-subscribers --help

Argument	Type	Required	Meaning
`subscribers`	array	Body	See the exact input schema.
`callback_url`	string/null	No	See the exact input schema.

list_subscribers

List subscribers. Read-only.

kit-cli list-subscribers --help

Argument	Type	Required	Meaning
`after`	string/null	No	See the exact input schema.
`before`	string/null	No	See the exact input schema.
`created_after`	string	No	See the exact input schema.
`created_before`	string	No	See the exact input schema.
`email_address`	string	No	See the exact input schema.
`include`	string	No	See the exact input schema.
`include_total_count`	boolean	No	See the exact input schema.
`per_page`	number/null	No	See the exact input schema.
`slim`	boolean	No	See the exact input schema.
`sort_field`	string	No	Values: `id`, `created_at`, `updated_at`, `cancelled_at`, `canceled_at`, `engagement__sent`, `engagement__opens`, `engagement__clicks`, `engagement__open_rate`, `engagement__click_rate`.
`sort_order`	string	No	Values: `asc`, `desc`.
`status`	string	No	Values: `active`, `inactive`, `bounced`, `complained`, `cancelled`, `all`.
`updated_after`	string	No	See the exact input schema.
`updated_before`	string	No	See the exact input schema.
`all_pages`	boolean	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	integer	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.

create_subscriber

Create a subscriber. Requires confirmation.

kit-cli create-subscriber --help

Argument	Type	Required	Meaning
`first_name`	string/null	No	See the exact input schema.
`email_address`	string	Body	See the exact input schema.
`state`	string/null	No	Create subscriber in this state (`active`, `bounced`, `cancelled`, `complained` or `inactive`). Defaults to `active`. Values: `active`, `cancelled`, `bounced`, `complained`, `inactive`.
`fields`	object	No	Custom field values keyed by the custom field's `key` (e.g. `last_name`, not `Last Name`). Unknown keys are ignored and reported in the response `warnings` array.

filter_subscribers

Filter subscribers by engagement, sign-up date, state, and tags. Read-only.

kit-cli filter-subscribers --help

Argument	Type	Required	Meaning
`counting_mode`	string	No	Controls how engagement-filter count thresholds are tallied. `raw` (default) counts every event : five opens of the same email = five. `unique_email` counts distinct emails on which the action occurred : five opens of the same email = one. Applies to every engagement filter (opens, clicks, sent, delivered) in the request; ignored for other filter types. Values: `raw`, `unique_email`.
`all`	array	Body	Array of filter conditions where ALL must be met (AND logic)
`include`	array	No	Optional. Array of `{ type, ...config }` objects naming additional fields to embed on each subscriber row. Valid types: `attribution`, `tags`, `location`, `canceled_at`, `stats`, `custom_fields`. The `stats` type accepts an optional `range: { start, end }` (YYYY-MM-DD dates, defaulting to the last 90 days). The `custom_fields` type adds a `fields` object with all account custom field values (null for fields the subscriber has not set).
`sort_field`	string	No	Field to order results by. Base columns (`id`, `first_name`, `email_address`, `created_at`) order by that subscriber attribute. `engagement__` orders by an engagement stat over the trailing 90 days: counts (`sent`, `opens`, `clicks`) and rates (`open_rate`, `click_rate`); subscribers with no sends order as 0. `location__distance` orders by great-circle distance and requires a `location` filter in the same request : its `latitude`/`longitude` supply the origin, and subscribers without a primary location are excluded. Distance defaults to nearest-first (`sort_order` defaults to `asc` for this field); pass `sort_order=desc` for farthest-first. Values: `id`, `first_name`, `email_address`, `created_at`, `engagement__sent`, `engagement__opens`, `engagement__clicks`, `engagement__open_rate`, `engagement__click_rate`, `location__distance`. Default: `"created_at"`.
`sort_order`	string	No	Sort direction (default: desc). Values: `asc`, `desc`.

get_subscriber

Get a subscriber. Read-only.

kit-cli get-subscriber --help

Argument	Type	Required	Meaning
`subscriber_id`	schema	Yes	Positive subscriber id.

update_subscriber

Update a subscriber. Requires confirmation.

kit-cli update-subscriber --help

Argument	Type	Required	Meaning
`subscriber_id`	schema	Yes	Positive subscriber id.
`first_name`	string/null	No	See the exact input schema.
`email_address`	string	Body	See the exact input schema.
`fields`	object	No	Custom field values keyed by the custom field's `key` (e.g. `last_name`, not `Last Name`). Unknown keys are ignored and reported in the response `warnings` array.

unsubscribe

Unsubscribe subscriber. Requires confirmation.

kit-cli unsubscribe --help

Argument	Type	Required	Meaning
`subscriber_id`	schema	Yes	Positive subscriber id.

delete_subscriber_location

Delete a subscriber's location. Requires confirmation.

kit-cli delete-subscriber-location --help

Argument	Type	Required	Meaning
`subscriber_id`	schema	Yes	Positive subscriber id.

update_subscriber_location

Update a subscriber's pinned location. Requires confirmation.

kit-cli update-subscriber-location --help

Argument	Type	Required	Meaning
`subscriber_id`	schema	Yes	Positive subscriber id.
`location`	object	Body	See the exact input schema.

pin_subscriber_location

Pin a subscriber's location. Requires confirmation.

kit-cli pin-subscriber-location --help

Argument	Type	Required	Meaning
`subscriber_id`	schema	Yes	Positive subscriber id.
`location`	object	Body	See the exact input schema.

get_subscriber_stats

List stats for a subscriber. Read-only.

kit-cli get-subscriber-stats --help

Argument	Type	Required	Meaning
`email_sent_after`	string	No	See the exact input schema.
`email_sent_before`	string	No	See the exact input schema.
`subscriber_id`	schema	Yes	Positive subscriber id.

list_subscriber_tags

List tags for a subscriber. Read-only.

kit-cli list-subscriber-tags --help

Argument	Type	Required	Meaning
`after`	schema	No	See the exact input schema.
`before`	schema	No	See the exact input schema.
`include_total_count`	boolean	No	See the exact input schema.
`per_page`	schema	No	See the exact input schema.
`subscriber_id`	schema	Yes	Positive subscriber id.
`all_pages`	boolean	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	integer	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.

bulk_delete_tags

Bulk delete tags. OAuth-only. Requires confirmation.

kit-cli bulk-delete-tags --help

Argument	Type	Required	Meaning
`tags`	array	Body	Tags to delete, identified by `id`. Batches of 100 or fewer are processed synchronously (200); larger batches are queued and processed asynchronously (202).
`callback_url`	string/null	No	Optional. When the batch is processed asynchronously (more than 100 tags), the results are POSTed to this URL on completion.

bulk_create_tags

Bulk create tags. OAuth-only. Reversible configuration write.

kit-cli bulk-create-tags --help

Argument	Type	Required	Meaning
`tags`	array	Body	See the exact input schema.
`callback_url`	string/null	No	See the exact input schema.

bulk_remove_tags_from_subscribers

Bulk remove tags from subscribers. OAuth-only. Requires confirmation.

kit-cli bulk-remove-tags-from-subscribers --help

Argument

Type

Required

Meaning

bulk_tag_subscribers

Bulk tag subscribers. OAuth-only. Requires confirmation.

kit-cli bulk-tag-subscribers --help

Argument	Type	Required	Meaning
`taggings`	array	Body	See the exact input schema.
`callback_url`	string/null	No	See the exact input schema.

List tags. Read-only.

kit-cli list-tags --help

Argument	Type	Required	Meaning
`after`	schema	No	See the exact input schema.
`before`	schema	No	See the exact input schema.
`include_total_count`	boolean	No	See the exact input schema.
`per_page`	schema	No	See the exact input schema.
`include`	string	No	See the exact input schema.
`all_pages`	boolean	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	integer	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.

create_tag

Create a tag. Reversible configuration write.

kit-cli create-tag --help

Argument	Type	Required	Meaning
`name`	string	Body	See the exact input schema.

update_tag_name

Update tag name. Reversible configuration write.

kit-cli update-tag-name --help

Argument	Type	Required	Meaning
`tag_id`	schema	Yes	Positive tag id.
`name`	string	Body	See the exact input schema.

untag_subscriber_by_email

Remove tag from subscriber by email address. Requires confirmation.

kit-cli untag-subscriber-by-email --help

Argument	Type	Required	Meaning
`tag_id`	schema	Yes	Positive tag id.
`email_address`	string	Yes	See the exact input schema.

list_subscribers_for_tag

List subscribers for a tag. Read-only.

kit-cli list-subscribers-for-tag --help

Argument	Type	Required	Meaning
`after`	schema	No	See the exact input schema.
`before`	schema	No	See the exact input schema.
`created_after`	string/null	No	See the exact input schema.
`created_before`	string/null	No	See the exact input schema.
`include_total_count`	boolean	No	See the exact input schema.
`per_page`	schema	No	See the exact input schema.
`slim`	boolean	No	See the exact input schema.
`status`	string	No	Values: `active`, `inactive`, `bounced`, `complained`, `cancelled`, `all`.
`tag_id`	schema	Yes	Positive tag id.
`tagged_after`	string/null	No	See the exact input schema.
`tagged_before`	string/null	No	See the exact input schema.
`all_pages`	boolean	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	integer	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.

tag_subscriber

Tag a subscriber by email address. Requires confirmation.

kit-cli tag-subscriber --help

Argument	Type	Required	Meaning
`tag_id`	schema	Yes	Positive tag id.
`email_address`	string	Body	See the exact input schema.

untag_subscriber

Remove tag from subscriber. Requires confirmation.

kit-cli untag-subscriber --help

Argument	Type	Required	Meaning
`subscriber_id`	schema	Yes	Positive subscriber id.
`tag_id`	schema	Yes	Positive tag id.

tag_subscriber_by_id

Tag a subscriber. Requires confirmation.

kit-cli tag-subscriber-by-id --help

Argument	Type	Required	Meaning
`subscriber_id`	schema	Yes	Positive subscriber id.
`tag_id`	schema	Yes	Positive tag id.

list_webhook_endpoints

List webhook endpoints. Read-only.

kit-cli list-webhook-endpoints --help

Argument	Type	Required	Meaning
`after`	schema	No	See the exact input schema.
`before`	schema	No	See the exact input schema.
`include_total_count`	boolean	No	See the exact input schema.
`per_page`	schema	No	See the exact input schema.
`status`	string	No	Values: `active`, `disabled`.
`all_pages`	boolean	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	integer	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.

create_webhook_endpoint

Create a webhook endpoint. Requires confirmation.

kit-cli create-webhook-endpoint --help

Argument	Type	Required	Meaning
`url`	string	Body	See the exact input schema.
`events`	array	Body	Event types this endpoint subscribes to (e.g. `subscriber.created`). On update, the list supplied here replaces the endpoint's full subscription list.
`name`	string	No	See the exact input schema.
`description`	string	No	See the exact input schema.
`secret_name`	string	Yes	New private filename under KIT_PRIVATE_DIR. Required before creating/rotating a signing secret; never overwritten.

delete_webhook_endpoint

Delete a webhook endpoint. Requires confirmation.

kit-cli delete-webhook-endpoint --help

Argument	Type	Required	Meaning
`webhook_endpoint_id`	schema	Yes	Positive webhook endpoint id.

get_webhook_endpoint

Get a webhook endpoint. Read-only.

kit-cli get-webhook-endpoint --help

Argument	Type	Required	Meaning
`webhook_endpoint_id`	schema	Yes	Positive webhook endpoint id.

update_webhook_endpoint

Update a webhook endpoint. Requires confirmation.

kit-cli update-webhook-endpoint --help

Argument	Type	Required	Meaning
`webhook_endpoint_id`	schema	Yes	Positive webhook endpoint id.
`name`	string	No	See the exact input schema.
`url`	string	No	See the exact input schema.
`description`	string	No	See the exact input schema.
`status`	string	No	Endpoint status. One of: `active`, `disabled`. Values: `active`, `disabled`.
`events`	array	No	Event types this endpoint subscribes to (e.g. `subscriber.created`). On update, the list supplied here replaces the endpoint's full subscription list.

revoke_previous_webhook_secret

Revoke the previous webhook endpoint secret. Requires confirmation.

kit-cli revoke-previous-webhook-secret --help

Argument	Type	Required	Meaning
`webhook_endpoint_id`	schema	Yes	Positive webhook endpoint id.

rotate_webhook_secret

Rotate a webhook endpoint secret. Requires confirmation.

kit-cli rotate-webhook-secret --help

Argument	Type	Required	Meaning
`webhook_endpoint_id`	schema	Yes	Positive webhook endpoint id.
`force`	boolean	No	Rotating again while a previous rotation's overlap window is still open returns `409` (see the responses below). Pass `true` to rotate anyway, immediately expiring the older secret.
`secret_name`	string	Yes	New private filename under KIT_PRIVATE_DIR. Required before creating/rotating a signing secret; never overwritten.

list_webhooks

List webhooks. Read-only.

kit-cli list-webhooks --help

Argument	Type	Required	Meaning
`after`	schema	No	See the exact input schema.
`before`	schema	No	See the exact input schema.
`include_total_count`	boolean	No	See the exact input schema.
`per_page`	schema	No	See the exact input schema.
`all_pages`	boolean	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	integer	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.

create_webhook

Create a webhook. Requires confirmation.

kit-cli create-webhook --help

Argument	Type	Required	Meaning
`target_url`	string	Body	See the exact input schema.
`event`	object	Body	See the exact input schema.

delete_webhook

Delete a webhook. Requires confirmation.

kit-cli delete-webhook --help

Argument	Type	Required	Meaning
`webhook_id`	schema	Yes	Positive webhook id.

search_subscribers

Find subscribers by exact email. Read-only.

kit-cli search-subscribers --help

Argument	Type	Required	Meaning
`after`	string/null	No	See the exact input schema.
`before`	string/null	No	See the exact input schema.
`created_after`	string	No	See the exact input schema.
`created_before`	string	No	See the exact input schema.
`email_address`	string	Yes	See the exact input schema.
`include`	string	No	See the exact input schema.
`include_total_count`	boolean	No	See the exact input schema.
`per_page`	number/null	No	See the exact input schema.
`slim`	boolean	No	See the exact input schema.
`sort_field`	string	No	Values: `id`, `created_at`, `updated_at`, `cancelled_at`, `canceled_at`, `engagement__sent`, `engagement__opens`, `engagement__clicks`, `engagement__open_rate`, `engagement__click_rate`.
`sort_order`	string	No	Values: `asc`, `desc`.
`status`	string	No	Values: `active`, `inactive`, `bounced`, `complained`, `cancelled`, `all`.
`updated_after`	string	No	See the exact input schema.
`updated_before`	string	No	See the exact input schema.
`all_pages`	boolean	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	integer	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.

list_accounts

List configured accounts. Read-only.

kit-cli list-accounts --help

No arguments.

Draft privately, review, then schedule

A create call defaults to public:false and send_at:null. It creates a private unscheduled draft. It still requires confirmation because it changes account content and can accept delivery fields when explicitly supplied.

kit-cli list-email-templates --agent
kit-cli create-broadcast --subject "This week's creator notes" --content '<p>Write the actual newsletter here.</p>' --confirm --agent --select broadcast.id,broadcast.subject,broadcast.send_at
kit-cli get-broadcast --broadcast-id BROADCAST_ID_FROM_RESULT --agent

Positive IDs are returned by Kit; replace illustrative markers with real IDs. For an existing draft, validate the intended audience and delivery time before the separate confirmed update:

kit-cli update-broadcast --broadcast-id 123 --payload-file /absolute/private/path/schedule.json --confirm --agent

Your private schedule.json contains the ISO timestamp and the audience fields from the current schema, for example send_at with a timezone offset or UTC Z. published_at controls web publication metadata; it is not the email send time. Neither successful creation nor a local confirmation proves delivery. Read the broadcast and statistics afterwards.

Template HTML needs care

The API's content is HTML; it is not Kit's visual editor block tree. Preserve the full email wrapper and required Liquid unsubscribe/address markup when replacing content. Retrieve an existing example and inspect the selected template before updating. Do not replace a whole template with one paragraph if you need its existing branding and legal footer.

Kit's current OpenAPI prose contradicts itself around Starting point templates and required fields. This wrapper accepts a subject plus either content or email_template_id, allows nonempty partial broadcast updates, and exposes the documented allow_starting_point flag. These reviewed corrections are recorded with the snapshot. Starting point behavior remains unverified against a live account, so test with a private unscheduled draft and inspect it in Kit before any send.

Existing broadcasts and click reports

kit-cli list-broadcasts --per-page 10 --agent --select broadcasts.id,broadcasts.subject,pagination
kit-cli get-broadcast-stats --broadcast-id 123 --agent
kit-cli get-broadcast-clicks --broadcast-id 123 --agent

The client does not automatically retry POST, PUT, PATCH or DELETE requests. A timeout can have an unknown outcome. Check the existing draft or scheduled broadcast before repeating a write; sending twice cannot be undone by a retry wrapper.

Subscriber workflows

Find an exact email or read a bounded list, then choose a requested audience change:

kit-cli search-subscribers --email-address reader@example.com --agent
kit-cli list-tags --agent
kit-cli tag-subscriber --tag-id 123 --email-address reader@example.com --confirm --agent
kit-cli list-subscriber-tags --subscriber-id 456 --agent

The .example address is illustrative. Do not add or tag real people without the requested account action. Tagging and form/sequence enrollment may trigger existing Kit automations.

filter_subscribers is a read-only POST with nested all/any filters. Use its current schema and a private JSON body; it is not a v3 page-number endpoint. search_subscribers is an exact-email compatibility alias, not a fuzzy search engine.

Sequences now have their own create/update/delete endpoints and individual email operations. Read their schemas and current delay units before using them. Sequence enrollment can deliver email through existing automation, so it is confirmed even if the API call itself merely adds a subscriber.

Custom field and tag creation are reversible configuration writes, so they do not require --confirm; they still disappear in read-only mode. Deletions, audience changes, snippets that can affect email and purchases are guarded. The tool table labels every operation.

10. Pagination, bulk work and webhooks

Cursor pages

Kit v4 uses after, before, start_cursor and end_cursor, not old v3 numeric page arguments. Default per_page is 500, maximum 1000. Ask for a small page when you only need a sample:

kit-cli list-subscribers --per-page 25 --include-total-count --agent
kit-cli list-subscribers --after END_CURSOR_FROM_RESULT --per-page 25 --agent
kit-cli list-subscribers --all-pages --max-items 1000 --agent

Do not supply both before and after. all_pages traverses forward and refuses before. It stops at max_items (default 1000, maximum 10000) or 100 pages, and refuses repeated cursors. It reduces each page size to the remaining cap so the returned end cursor does not skip unseen records. Aggregated output includes collected, pages, the last pagination object and truncated.

include_total_count must be requested where supported; total count can add API work. max_items without all_pages is a usage error. This is bounded retrieval, not a backup/export guarantee for an entire large account.

OAuth-only bulk

The full API snapshot supplies nested request schemas and endpoint-specific limits. Discover the body and put private batches outside the checkout:

kit-cli schema bulk-create-subscribers
kit-cli bulk-create-subscribers --payload-file /absolute/private/path/subscribers.json --confirm --agent

Some bulk operations require a callback URL. Use HTTPS on a receiver you control and inspect its actual completion notification. The wrapper does not deploy or listen for callbacks. Split payloads according to Kit's current per-endpoint limits and the local 5 MB request cap. Do not retry an asynchronous submission merely because its completion has not arrived yet.

Signed webhooks

The current signed webhook_endpoints family and older webhooks are separate APIs. Prefer signed endpoints for new setups. Discover the accepted event enum from the current schema:

kit-cli schema create-webhook-endpoint
kit-cli create-webhook-endpoint --url https://your-receiver.example/kit --events EVENT_FROM_SCHEMA --secret-name newsletter-hook --confirm --agent

Replace both placeholders with your own endpoint and a supported event. Creation and secret rotation require a new secret_name. Before the remote call, the server reserves that filename exclusively under KIT_PRIVATE_DIR (default ~/.config/kit-mcp-cli/secrets) with mode 0600. Existing files are never overwritten.

Returned signing secrets are redacted from model/CLI output and saved to the private file. The result exposes secret_file, not the secret itself. Configure your own receiver's signature verification privately. The package does not provide a receiver or claim that the endpoint is reachable. Protect private folders with Windows ACLs where applicable.

When rotating, update and verify your receiver before revoking the previous secret. If Kit changed the endpoint but local secret storage failed, inspect the remote endpoint before attempting rotation again. Do not paste signing secrets in an AI chat or public issue.

11. Several private accounts

Set KIT_ACCOUNTS to a private JSON array. Its supported keys are name, api_key, access_token, refresh_token, client_id, client_secret and tokens_file. It replaces the single-account variables:

[
  {"name":"work","api_key":"YOUR_WORK_V4_KEY"},
  {"name":"personal","tokens_file":"/absolute/private/path/personal-kit.json"}
]

Set KIT_DEFAULT_ACCOUNT=work, then:

kit-cli list-accounts --agent
kit-cli list-broadcasts --account work --per-page 10 --agent
kit-cli get-growth-stats --account personal --agent

Names must be unique. list_accounts exposes labels, default choice and auth type only, never credentials or file paths. Guard logs omit account names. Separate processes are still preferable when you need strict account isolation.

12. Writing safely

KIT_READ_ONLY=1 hides every write, leaving 38 reads, and also refuses a direct write invocation. KIT_ALLOW_DESTRUCTIVE=0 leaves tools visible but refuses the 40 guarded audience/delivery/deletion/secret operations. There is no --agent or --yes bypass. Confirmation means permission for the actual user-requested operation, not a blanket license to modify an account.

Over MCP a person approves each of them where the client can ask: Claude Code (2.1.246 and later) shows its own prompt, and a client that can show forms asks with an approval form whose one box starts unticked. Each approval is signed, bound to that exact call and works once. Where a client can do neither, the model's confirm: true counts. KIT_CONFIRM=model makes confirm: true enough everywhere, for an agent with no person to ask.

Seven configuration writes (such as creating a tag or custom field) do not require confirmation. They are still writes and are blocked by read-only mode. Tool annotations describe read, destructive, idempotent and open-world behavior; application prompts remain client-dependent.

GET 429 responses can retry up to two times by default, honoring a bounded delay. GET OAuth 401 can refresh and retry once. All mutating requests have zero automatic retries, including 429 and token expiry. A read-only filter POST also has no automatic retry. Treat service data as data, not instructions to execute an unrelated operation.

13. How it works

git clone https://github.com/thenavidm/kit-mcp-cli.git
cd kit-mcp-cli
npm ci
npm run typecheck
npm run build
npm test
npm run check:counts
npm run build:mcpb
npm pack --dry-run

The snapshot is checked into scripts/kit-api.snapshot.json; generated operation schemas and the source hash are in src/tools/. To review a future API snapshot, save the official document locally and run node scripts/sync-openapi.mjs /absolute/path/reviewed-v4.json, inspect every diff and re-run the checks. Do not treat new endpoint discovery as a reviewed release. Record current source corrections and verify live behavior when credentials permit.

The CI workflow verifies Node 22 and 24 on Linux and Windows, then builds the desktop archive. The release workflow verifies package/tag/counts/tests, publishes npm with provenance, and attaches the matching desktop archive. Release tags are annotated v<package version>. Topics and npm keywords cover the actual Kit/MCP/CLI surfaces. Credentials use encrypted GitHub secrets or private local configuration and never enter a package.

The npm allowlist includes built code, full setup/skill/comparison/changelog/security/contribution docs and licenses. It excludes source tests, private account files, local .env, build scratch folders and the desktop archive. The .mcpb vendors production dependencies, the server and notices without configured credentials. A build dependency audit can differ from the production audit; see SECURITY.md.

Issues and reproducible bug reports are welcome. This repository does not accept unsolicited pull requests; see CONTRIBUTING.md. Use private vulnerability reporting for security issues.

14. Your data

Requests go directly to https://api.kit.com/v4; no Navid-hosted relay, analytics or telemetry is included. HTTP redirects are refused. Keys, OAuth tokens, client secrets and signing secrets are sanitized from tool results and reflected API errors. Subscriber addresses, email content, reports and other authorized response data are still private business data that your AI client can process. Configure its retention and sharing policy accordingly.

Private OAuth files, webhook-secret files and optional audit files remain local. Audit records contain attempted write names, risk, surface, decision and outcome, without arguments, subscriber addresses, message bodies, account labels or credentials. Audit failure does not block a requested operation. It is a guard-decision log, not proof of remote delivery or complete Kit account audit history.

See SECURITY.md for disclosure, private file handling, dependency limitations and live-validation limits.

15. Environment variables

Variable	Default	Meaning
`KIT_API_KEY`	`Empty`	Personal v4 API key
`KIT_ACCESS_TOKEN`	`Empty`	Existing OAuth access token
`KIT_REFRESH_TOKEN`	`Empty`	OAuth refresh token
`KIT_CLIENT_ID`	`Empty`	Your authorized Kit app ID
`KIT_CLIENT_SECRET`	`Empty`	Your private confidential-app secret
`KIT_TOKENS_FILE`	`Empty`	Regular private OAuth JSON, max 64 KB
`KIT_ACCOUNTS`	`Empty`	Private JSON named accounts; replaces single-account settings
`KIT_DEFAULT_ACCOUNT`	`First account`	Default name from KIT_ACCOUNTS
`KIT_READ_ONLY`	`0`	1 or true hides and refuses all 47 writes
`KIT_ALLOW_DESTRUCTIVE`	`1`	0 or false blocks all 40 guarded operations even with confirm
`KIT_AUDIT_LOG`	`None`	Local attempted-write guard log, no request fields
`KIT_PRIVATE_DIR`	`~/.config/kit-mcp-cli/secrets`	Private signing-secret folder
`KIT_REQUEST_TIMEOUT_MS`	`30000`	Per-request deadline, integer 100–300000
`KIT_MAX_RETRIES`	`2`	GET 429 retries only, integer 0–5
`KIT_MIN_REQUEST_INTERVAL_MS`	`0 = automatic`	0 chooses 550 ms keys / 110 ms OAuth; otherwise 1–10000 ms
`KIT_CONFIRM`	`human`	`model` lets confirm:true alone approve over MCP, for an agent with no person to ask
`KIT_SURFACE`	`full`	`search` lists three tools that find, describe and run the rest
`KIT_TOOL_TIMEOUT_MS`	None	Give up on any tool after this long
`KIT_HTTP_PORT`, `KIT_HTTP_HOST`, `KIT_HTTP_TOKEN`	8787, 127.0.0.1, none	For `--http`; any host but 127.0.0.1 needs the bearer token
`KIT_HTTP_ALLOWED_ORIGINS`	None	Comma-separated browser origins allowed to call `--http`; a page from any other site is refused
`KIT_DEBUG`	0	`1` prints debug lines on stderr

The package reads environment variables only. It does not automatically load .env, resolve a secret-manager account, or inherit GUI environment values from a terminal. Private client config examples are in INSTALL.md. Never put real credentials in project MCP files.

16. Updates and removal

npm install -g @thenavidm/kit-mcp-cli@latest
kit-cli --version
claude mcp remove --scope user kit
codex mcp remove kit
npm uninstall -g @thenavidm/kit-mcp-cli

Reinstall a newer desktop archive separately and restart affected clients. Remove manual client entries using its own settings. Uninstalling the package does not revoke Kit credentials, remove private token/secret files or unschedule email. Revoke/delete keys or authorized apps in Kit when appropriate. Inspect and remove private files yourself after preserving any receiver secrets still in use.

Pin a reviewed version instead of @latest if your automation requires reproducibility. Check CHANGELOG.md and GitHub Releases before a major update. Do not roll back by blindly publishing an older version over an existing npm version.

17. Troubleshooting

Symptom	Resolution
Binary not found	Install Node 22+, check npm global prefix/PATH, reopen terminal
PowerShell blocks npm.ps1	Use npm.cmd or Command Prompt in accordance with your policy
Local doctor exit 10	Configure a v4 key or regular OAuth token file in private settings
GUI works differently from terminal	GUI clients often do not inherit shell env; configure private client env
API 401	Verify v4 credentials; OAuth may be expired or revoked
API 403 / OAuth required	Check current plan permissions and use OAuth for that endpoint
Read-only missing tools	Set KIT_READ_ONLY=0 only when writes are wanted; reconnect
Confirmation refused	Supply confirm:true/--confirm only for an explicitly requested operation; check destructive policy
Invalid request body	Read schema; use payload for nested fields/null; avoid mixing body forms
No results beyond the first page	Follow end_cursor or use bounded all_pages
429	Wait; other integrations share the credential limit; do not blindly retry writes
Write timeout	Outcome may be unknown; inspect the account before repeating
Template or Starting point error	See recorded schema contradictions and test an unscheduled private draft
Secret filename exists	Choose a new private secret_name; files are never overwritten
Refresh succeeds but file update fails	Repair private folder access and inspect state before another write
Desktop extension rejected	Validate host custom-extension policy and compatible runtime; try manual stdio setup

18. API coverage and comparisons

Offering	Surface	What the reviewed source establishes	Tradeoff
Official Kit account MCP	Remote MCP, Kit OAuth	v4 account reads and writes; paid Creator/Creator Pro; 120 requests/min/token	Hosted consent/setup; standalone task CLI not identified there
Kit Developer Docs MCP	Documentation MCP	Read documentation	No account operations
This package	Local stdio, CLI, desktop archive	83 pinned operations + 2 helpers, private account settings and guards	You maintain local credentials; live writes pending
ArtisanPack UI ConvertKit	PHP/Laravel integration and Artisan commands	Kit integration with framework commands	Requires the Laravel application environment
CData ConvertKit CLI	Provider data-access CLI	JDBC-backed data access from a CLI	Different provider/license and data-oriented scope

COMPARISON.md records dated primary sources, scope and limitations. Counts are package discovery results, not evidence that the official server has fewer endpoints. No competitor latency, success rate or total token cost has been measured here.

19. Versions

Component	Version / source
This package and desktop manifest	3.0.0
Runtime	Node 22 or newer
Kit API	v4; 83 reviewed operations from the 2026-10-02 snapshot
Slipway	0.1.20
MCP TypeScript SDK, through Slipway	2.3.0
Source provenance	api-source.json, with SHA-256 and corrections

CHANGELOG.md records dated changes and validation. Version 2.0.0 replaces the private 1.0.0 source with a sanitized public v4 implementation. It preserves the AGPL license and useful operation names, and adds the CLI and desktop surface.

The old source's private account instructions and original commits remain private. Public history starts with the reviewed v2 source; this avoids publishing personal setup data. Only the sanitized public branch is pushed.

Major-version migration

Configure a v4 key or private authorized OAuth file; a v3 API secret is insufficient.
Replace numeric page arguments with v4 cursors.
Use current tool IDs and schemas; search_subscribers remains an exact-email alias.
The old browser kit_login and broadcast/sequence/visual-automation duplication helpers are not included. Their private cookie workflows are not part of the v4 API. Use the Kit UI for designed duplication and visual automation work.
API sequence/email CRUD is now available, but it is not a claim of legacy browser feature parity.
Review send_at, draft defaults and explicit confirmation before any delivery or audience change.
Never copy old personal SKILL content, cookies or the private Git history into public files.

20. FAQ

The wrapper is free AGPL software. Your Kit subscription and API eligibility are separate. The official Kit MCP is available on paid Creator and Creator Pro plans; consult Kit for your account’s API access.

Yes. Its account server supports reads and writes across v4. Its separate developer-docs MCP reads documentation and cannot act on your account.

Use it for standalone task commands, shell automation, private named-account settings, token-file refresh, bounded pagination or a local desktop archive. Use Kit’s official server for Kit-managed hosted OAuth. Neither is declared universally better.

No standalone email-account task CLI was identified in the official developer surfaces reviewed on 2026-10-02. Framework-specific and data-provider CLIs exist; see COMPARISON.md.

Discovery shows them, but OAuth-only bulk and purchase endpoints reject API-key calls before HTTP. The tool table marks them. Use an authorized OAuth session for those operations.

No. Configure it privately in your shell or client settings. Help, discovery and schemas work without it.

No. It explains first-time key/OAuth setup. This package does not host a consent flow or copy your browser cookies.

Yes, through local stdio configuration or the custom .mcpb release. GUI installation of this version remains a separate host check.

This local package does not expose an HTTPS connector. Use Kit’s official remote MCP for a compatible web connector.

The wrapper defaults create to private and unscheduled. If you explicitly pass send_at or publication fields, they can change that behavior. All broadcast writes require confirmation; review in Kit before delivery.

No. Use send_at for email delivery. published_at concerns web publication.

Use update_broadcast with a JSON body containing send_at:null, then inspect the broadcast. A shell string null is not JSON null.

Inspect existing template HTML and required Liquid/footer markup before changing content. The API is not a visual block editor. Starting point schema conflicts remain live-account validation pending.

Yes, existing automations can react to tagging, form subscription or sequence enrollment. Those operations require explicit confirmation here.

No. Mutating requests are never automatically retried. A timeout may have an unknown outcome; inspect the account first.

Yes. Use a private KIT_ACCOUNTS array with unique names, then --account. list_accounts returns labels/auth methods without credentials.

Use after or bounded all_pages/max_items. v4 uses cursors. Aggregate output exposes the last cursor and truncation; it is not an unlimited export.

New signed endpoint secrets go to exclusive owner-only files under KIT_PRIVATE_DIR and are redacted from returned tool data. Configure your own receiver privately.

Against the official MCP it has not been measured. In Claude Code the CLI costs nothing until it is used, plus about 1,570 tokens for SKILL.md once, where the server costs about 1,520 tokens a message with tool search and 46,200 with every tool loaded. In Codex, finding the command that tags a subscriber and its flags took a median of 83,147 input tokens over the CLI and 77,462 over MCP. Section 7 has how each was measured.

Create new private settings with a v4 key or authorized OAuth token file. Do not copy old personal SKILL content, cookies or source history into a public repo. See the 2.0 migration notes.

Questions

Open an issue with the version, client and a sanitized reproduction. Report security problems privately through SECURITY.md.

About the author

Navid Moazzez is a leading AI business strategist, and the host of the AI Creator Summit, watched by 100,000+ creators. He helps creators and founders master AI and build their own AI Operating System (AI OS) to automate their business and life. He creates useful free tools, MCP servers and CLIs that creators and founders can use in their own workflows.

Links

Personal website: navid.me
Link in bio: navid.bio
Navid Media: navid.media
YouTube: @thenavidm and @thenavidai
X: @thenavidm
Instagram: @thenavidm
LinkedIn: thenavidm

Dependencies

Dependency	Version range	Used for
`@thenavidm/slipway`	`^0.1.20`	The MCP server and the CLI from one definition of each tool, with the MCP TypeScript SDK
`ajv`	`^8.17.1`	JSON Schema input validation
`ajv-formats`	`^3.0.1`	JSON Schema input validation

Full third-party attribution is in THIRD_PARTY_NOTICES.md. Development tooling and its audit limitations are documented in SECURITY.md.

License

This wrapper is AGPL-3.0-or-later, preserving the legacy source's license. See LICENSE and the full AGPL text. Kit's service and documentation retain their own rights and terms. Third-party dependency attribution is in THIRD_PARTY_NOTICES.md.

Available Tools

85 tools

add_subscriber_to_formAdd subscriber to form by email addressA

Destructive

Add subscriber to form by email address. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`form_id`	Yes	Positive form id.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`referrer`	No
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.
`email_address`	No

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, and the description adds genuinely useful impact context ('may affect delivery, audience membership, published data or irreversible state') plus the confirm gate. It stops short of stating exactly which of those side effects occur, keeping it out of 5 territory.

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

Conciseness4/5

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

Two tight sentences with the action front-loaded and no filler. The first sentence duplicates the title verbatim, which is minor redundancy but the second sentence earns its place by conveying risk and the confirm requirement.

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?

For a 7-parameter destructive mutation with no output schema, the description covers the safety-critical facts (impact domain, confirm requirement) while the schema carries the parameter detail, including the payload vs body-flag exclusivity. Only the choice between this and the by_id/bulk variants is left implicit.

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 description coverage is 71% and the schema already documents account, confirm, form_id, payload and payload_file. The description only echoes the confirm requirement (also in the schema) and implies email_address via the title phrasing, adding little beyond the structured fields.

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?

States a specific verb and resource (add subscriber to form) with the distinguishing qualifier 'by email address', which separates it from the sibling add_subscriber_to_form_by_id. The first sentence is an exact restatement of the title, so it breaks no new ground, but the resource and targeting method are unambiguous.

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

Usage Guidelines3/5

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

Provides one real prerequisite ('Requires confirm=true') but offers no guidance on when to prefer this over add_subscriber_to_form_by_id or bulk_add_subscribers_to_forms. Usage is implied by the name rather than explained.

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

add_subscriber_to_form_by_idAdd subscriber to formA

Destructive

Add subscriber to form. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`form_id`	Yes	Positive form id.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`referrer`	No
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.
`subscriber_id`	Yes	Positive subscriber id.

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, so safety is partly covered. The description adds genuine context beyond them: the categories of side effect (delivery, audience membership, published data, irreversible state) and the mandatory confirm=true gate.

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

Conciseness5/5

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

Two short sentences with no filler, and the required precondition is front-loaded in the first sentence. Nothing wasted.

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?

For a 7-parameter mutating tool with a nested payload object, the description covers the critical safety gate and effect scope, while the rich schema handles the rest and no output schema exists to explain. The only real gap is sibling disambiguation, which is minor.

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 86%, so the schema already documents almost every parameter including the payload/payload_file mutual exclusion. The description adds only the confirm=true requirement, which the schema also states, so it does not meaningfully go beyond the structured fields.

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?

States a specific verb and resource ('Add subscriber to form'), which is clear on its own. However, it does not distinguish itself from the near-identical sibling 'add_subscriber_to_form' (the name suffix '_by_id' is the only hint), so the agent has to infer the difference from naming alone.

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

Usage Guidelines3/5

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

Gives one concrete prerequisite ('Requires confirm=true'), which is actionable. It does not say when to prefer this over 'add_subscriber_to_form' or 'bulk_add_subscribers_to_forms', leaving the sibling selection implied.

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

add_subscriber_to_sequenceAdd subscriber to sequence by email addressA

Destructive

Add subscriber to sequence by email address. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`sequence_id`	Yes	Positive sequence id.
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.
`email_address`	No

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, non-idempotent, openWorld, and non-read-only. The description goes beyond them by naming the concrete blast radius ('delivery, audience membership, published data or irreversible state') and restating the confirm gate, which is useful added context for a mutation.

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

Conciseness4/5

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

Three short sentences, front-loaded with the action and followed by the impact warning and the confirm requirement. No filler, though the impact sentence is a generic catch-all list rather than specific to this tool.

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?

For a 6-parameter, nested-payload mutation with no output schema, the description covers the action, the key, the side-effect risk, and the confirmation gate. Remaining gaps (duplicate-subscription behavior, email vs. payload precedence) are minor.

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 description coverage is 83%, so the schema already documents confirm, payload, payload_file, account, and sequence_id. The description only reiterates the confirm requirement and the email-address lookup, adding little beyond structured fields — the baseline 3 for high coverage is appropriate.

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 states a specific verb and resource ('Add subscriber to sequence') and the lookup key ('by email address'), which implicitly distinguishes it from the sibling add_subscriber_to_sequence_by_id. It does not explicitly name that sibling, but the action is unambiguous.

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

Usage Guidelines3/5

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

It states the confirm=true prerequisite, which is genuine invocation guidance, but gives no when-to-use/when-not context and never routes the agent to the alternative 'by_id' sibling. Usage is implied rather than explained.

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

add_subscriber_to_sequence_by_idAdd subscriber to sequenceA

Destructive

Add subscriber to sequence. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`sequence_id`	Yes	Positive sequence id.
`subscriber_id`	Yes	Positive subscriber id.

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds value by enumerating the affected surfaces (delivery, audience membership, published data, irreversible state) and the confirm=true requirement, which is not expressed in 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.

Conciseness5/5

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

Two tight sentences with the effect warning and the confirm requirement front-loaded. No filler, nothing redundant.

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?

For a destructive, non-idempotent, open-world mutation with no output schema, the description conveys the risk surface and the confirmation gate. It omits what success/failure returns and whether the operation can partially apply, which would help, but the core call requirements are present.

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 description coverage is 100%, so the schema already documents account, confirm, sequence_id, and subscriber_id. The description only restates the confirm requirement and adds no syntax or format detail beyond it — baseline 3.

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

Purpose5/5

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

States the exact verb (Add) and resource (subscriber to sequence), and the '_by_id' suffix plus sibling 'add_subscriber_to_sequence' implies an id-based variant. An agent can distinguish this from the email-based sibling immediately.

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

Usage Guidelines3/5

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

The description gates the action behind confirm=true, implying it should only be used when explicitly requested. However, it never names the sibling 'add_subscriber_to_sequence' or explains when to prefer the id variant over the email variant, leaving that choice to inference.

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

bulk_add_subscribers_to_formsBulk add subscribers to formsA

Destructive

Bulk add subscribers to forms. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true. Requires OAuth; API keys are not supported for this endpoint.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`additions`	No
`callback_url`	No
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the destructive/openWorld annotations, the description specifies what can be affected: 'delivery, audience membership, published data or irreversible state.' It also adds concrete operational requirements: confirm=true and OAuth-only authentication. This is rich behavioral context that annotations alone do not provide.

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

Conciseness5/5

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

The description is four sentences, front-loaded with the action, then immediately states impact, confirmation, and auth constraints. Every sentence carries safety or prerequisite information without padding.

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?

For a complex bulk mutation with nested objects and no output schema, the description covers purpose, risk profile, confirmation, and authentication. It leaves detailed payload structure to the schema, which is acceptable, but it could say more about the return or async behavior if applicable.

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 description coverage is 67%, so the schema already documents several parameters. The description adds one important parameter-level constraint by declaring confirm=true required, but it does not explain the nested additions structure, payload vs payload_file, or callback_url. A baseline of 3 is appropriate.

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

Purpose5/5

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

The description states a specific verb and resource: 'Bulk add subscribers to forms.' The bulk scope is clear and distinguishes it from the singular add_subscriber_to_form siblings, even without naming them.

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

Usage Guidelines4/5

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

It gives clear prerequisites ('Requires confirm=true') and auth constraints ('Requires OAuth; API keys are not supported'), which frame when the tool can be used. It does not explicitly route agents away from the singular alternatives, so it stops short of full when/when-not guidance.

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

bulk_create_custom_fieldsBulk create custom fieldsA

Bulk create custom fields. Changes account configuration. Requires OAuth; API keys are not supported for this endpoint.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`callback_url`	No
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.
`custom_fields`	No

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnly=false, openWorld=true, idempotent=false, destructive=false. The description adds two things beyond that: the mutation alters account-level configuration, and the endpoint requires OAuth rather than API keys. That auth constraint is not derivable from annotations and is material for an agent planning a call.

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

Conciseness4/5

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

Three short sentences with the action front-loaded, then the side effect, then the auth constraint in descending order of importance. 'Changes account configuration' is close to redundant with the tool name but does flag the mutation, so it earns partial credit.

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

Completeness3/5

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

No output schema exists, and the tool is a non-idempotent mutation with nested objects and five parameters. The description covers the mutation and auth surface adequately for its length but says nothing about partial-failure behavior on bulk creation or what the response returns, which is a real gap for a bulk write.

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 description coverage is 60% and the description supplies no parameter detail at all, including whether bulk creation takes the same shape as the singular variant. The schema's own descriptions of account, payload, and payload_file are decent, so the baseline 3 applies, but the description misses an opportunity to clarify the payload vs. body-flags vs. payload_file exclusivity that matters for a nested bulk tool.

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?

States a specific verb+resource ('bulk create custom fields') with the bulk scope made explicit, which distinguishes it from the singular create_custom_field sibling in the tool list. It does not name that sibling directly, so an agent must consult the list to confirm the split.

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

Usage Guidelines3/5

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

Provides a prerequisite (OAuth required, API keys unsupported) which is genuine usage context, but gives no when-to-use guidance and never contrasts with create_custom_field or bulk_update_subscriber_custom_field_values. The routing decision is left to inference.

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

bulk_create_subscribersBulk create subscribersA

Destructive

Bulk create subscribers. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true. Requires OAuth; API keys are not supported for this endpoint.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`subscribers`	No
`callback_url`	No
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the bar is lower; the description nonetheless adds the confirm=true guardrail and the OAuth-vs-API-key constraint, plus a warning about side effects on delivery/audience/published data. The side-effect sentence is somewhat generic boilerplate, which keeps it from a 5.

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

Conciseness4/5

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

Three short sentences, front-loaded with the purpose, then the risk warning, then the hard requirements. Efficient overall, though the vague 'May affect delivery, audience membership, published data or irreversible state' phrasing spends words without pinning down a concrete consequence.

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

Completeness3/5

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

For a destructive bulk mutation with no output schema this covers the essentials (auth, confirmation, side effects), but omits practical operational details an agent would want: whether the call is async given the callback_url parameter, any batch-size limit, and how the three body-input modes relate.

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 67%, so most parameters are documented structurally. The description only reinforces 'confirm' (already described in the schema) and adds nothing about the payload vs. individual body flags vs. payload_file mutual exclusion, nor about the subscribers array shape.

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 opens with a specific verb+resource ('Bulk create subscribers') and the 'Bulk' qualifier implicitly separates it from the single-record create_subscriber sibling. It never names the alternative explicitly, so the agent must infer the distinction, but the core 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.

Usage Guidelines3/5

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

It states two real prerequisites (confirm=true, OAuth-only auth), which is useful gating information, but gives no guidance on when to choose this over create_subscriber, bulk_add_subscribers_to_forms, or other bulk siblings. Usage context is implied by the name rather than explained.

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

bulk_create_tagsBulk create tagsB

Bulk create tags. Changes account configuration. Requires OAuth; API keys are not supported for this endpoint.

ParametersJSON Schema

Name	Required	Description
`tags`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`callback_url`	No
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.

TDQS

B3/5.0

Behavior4/5

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

Annotations already declare the mutation/safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true). Beyond that, the description adds genuinely useful behavior: it changes account configuration and requires OAuth with API keys unsupported for this endpoint, which an agent cannot derive from annotations or schema.

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

Conciseness4/5

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

Three short, front-loaded sentences with no filler; the action, side effect, and auth constraint each earn their place. Slightly terse rather than padded, which is the right failure mode.

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

Completeness3/5

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

For a non-idempotent bulk mutation with nested objects and no output schema, the auth and account-config notes are valuable, but the absence of any parameter-level or payload-format guidance leaves real gaps. Adequate but not complete.

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

Parameters2/5

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

Schema description coverage is only 60% across 5 parameters, and the description explains none of them. Notably, the tags/payload/payload_file interplay (the schema says payload cannot be combined with body flags or payload_file, and callback_url appears at two levels) is left for the agent to work out from the schema alone.

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

Purpose3/5

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

The first sentence restates the name/title ('Bulk create tags'), and the bulk-vs-single distinction is inferable only from the name. It doesn't explicitly contrast with create_tag or bulk_tag_subscribers, which is the most likely source of confusion among siblings.

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

Usage Guidelines2/5

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

No guidance on when to use this versus create_tag (single) or bulk_tag_subscribers (which tags existing subscribers). Nothing states prerequisites such as needing existing tags or subscriber context.

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

bulk_delete_tagsBulk delete tagsA

Destructive

Bulk delete tags. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true. Requires OAuth; API keys are not supported for this endpoint.

ParametersJSON Schema

Name	Required	Description
`tags`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`callback_url`	No	Optional. When the batch is processed asynchronously (more than 100 tags), the results are POSTed to this URL on completion.
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.

TDQS

A3.8/5.0

Behavior4/5

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

Goes beyond the annotations by disclosing concrete consequences ('may affect delivery, audience membership, published data or irreversible state') and an auth constraint ('Requires OAuth; API keys are not supported'). Annotations already flag destructiveHint=true and idempotentHint=false, so this adds real value rather than repeating them.

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

Conciseness5/5

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

Three short sentences, purpose front-loaded, followed by consequences, prerequisite, and auth constraint. 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.

Completeness4/5

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

For a destructive bulk operation with no output schema, it covers the safety-relevant essentials: destructive scope, confirmation gate, and auth requirement, with async batching behavior handled by the schema. Only minor gap is no return/response expectation, which is largely acceptable given no output schema.

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 description coverage is 83% (high), so the schema already documents tags, account, confirm, callback_url, and payload_file. The description reinforces the confirm requirement but adds no parameter detail beyond what the schema provides, so baseline 3 applies.

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?

States a specific verb+resource ('Bulk delete tags'), clearly distinguishing it from the many tag-related siblings (bulk_create_tags, update_tag_name, bulk_remove_tags_from_subscribers). However, it doesn't explicitly name an alternative or contrast the 'remove tags from subscribers' sibling, which could be confused with tag deletion.

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

Usage Guidelines3/5

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

Adds a prerequisite ('Requires confirm=true') and warns of side effects, which guides invocation. But it gives no explicit when-to-use vs when-not framing and no alternative routing, leaving usage context implied rather than stated.

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

bulk_remove_tags_from_subscribersBulk remove tags from subscribersA

Destructive

Bulk remove tags from subscribers. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true. Requires OAuth; API keys are not supported for this endpoint.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is partly covered. The description still adds substantive context beyond them: the confirm=true gate, the OAuth-only auth constraint, and the scope of impact (delivery, audience membership, published data, irreversible state).

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

Conciseness5/5

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

Three short sentences, no filler, with the action and its blast radius front-loaded before the gating requirements. Every clause carries distinct information.

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?

For a destructive, non-idempotent bulk mutation with no output schema, the description covers impact, auth, and the confirmation gate adequately; the only gap is the absence of any indication of what the result looks like (e.g., counts of affected subscribers).

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 description coverage is 100% for both parameters, so the baseline is 3. The description's 'Requires confirm=true' slightly strengthens the schema's softer wording ('Set true only when the user asked for exactly this action'), but adds no syntax or format detail beyond that.

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?

States a specific verb (remove) with resource (tags) and scope (bulk) plus the target (subscribers), which separates it from the singular untag_subscriber and from bulk_tag_subscribers. It does not explicitly name those siblings, but the bulk/singular distinction is inferable.

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

Usage Guidelines3/5

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

Gives real prerequisites (confirm=true, OAuth required, API keys unsupported), which is useful gating information. However, it never states when to choose this over untag_subscriber or bulk_tag_subscribers, so the when-to-use guidance is only implied.

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

bulk_tag_subscribersBulk tag subscribersB

Destructive

Bulk tag subscribers. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true. Requires OAuth; API keys are not supported for this endpoint.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`taggings`	No
`callback_url`	No
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.

TDQS

B3.1/5.0

Behavior4/5

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

Beyond the annotations (destructiveHint=true, idempotentHint=false, openWorldHint=true), the description adds two genuinely useful behavioral facts: the mandatory confirm=true gate and the authentication constraint that API keys do not work here. The impact clause is boilerplate, but the auth and confirmation details are real added value.

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

Conciseness4/5

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

Three short, front-loaded sentences with no padding. The impact sentence is generic filler, but the ordering (action, impact, confirm gate, auth) is efficient.

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

Completeness3/5

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

For a destructive, non-idempotent bulk mutation with a nested taggings array and no output schema, the description covers safety, confirmation, and auth but omits key semantics such as whether tagging appends or replaces existing taggings and what the bulk result looks like. Adequate but with clear gaps.

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 67% and the description only restates the confirm requirement, which the schema already documents ('Set true only when the user asked for exactly this action'). It adds no meaning for the taggings structure, payload/payload_file alternatives, or callback_url, so it neither compensates for nor extends the schema.

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

Purpose3/5

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

The opening sentence 'Bulk tag subscribers' essentially restates the tool name and title, adding only the notion of bulk. The action is understandable, but nothing distinguishes it from siblings like tag_subscriber, untag_subscriber, or bulk_remove_tags_from_subscribers.

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

Usage Guidelines2/5

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

No when-to-use guidance is given relative to alternatives. 'Requires confirm=true' and the OAuth requirement are prerequisites rather than routing guidance, and the agent is left to infer when bulk tagging is preferable to single-subscriber tag_subscriber calls.

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

bulk_update_subscriber_custom_field_valuesBulk update subscriber custom field valuesA

Destructive

Bulk update subscriber custom field values. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true. Requires OAuth; API keys are not supported for this endpoint.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`callback_url`	No
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.
`custom_field_values`	No

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds genuinely new context: effects on delivery, audience membership and published data, the confirm=true guard, and the OAuth/API-key auth constraint. This is meaningful disclosure beyond the structured fields.

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

Conciseness4/5

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

Four short sentences, front-loaded with the operation and immediately following with the risky-effects warning and hard prerequisites. No filler or repetition.

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?

For a nested bulk mutation with no output schema, the description covers the critical unknowns: required confirmation, auth restriction, and potential side effects. Remaining gaps (pagination/return shape, callback_url behavior) are minor since no output schema exists.

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 67%, so most parameters are documented in the schema. The description restates the confirm requirement but adds no detail about how payload, payload_file and body flags interact, nor about callback_url semantics. Baseline 3 is appropriate.

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?

States a specific verb (bulk update) and resource (subscriber custom field values), which cleanly separates it from update_custom_field and bulk_create_custom_fields. However, it does not explicitly name the sibling it is not, so differentiation is inferred rather than stated.

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

Usage Guidelines3/5

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

The description supplies strong prerequisites (confirm=true, OAuth-only, possible irreversible effects), which imply this is a high-friction write operation. It never states when to use this versus alternatives like update_subscriber or a single-field update, so the when-to-use guidance remains implicit.

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

create_broadcastCreate a broadcastB

Destructive

Create a broadcast. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`public`	No	`true` to publish this broadcast to the web. The broadcast will appear in a newsletter feed on your Creator Profile and Landing Pages.
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`content`	No
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`send_at`	No	The scheduled send time for this broadcast in ISO8601 format. If no timezone is provided, UTC is assumed.
`subject`	No
`description`	No
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.
`preview_text`	No
`published_at`	No	The published timestamp to display in ISO8601 format. If no timezone is provided, UTC is assumed.
`email_address`	No	The sending email address to use. Uses the account's sending email address if not provided.
`thumbnail_alt`	No
`thumbnail_url`	No
`email_template_id`	No	Id of the email template to use. Uses the account's default template if not provided. 'Starting point' template is not supported.
`subscriber_filter`	No
`allow_starting_point`	No	Explicitly allow replacing a Starting point template body, as described in Kit’s current content-field documentation. Review the complete rendered HTML first.

TDQS

B3.1/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered structurally; the description nonetheless adds useful context by naming the affected surfaces (delivery, audience membership, published data, irreversible state) and the confirm gate. That is genuine added value beyond the annotations, though the phrasing "may affect" is vague about exactly what is destroyed.

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

Conciseness4/5

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

Three short sentences, front-loaded with the action and the hard precondition, with no filler. It is efficiently written for the space it uses, though for a destructive 17-parameter tool the brevity edges toward under-specification.

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

Completeness2/5

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

This is a destructive, open-world, non-idempotent create with a complex nested payload, no output schema, and no required fields — the description covers none of the practical requirements (e.g. that a subject/content or template is needed, how scheduling via send_at behaves, or what success looks like). Those gaps are significant relative to the tool's complexity.

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

Parameters2/5

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

With 17 parameters, 0 required, nested objects, and schema coverage around 59% (including mutually-exclusive body flags vs `payload` vs `payload_file`), the description must compensate and does not. Its only parameter-level statement, "Requires confirm=true", merely repeats the `confirm` schema description. The complex `content`/`email_template_id`/`allow_starting_point` semantics are left entirely to the schema.

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

Purpose3/5

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

The first sentence restates the title verbatim ("Create a broadcast"), and the tool name already conveys create + broadcast, so the description adds little about what a broadcast actually is or how it relates to siblings like create_sequence_email or update_broadcast. The action is unambiguous, but there is no field-level or scope detail beyond the title.

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

Usage Guidelines3/5

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

"Requires confirm=true" is a real usage precondition, and the risk sentence hints that this is a consequential operation, so usage is implied rather than absent. However, there is no when-to-use/when-not-to-use guidance, no explanation of how to choose between the top-level body flags and the nested `payload` object, and no routing to the sibling update/delete broadcast tools.

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

create_custom_fieldCreate a custom fieldB

Create a custom field. Changes account configuration.

ParametersJSON Schema

Name	Required	Description
`label`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false, so the safety profile is covered. "Changes account configuration" adds a modest hint that this mutates account-wide settings, but says nothing about permissions, validation failures, or what happens on duplicate labels.

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

Conciseness4/5

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

Two short, front-loaded sentences with no padding. The second sentence is thin and largely restates the non-read-only nature already implied by annotations, but nothing is verbose.

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

Completeness2/5

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

For a creation tool with no output schema and a nested payload parameter, the description omits what the call returns, whether the label must be unique, and any account-scoping caveats. It is under-specified rather than merely concise.

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 description coverage is 75% and the nested payload object carries its own detailed description (mutual exclusivity with body flags and payload_file). The description itself contributes zero parameter semantics, but the schema does the heavy lifting, so a baseline 3 is appropriate.

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?

States a specific verb and resource ("Create a custom field"), so the core action is unambiguous. However, it does nothing to distinguish itself from the close siblings bulk_create_custom_fields, update_custom_field, and delete_custom_field, and the trailing sentence adds no purpose information.

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

Usage Guidelines2/5

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

No when-to-use guidance, no prerequisites, and no mention of the obvious alternative bulk_create_custom_fields for creating multiple fields at once. The agent must infer the choice entirely from the tool names.

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

create_purchaseCreate a purchaseA

Destructive

Create a purchase. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true. Requires OAuth; API keys are not supported for this endpoint.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`purchase`	No
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is partly covered. The description adds genuinely new operational context beyond that: concrete downstream effects (delivery, audience membership, published data), the confirm gate, and the fact that OAuth is mandatory while API keys are rejected.

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

Conciseness5/5

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

Three short sentences, front-loaded with the action and then the risk, confirm gate and auth constraint. No filler and no repetition of the title.

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?

For a 5-parameter, nested-object, no-output-schema mutation tool, the description covers risk, confirmation and authentication, which is what an agent most needs. It omits the mutual exclusivity of the three body-input modes (purchase, payload, payload_file), though that is documented in the schema.

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?

With 80% schema description coverage and a nested purchase object fully documented in the schema, the schema already does the heavy lifting for parameters. The description adds no syntax, format or constraint detail beyond what the schema states, so the baseline 3 applies.

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 states a specific verb and resource ('Create a purchase') that is clearly distinguishable from the read-side siblings get_purchase and list_purchases. It does not, however, differentiate itself from the many other create_* tools beyond the resource name, which is adequate here since no other tool creates purchases.

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

Usage Guidelines3/5

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

It gives one hard prerequisite ('Requires confirm=true') and an auth constraint, which supports correct invocation. It stops short of stating when this tool is preferred over alternatives, what conditions should block a call, or what happens if confirm is omitted.

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

create_sequenceCreate a sequenceA

Destructive

Create a sequence. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`hold`	No	When `true`, subscribers added via Visual Automations stay in the sequence after receiving the last email.
`name`	No	The name of the sequence.
`active`	No	`true` to activate the sequence, `false` to deactivate it.
`repeat`	No	When `true`, subscribers can restart the sequence multiple times.
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`send_days`	No	The days of the week to send the sequence on. Must be one of: `monday`, `tuesday`, `wednesday`, `thursday`, `friday`, `saturday`, `sunday`.
`send_hour`	No	The hour of the day to send the sequence at. Must be an integer between 0 and 23.
`time_zone`	No	The timezone to use for the sequence. Must be a valid IANA timezone string.
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.
`email_address`	No	The sending email address to use. Uses the account's sending email address if not provided.
`email_template_id`	No	Id of the email template to use.
`exclude_subscriber_sources`	No

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is covered. The description adds real value beyond that by naming the blast radius — delivery, audience membership, published data, irreversible state — and restating the confirm gate, which is exactly the kind of context an agent should weigh before a destructive call.

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

Conciseness5/5

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

Two short sentences, zero filler, with the risk warning and the confirm requirement front-loaded. Nothing is padded or repeated.

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

Completeness3/5

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

For a 14-parameter, destructive, nested-object tool with no output schema, the description covers consequences and the confirm gate but omits sibling routing and the mutual exclusivity between payload, individual body flags, and payload_file that the schema mentions. It is adequate given 93% schema coverage and strong annotations, but leaves real gaps.

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 description coverage is 93% across 14 parameters, so the schema already documents name, active, send_days, time_zone, payload_file and the rest. The description adds no parameter detail beyond echoing the confirm requirement that the schema itself already explains. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb and resource ("Create a sequence"), which is unambiguous on its own. However, it does nothing to distinguish itself from the many sibling sequence tools (create_sequence_email, update_sequence, delete_sequence, add_subscriber_to_sequence), so an agent still has to reason about scope from the name alone.

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

Usage Guidelines2/5

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

The only guidance is the confirm=true prerequisite, which is a precondition rather than a when-to-use/when-not instruction. There is no mention of when to choose this over update_sequence or create_sequence_email, and no stated context about when creating a sequence is appropriate.

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

create_sequence_emailCreate a sequence emailC

Destructive

Create a sequence email. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`content`	No	HTML body content of the email
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`subject`	No	Subject line of the email
`position`	No	Zero-based position of the email in the sequence. Assigned automatically after the last email if omitted
`published`	No	Whether the email is active and will be sent to subscribers. Defaults to `false` (draft)
`send_days`	No
`delay_unit`	No	Unit for the send delay. Use `days` for schedule-aware delivery, `hours` for a fixed hourly delay
`delay_value`	No	Number of days or hours to wait before sending this email after the previous one
`sequence_id`	Yes	Positive sequence id.
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.
`preview_text`	No	Preview text shown in email clients before the email is opened
`email_template_id`	No	ID of the email template to use for layout and styling

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the risk profile is covered structurally. The description adds some value by enumerating what may be affected (delivery, audience membership, published data, irreversible state) and restating the confirmation requirement. It does not contradict annotations, but adds little beyond them.

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

Conciseness4/5

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

Two short sentences, front-loaded with the core action and the risk/confirm constraint. Nothing is wasted, though brevity here is achieved partly by omitting needed context rather than by tight writing.

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

Completeness3/5

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

For a 14-parameter mutation tool with a nested payload object and no output schema, the description is thin. The safety warning is present, but there is no explanation of the payload-vs-flags mutual exclusion, the draft-by-default behavior, or how this differs from updating an existing sequence email. The rich schema carries most of the load.

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 description coverage is 93%, so the schema already documents sequence_id, confirm, payload vs body-flag semantics, send_days, delay_unit, and published defaults. The description contributes no parameter-level meaning beyond the schema, making the baseline 3 appropriate.

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

Purpose2/5

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

The description is essentially a verbatim restatement of the tool title: "Create a sequence email." It states a verb and resource, but adds nothing to distinguish this from siblings such as create_broadcast, create_sequence, or update_sequence_email. By the rubric this is a tautology that merely restates the name/title.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus update_sequence_email (edit an existing email), create_sequence (create the container), or create_broadcast (one-off send). The only directive is "Requires confirm=true," which is a precondition, not usage guidance. No exclusions or alternatives are named.

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

create_snippetCreate a snippetA

Destructive

Create a snippet. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, non-idempotent, and openWorld, so the bar is lower, and the description still adds concrete blast radius ("delivery, audience membership, published data or irreversible state") plus the confirm gate. It omits auth scope, rate limits, or return behavior, keeping it short of a 5.

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

Conciseness4/5

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

Two short sentences, front-loaded with the action and followed by the caveats, with no filler. The impact clause is a slightly loose list, which keeps it just under a full 5.

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

Completeness3/5

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

No output schema exists, and the description covers the mutation's destructive character, which is adequate for a create tool. However, it claims confirm is required while the schema lists zero required parameters, a discrepancy the description never resolves, leaving a completeness gap.

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 description coverage is 100% and both parameters carry their own descriptions, so the schema does the heavy lifting and baseline is 3. The description reinforces the confirm parameter's importance but adds no new semantics for account or confirm beyond what the schema states.

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 states a specific verb+resource ("Create a snippet"), which is immediately distinguishable from the sibling verbs update_snippet, get_snippet, and list_snippets. It stops short of explicitly routing the agent or differentiating the create case from any near-sibling, which keeps it at a clear-but-generic 4.

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

Usage Guidelines3/5

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

"Requires confirm=true" conveys a prerequisite, and the impact list hints at when caution is warranted, but there is no explicit when-to-use-vs-alternative guidance (e.g., create_snippet vs update_snippet). Usage is implied rather than stated, fitting a 3.

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

create_subscriberCreate a subscriberB

Destructive

Create a subscriber. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`state`	No
`fields`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`first_name`	No
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.
`email_address`	No

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, non-idempotent, and openWorldHint, so the safety profile is largely covered. The description adds 'May affect delivery, audience membership, published data or irreversible state' plus the confirm requirement, which is genuine extra context — but it's vague boilerplate that doesn't say exactly what is destroyed or why it's not idempotent.

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

Conciseness4/5

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

Two short, front-loaded sentences with no redundancy and the confirm precondition surfaced immediately. Efficient, if terse.

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

Completeness2/5

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

For an 8-param, non-idempotent, destructive create with nested payload object, no output schema, and 50% schema coverage, the description leaves the risk surface underspecified: it never says the tool is not idempotent, what making a subscriber actually entails downstream, or how payload fields interact with body flags.

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 50%, so the schema documents state, fields, account, confirm, and payload_file in detail, but first_name and email_address carry no descriptions anywhere. The description adds nothing to close that gap and does not explain payload vs. body-flag precedence, so it stays at baseline.

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?

States a specific verb+resource ('Create a subscriber') matching the title. It does not differentiate from bulk_create_subscribers or otherwise disambiguate from siblings, so it lands short of a 5.

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

Usage Guidelines3/5

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

The description implies 'use this to add a subscriber' and gives a precondition ('Requires confirm=true'), but never says when to prefer bulk_create_subscribers over this single-record tool or when to avoid it. Usage is implied rather than stated.

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

create_tagCreate a tagC

Create a tag. Changes account configuration.

ParametersJSON Schema

Name	Required	Description
`name`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.

TDQS

C2.6/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the mutation profile is covered. The description's only added claim, "Changes account configuration," is vague about what configuration changes, whether auth/account selection matters, or what side effects occur, adding little beyond the structured hints.

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

Conciseness4/5

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

Two short sentences with the action front-loaded and no filler. The second sentence is terse to the point of being cryptic, but the definition is efficiently sized.

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

Completeness2/5

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

This is a mutation tool with 4 parameters, a nested payload object, and no output schema, yet the description never explains the tag model, required fields, or the effect of the change. Given the complexity and the absence of an output schema, far more context is needed.

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 description coverage is 75% and the schema documents account, payload, and payload_file in detail; the description adds nothing about any parameter. With coverage this high the baseline of 3 applies, and notably the top-level name parameter is undocumented in both places.

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

Purpose3/5

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

States a clear verb+resource ("Create a tag") that is distinguishable from bulk_create_tags and update_tag_name by the singular create action. However, it does not state what a tag is, what scope it applies to, or explicitly differentiate itself from the many sibling tag tools, so the purpose is only minimally specified.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no mention of prerequisites, and no reference to alternatives such as bulk_create_tags or tag_subscriber. The agent is left to infer usage entirely from the name.

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

create_webhookCreate a webhookA

Destructive

Create a webhook. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true. Webhook response secrets are redacted; new signing secrets are saved only to a private local file.

ParametersJSON Schema

Name	Required	Description
`event`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`target_url`	No
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds substantive context beyond them: the concrete impact surface ("delivery, audience membership, published data or irreversible state"), the confirmation requirement, and the non-obvious secret-handling behavior (redacted response secrets, signing secret written only to a private local file). That is real value the annotations cannot convey.

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

Conciseness4/5

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

Three tight sentences, front-loaded with the action and its impact, then the confirmation gate, then the secret-handling note. Every sentence earns its place; only the abrupt jump between impact and secrets slightly interrupts flow.

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?

For a no-required-param, nested-object mutation tool with no output schema, the description covers the destructive consequence, the confirmation requirement, and the surprising secret side effect. It is complete enough to call safely, though it omits any relationship to the endpoint/secrets siblings.

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 67% and the schema itself documents account, confirm, payload and payload_file. The description adds only the confirm=true requirement (which the schema already implies) and says nothing about the undocumented target_url and event parameters or the mutual exclusivity of body flags vs payload vs payload_file, so it does not compensate for the gap.

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?

"Create a webhook" states a specific verb and resource, so the basic intent is unambiguous. However, the sibling list contains create_webhook_endpoint, and the description does nothing to distinguish creating a webhook from creating a webhook endpoint, leaving the agent to infer the difference.

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

Usage Guidelines3/5

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

The description supplies one real prerequisite ("Requires confirm=true"), which is genuine usage guidance. It offers no when-to-use context relative to alternatives (endpoint creation, list_webhooks, rotate_webhook_secret), so an agent must infer selection from names alone.

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

create_webhook_endpointCreate a webhook endpointA

Destructive

Create a webhook endpoint. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true. Webhook response secrets are redacted; new signing secrets are saved only to a private local file.

ParametersJSON Schema

Name	Required	Description
`url`	No
`name`	No
`events`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`description`	No
`secret_name`	Yes	New private filename under KIT_PRIVATE_DIR. Required before creating/rotating a signing secret; never overwritten.
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety bar is lower. The description nonetheless adds genuinely non-obvious behavior: that secrets in webhook responses are redacted and that newly minted signing secrets are written only to a private local file, plus the irreversibility warning. This goes meaningfully beyond the structured fields.

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

Conciseness4/5

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

Four short sentences with the action stated first and the risk/secret caveats after; no filler. Slightly terse on parameters given the tool's complexity, but structurally front-loaded and efficient.

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

Completeness3/5

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

For a destructive, non-idempotent mutation with 9 parameters, a nested payload object, and no output schema, the description covers safety and secret-handling well but leaves the request-body construction (payload vs. payload_file exclusivity, events semantics) and the expected result largely unexplained.

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 56% across 9 parameters, so roughly half the params are undocumented anywhere. The description adds useful framing for secret_name (where the signing secret lands) and reiterates confirm, but says nothing about url, events, payload vs. payload_file mutually exclusive flags, or name/description, leaving the payload-body parameters thin.

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?

States a specific verb and resource ('Create a webhook endpoint'), which is unambiguous against the many list/get/update webhook siblings. It does not, however, explicitly distinguish itself from update_webhook_endpoint, create_webhook, or rotate_webhook_secret, which sit in the same family.

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

Usage Guidelines3/5

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

The description does state the confirm=true precondition, which is real usage guidance, but it gives no when-not guidance and never names or contrasts the alternative webhook tools (update_webhook_endpoint, create_webhook). The condition for choosing this tool over its siblings is left to inference.

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

delete_broadcastDelete a broadcastA

Destructive

Delete a broadcast. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`broadcast_id`	Yes	Positive broadcast id.

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds real value beyond that by naming the blast radius ("delivery, audience membership, published data or irreversible state") and restating the confirm gate, which tells the agent this is not a recoverable cleanup.

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

Conciseness5/5

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

Three short sentences with zero filler; the action is front-loaded and the consequence and precondition follow in priority order. Every sentence carries distinct information.

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?

For a destructive mutation with full annotation coverage and no output schema, the description covers action, consequences, and the confirm gate, which is what an agent needs to call it correctly. Only minor gaps remain, such as what happens on a broadcast that is mid-send or already deleted.

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 description coverage is 100%, so account, confirm, and broadcast_id are already documented in the schema, including the confirm semantics. The description echoes the confirm requirement but adds no format, id-type, or account-resolution detail beyond what the schema provides.

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?

States a specific verb and resource ("Delete a broadcast"), which cleanly separates it from sibling deletes like delete_sequence_email, delete_sequence, and delete_webhook. It does not explicitly name a sibling or scope boundary, but the resource is unambiguous.

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

Usage Guidelines3/5

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

The description supplies a precondition ("Requires confirm=true"), which is genuine usage guidance. However, it never says when to prefer this over update_broadcast or what state a broadcast must be in to be deletable, so the when-to-use context is only implied.

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

delete_custom_fieldDelete custom fieldA

Destructive

Delete custom field. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`custom_field_id`	Yes	Positive custom field id.

TDQS

A3.8/5.0

Behavior4/5

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

The annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description earns credit for adding blast-radius detail the annotations do not carry: effects on delivery, audience membership and published data, plus irreversible state.

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

Conciseness5/5

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

Two short sentences with no filler; the destructive consequence is front-loaded before the confirm requirement. Every clause carries information an agent needs before calling.

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?

For a destructive single-resource delete with no output schema and full schema coverage, the definition supplies the essential pieces: what is destroyed, the side effects, and the confirmation gate. It could go further on recoverability or error behavior, but nothing required to invoke correctly is missing.

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 description coverage is 100%, so the schema already documents all three parameters including confirm and account. The description only restates the confirm requirement, adding no syntax or format meaning beyond the schema's own text; baseline 3 applies.

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?

States a specific verb and resource ('Delete custom field'), which cleanly separates it from the sibling create_custom_field, update_custom_field, list_custom_fields and bulk_create_custom_fields. It does not explicitly name alternatives, but the destructive delete intent is unambiguous from the first sentence.

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

Usage Guidelines3/5

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

'Requires confirm=true' is a concrete gating precondition that tells the agent this call cannot be made speculatively. However, it never says when deletion is the right choice versus other siblings (e.g. update_custom_field to rename, or bulk paths), so usage is implied rather than guided.

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

delete_sequenceDelete a sequenceA

Destructive

Delete a sequence. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`sequence_id`	Yes	Positive sequence id.

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is known. The description goes beyond them by naming the blast radius ('delivery, audience membership, published data or irreversible state') and the confirm gate, which is genuine added value. It stops short of saying whether the deletion cascades to sequence emails or enrolled subscribers.

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

Conciseness5/5

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

Three terse sentences with zero filler; the action, the impact, and the hard prerequisite are all front-loaded. Nothing here could be cut without losing meaning.

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?

For a destructive, non-idempotent tool with no output schema, the combination of annotations (safety) plus the description's impact list and confirm requirement covers most of what an agent needs. The remaining gap is scope: it never clarifies whether sequence emails or subscriber enrollments are also removed.

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 description coverage is 100%, so account, confirm, and sequence_id are already documented in the schema. The description only echoes the confirm requirement and adds no format or constraint detail beyond it, making the baseline 3 appropriate.

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?

States a specific verb and resource ('Delete a sequence'), so the operation is unambiguous. However, it does not distinguish itself from the sibling delete_sequence_email, and an agent could plausibly confuse whole-sequence deletion with deleting a single email in a sequence.

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

Usage Guidelines3/5

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

The description supplies one real prerequisite ('Requires confirm=true'), which is useful gating information. But it offers no when-to-use/when-not guidance and never mentions the sibling delete_sequence_email as the narrower alternative, leaving the agent to infer which deletion tool fits the request.

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

delete_sequence_emailDelete a sequence emailA

Destructive

Delete a sequence email. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`email_id`	Yes	Positive email id.
`sequence_id`	Yes	Positive sequence id.

TDQS

A3.7/5.0

Behavior4/5

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

The annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds value beyond that by naming the blast radius ("delivery, audience membership, published data or irreversible state") and the confirm gate, though the hedged "may affect" wording stops short of stating exactly what is destroyed.

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

Conciseness4/5

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

Two short sentences, front-loaded with the action and followed by the risk/precondition. Every clause carries information, though the four-item consequence list is slightly vague rather than crisp.

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?

For a destructive, non-idempotent tool with no output schema and a fully documented input schema, the description covers purpose, consequence, and the confirm requirement. It would be stronger if it clarified permanence and effect on subscribers, but the annotations already flag destructiveness.

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 description coverage is 100%, so account, confirm, email_id, and sequence_id are all documented in the schema itself, including the caution that confirm should only be set when the user asked for exactly this action. The description only repeats the confirm requirement, adding no new parameter semantics; baseline 3 applies.

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 states a precise verb+resource ("Delete a sequence email"), which cleanly distinguishes it from siblings like create_sequence_email, update_sequence_email, and get_sequence_email. It does not, however, explicitly differentiate itself from delete_sequence, leaving an agent to infer the containment relationship.

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

Usage Guidelines3/5

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

It gives a hard precondition ("Requires confirm=true"), which is genuine usage guidance. But it never says when to prefer this over alternatives such as update_sequence_email, nor does it state when deletion is inappropriate, so the routing guidance is only implied.

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

delete_subscriber_locationDelete a subscriber's locationA

Destructive

Delete a subscriber's location. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`subscriber_id`	Yes	Positive subscriber id.

TDQS

A4/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds genuine value beyond them by naming concrete blast radius (delivery, audience membership, published data, irreversible state) and the confirm gate, though the consequences remain hedged with 'may affect' rather than specified precisely.

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

Conciseness5/5

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

Two short sentences with zero filler; the action is front-loaded and the consequence/precondition detail follows. Nothing needs to be trimmed.

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?

For a destructive, non-idempotent tool with full schema coverage and no output schema, the description covers the action, its risk, and the required confirmation flag. It stops short of explaining what a caller should expect after deletion (e.g., resulting state or reversibility mechanics), leaving a small gap.

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 description coverage is 100%, so account, confirm, and subscriber_id are all documented in the schema itself. The description only restates the confirm requirement and adds no new semantics (e.g., what happens if confirm is omitted), so the baseline 3 applies.

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

Purpose5/5

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

The description opens with a precise verb+resource statement ('Delete a subscriber's location'), which is self-evidently distinct from the neighboring update_subscriber_location and pin_subscriber_location tools. An agent can tell what this does without opening the schema.

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

Usage Guidelines3/5

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

It states the precondition 'Requires confirm=true' and warns of side effects, which implies the action should only be taken deliberately, but it never names an alternative (e.g., update_subscriber_location) or states when deletion is the right choice over updating. Usage is implied rather than spelled out.

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

delete_webhookDelete a webhookA

Destructive

Delete a webhook. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true. Webhook response secrets are redacted; new signing secrets are saved only to a private local file.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`webhook_id`	Yes	Positive webhook id.

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description goes beyond them by naming the blast radius ('delivery, audience membership, published data or irreversible state'), the confirm gate, and secret-handling behavior (redaction, local signing secret file) – genuinely useful operational context.

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

Conciseness4/5

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

Three short sentences, front-loaded with the action and its risk, with no filler. The side-effect warning is slightly terse/list-like but still earns its place.

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 must carry return/behavior expectations, and it covers destruction scope, confirmation requirement, and secret handling. It omits any explicit statement of what the tool returns, but for a 3-param destructive call the essentials are present.

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%, so the baseline is 3. The description restates the confirm=true requirement already documented in the schema and adds nothing about webhook_id or account, so it does not meaningfully extend parameter meaning.

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?

States a specific verb and resource ('Delete a webhook'), which cleanly separates it from same-family siblings like create_webhook and delete_webhook_endpoint. It does not explicitly contrast itself with delete_webhook_endpoint, leaving the agent to infer the resource distinction.

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

Usage Guidelines3/5

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

It gives a hard prerequisite ('Requires confirm=true') and warns of broad side effects, which implies caution before use. However, it never states when to choose this over siblings such as delete_webhook_endpoint, so usage is only partially disambiguated.

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

delete_webhook_endpointDelete a webhook endpointA

Destructive

Delete a webhook endpoint. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true. Webhook response secrets are redacted; new signing secrets are saved only to a private local file.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`webhook_endpoint_id`	Yes	Positive webhook endpoint id.

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description goes further by naming concrete downstream consequences ('delivery, audience membership, published data or irreversible state'), the confirm requirement, and secret redaction/local-file behavior — genuine added context.

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

Conciseness4/5

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

Four short sentences, with the action and its consequences front-loaded before the confirm requirement. The trailing sentence about redacted response secrets and locally saved signing secrets is somewhat tangential to a delete operation, keeping it out of the top score.

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?

For a destructive mutation with full annotation coverage, no output schema, and complete parameter descriptions, the definition covers consequences, the confirm gate, and credential handling — enough to call it correctly. The only gap is the absence of any routing hint versus delete_webhook.

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 description coverage is 100%, so all three parameters (account, confirm, webhook_endpoint_id) are already documented in the schema. The description only restates the confirm=true requirement and adds nothing about the id format or account resolution, so baseline 3 applies.

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 opens with a specific verb+resource ('Delete a webhook endpoint'), so the core action is unambiguous. It does not, however, differentiate itself from the sibling delete_webhook, nor explain how endpoint-level deletion relates to it, leaving the agent to infer the distinction.

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

Usage Guidelines3/5

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

It states the operational gate ('Requires confirm=true'), which implies this is a high-caution action, and the schema reinforces when confirm should be set. But it never says when to choose this tool over delete_webhook or update_webhook_endpoint, so the selection guidance is only implied.

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

filter_subscribersFilter subscribers by engagement, sign-up date, state, and tagsC

Read-onlyIdempotent

Filter subscribers by engagement, sign-up date, state, and tags. Reads account data.

ParametersJSON Schema

Name	Required	Description
`all`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`include`	No
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`sort_field`	No
`sort_order`	No	Sort direction (default: desc).
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.
`counting_mode`	No

TDQS

C2.6/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint. The description's 'Reads account data' merely restates the read-only nature and adds no behavioral context about filtering complexity, rate limits, permissions, or result handling.

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

Conciseness3/5

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

The description is short and front-loaded, but for a tool this complex it is under-specified. The second sentence, 'Reads account data,' is largely redundant with the readOnlyHint annotation and does not earn its place.

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

Completeness2/5

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

This is a complex filtering tool with 8 parameters, nested objects, 0 required parameters, and no output schema. The description does not explain how to structure the nested filter conditions or mention key options like include, sort, or counting_mode, leaving it incomplete for correct invocation.

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

Parameters2/5

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

Schema description coverage is only 50%, and the description does not compensate. It names high-level categories ('engagement, sign-up date, state, and tags') but adds no meaning beyond the schema for nested filters, payload/payload_file, include, sort, or counting_mode.

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 states a specific verb and resource: 'Filter subscribers,' and lists the main filter categories. It is clear what the tool does, but it does not distinguish itself from siblings like search_subscribers or list_subscribers.

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

Usage Guidelines2/5

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

The description gives no guidance on when to use this tool versus alternatives such as search_subscribers or list_subscribers. It only states what can be filtered, not when this filtering approach is appropriate or what exclusions apply.

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

get_accountGet current accountC

Read-onlyIdempotent

Get current account. Reads account data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.

TDQS

C2.8/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true; 'Reads account data' merely restates the read-only nature. No additional behavioral context such as auth requirements, rate limits, or side effects is provided.

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?

The first sentence is front-loaded and sufficient, but the second sentence ('Reads account data.') is redundant with the title, annotations, and first sentence. It does not earn its place.

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

Completeness3/5

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

For a simple read tool with a fully documented optional parameter and rich annotations, the definition is mostly sufficient. However, with no output schema and no description of returned account fields, the agent lacks return-value context.

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 single optional account parameter is fully documented with default fallback behavior. The description adds no parameter information beyond the schema.

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 a specific verb and resource ('Get current account') and clarifies it is a read operation, so an agent can identify the basic action. It does not distinguish this tool from the sibling list_accounts or state scope beyond 'current'.

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

Usage Guidelines2/5

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

No when-to-use or when-not-to-use guidance appears; the description does not mention alternatives like list_accounts or any prerequisites. Usage is only implied by the tool name and parameter description.

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

get_broadcastGet a broadcastC

Read-onlyIdempotent

Get a broadcast. Reads account data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`broadcast_id`	Yes	Positive broadcast id.

TDQS

C2.5/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered structurally. The description adds nothing beyond that, and its "Reads account data" phrasing is confusing for a broadcast-reading tool rather than useful behavioral context.

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

Conciseness3/5

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

It is short and front-loaded, but the second sentence does not earn its place: it repeats the read nature already implied and introduces a misleading resource reference rather than adding information.

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

Completeness2/5

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

No output schema exists, so the description should convey what a broadcast read returns, but it only says "Reads account data." For a retrieval tool with no return-shape documentation, this leaves an important gap.

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 description coverage is 100%, so both the account and broadcast_id parameters are documented in the schema (positive id, account defaulting behavior). The description adds no syntax or format detail beyond that, which matches the baseline 3 when the schema does the heavy lifting.

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

Purpose3/5

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

The first sentence gives a clear verb+resource ("Get a broadcast"), but it does nothing to distinguish this tool from the many siblings reading the same broadcast resource (list_broadcasts, get_broadcast_stats, get_broadcast_clicks). The second sentence ("Reads account data") is vague and arguably misdescribes the resource the tool targets.

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

Usage Guidelines2/5

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

There is no guidance on when to use this versus list_broadcasts, get_broadcast_stats, or get_broadcast_clicks. No prerequisites or context for retrieval are given.

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

get_broadcast_clicksGet link clicks for a broadcastB

Read-onlyIdempotent

Get link clicks for a broadcast. Reads account data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`broadcast_id`	Yes	Positive broadcast id.

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only the vague 'Reads account data', which hints at account scoping but does not clarify pagination, result limits, or how click data is aggregated.

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

Conciseness4/5

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

Two very short sentences with the core action front-loaded and no padding. The second sentence earns little, but there is no verbosity to penalize.

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

Completeness2/5

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

There is no output schema, so the description should explain what a 'link click' result looks like (per-link counts, totals, date scoping), and it does not. For a data-retrieval tool with no output schema, the description leaves the return shape entirely opaque.

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 description coverage is 100%, so both the account and broadcast_id parameters are already documented in the schema. The description adds no additional meaning about parameter formats or constraints, which is the expected baseline when the schema carries the load.

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?

States a specific verb and resource ('Get link clicks for a broadcast'), which is clearly distinct from sibling stats tools like get_broadcast_stats. However, it makes no attempt to differentiate itself explicitly from those siblings, and the trailing phrase 'Reads account data' muddies rather than sharpens the purpose.

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

Usage Guidelines2/5

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

There is no when-to-use guidance at all: no indication of when to prefer this over get_broadcast_stats, list_broadcast_stats, or get_email_stats, and no prerequisites or exclusions. The agent must infer usage entirely from the name.

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

get_broadcast_statsGet stats for a broadcastC

Read-onlyIdempotent

Get stats for a broadcast. Reads account data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`broadcast_id`	Yes	Positive broadcast id.

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, covering the safety profile. 'Reads account data' restates the read-only nature with no additional value such as the stats returned, latency, rate limits, or auth/account-selection behavior beyond what the parameter already says.

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

Conciseness4/5

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

Two short sentences, front-loaded with the core action and no padding. 'Reads account data' is arguably redundant filler, but the description is not bloated.

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

Completeness3/5

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

For a simple read tool with rich annotations and a fully documented schema, the description is minimally adequate. Its main gap is not positioning itself against the several confusing sibling stats tools, which an agent needs to pick the right one.

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 description coverage is 100%, with both 'account' (naming KIT_ACCOUNTS default behavior) and 'broadcast_id' fully documented in the schema. The description adds nothing about parameter format or meaning, so the baseline 3 applies.

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?

States a specific verb and resource ('Get stats for a broadcast'), so the agent knows it retrieves metrics for a single broadcast. However, it does nothing to distinguish itself from close siblings like list_broadcast_stats, get_broadcast_clicks, or get_email_stats, leaving the selection ambiguous.

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

Usage Guidelines2/5

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

There is no guidance on when to use this versus list_broadcast_stats or get_broadcast_clicks, nor any prerequisites or exclusions. 'Reads account data' is a data-source note, not usage guidance.

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

get_creator_profileGet Creator ProfileC

Read-onlyIdempotent

Get Creator Profile. Reads account data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.

TDQS

C2.1/5.0

Behavior2/5

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 only 'Reads account data,' which is redundant with the readOnly annotation and does not disclose return shape, default-account resolution behavior beyond the schema, or any 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.

Conciseness3/5

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

It is short and front-loaded, but the first sentence is pure name repetition and the second is thin, so it's terse rather than information-dense. Neither sentence earns much beyond the structured fields.

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

Completeness2/5

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

There is no output schema, so the description should describe what a creator profile returns; it does not. For a tool with zero explanation of its return payload and no differentiation from get_account, this is incomplete.

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 description coverage is 100% and the single 'account' parameter is fully documented in the schema (including the KIT_DEFAULT_ACCOUNT fallback). The description adds nothing further, so the baseline of 3 applies.

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

Purpose2/5

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

The first sentence merely restates the tool name and title ('Get Creator Profile'), and the second, 'Reads account data,' is vague and arguably misleading – it doesn't clarify what a creator profile is or how it differs from siblings like get_account or list_accounts. No specific resource detail is added beyond the name.

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

Usage Guidelines1/5

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

There is no guidance on when to use this tool versus alternatives. With get_account and list_accounts among the siblings, an agent has no way to know which to choose from the description alone.

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

get_email_statsGet email statsC

Read-onlyIdempotent

Get email stats. Reads account data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.

TDQS

C2.3/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The only additional claim, "Reads account data," merely restates what readOnlyHint already conveys; it adds no scope, rate-limit, or result-shape 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.

Conciseness3/5

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

It is short and front-loaded, which is good, but the second sentence ("Reads account data.") is pure filler that duplicates the readOnlyHint annotation rather than earning its place.

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

Completeness2/5

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

There is no output schema, so the description carries the burden of explaining what 'email stats' actually contains, and it fails to do so. No time range, no scope (account vs. broadcast), and no metric list are provided, leaving the agent unable to predict the response.

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 description coverage is 100% and the single account parameter (with its KIT_ACCOUNTS default behavior) is fully documented in the schema. The description adds nothing further about the parameter, so the baseline 3 for high coverage is correct.

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

Purpose2/5

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

The description "Get email stats" simply restates the tool name and title verbatim, offering no detail about which email metrics (opens, clicks, sends, per-broadcast vs. account-wide) are returned. It does not distinguish this tool from close siblings like get_growth_stats, get_broadcast_stats, or get_subscriber_stats.

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

Usage Guidelines2/5

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

There is no indication of when to use this tool versus the many other stats tools in the sibling list, nor any prerequisites or exclusions. The agent is left to infer usage entirely.

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

get_growth_statsGet growth statsC

Read-onlyIdempotent

Get growth stats. Reads account data.

ParametersJSON Schema

Name	Required	Description
`ending`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`starting`	No

TDQS

C2.1/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, fully covering the safety profile. The description's only behavioral claim, 'Reads account data,' is essentially a restatement of readOnlyHint and adds no rate-limit, auth, or aggregation context beyond the structured fields.

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

Conciseness3/5

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

Very short and not padded, but the first sentence merely repeats the title, so a full sentence is spent without earning its place. Front-loading is technically present but the content is empty.

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

Completeness2/5

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

For a tool with three loosely documented parameters, no output schema, and no annotation gaps to fill, the description is inadequate: it does not define the metric, the time-range parameters, or the return shape. An agent would have to guess at both scope and inputs.

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

Parameters2/5

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

Schema coverage is only 33% (account documented, ending and starting undocumented), so the description must compensate but does not. It adds no meaning about what starting/ending represent (date ranges? periods?) or their format, leaving two of three parameters opaque.

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

Purpose2/5

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

The description is essentially a tautology: 'Get growth stats' restates the name and title verbatim. 'Reads account data' is a vague domain hint but does not specify what 'growth stats' are (subscriber growth? revenue? email list growth?) or how it differs from siblings like get_email_stats and get_subscriber_stats.

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

Usage Guidelines2/5

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

No when-to-use guidance, no prerequisites, and no routing to alternatives. An agent cannot tell from this text whether to call get_growth_stats, get_email_stats, or get_subscriber_stats. Usage is only implied by the tool name.

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

get_postGet a postC

Read-onlyIdempotent

Get a post. Reads account data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`post_id`	Yes	Positive post id.

TDQS

C2.4/5.0

Behavior2/5

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds only 'Reads account data,' which is vague and does not disclose auth needs, rate limits, or return behavior 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.

Conciseness3/5

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

Two sentences, but the second sentence 'Reads account data' is vague and does not earn its place; it may even mislead. The first sentence is front-loaded but tautological.

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

Completeness3/5

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

For a simple read tool with rich annotations and full schema coverage, the description is minimally adequate but lacks sibling differentiation and any note about what a post object contains (no output schema).

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% with both parameters fully described in the input schema. The description adds no parameter meaning, so baseline 3 applies.

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

Purpose2/5

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

The description 'Get a post' is a tautological restatement of the tool name and title; it does not distinguish this tool from siblings like list_posts or get_account. The added 'Reads account data' is vague and could be confused with get_account.

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

Usage Guidelines2/5

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 such as list_posts or get_account. No prerequisites or context are provided.

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

get_purchaseGet a purchaseA

Read-onlyIdempotent

Get a purchase. Reads account data. Requires OAuth; API keys are not supported for this endpoint.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`purchase_id`	Yes	Positive purchase id.

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint. The description adds genuinely useful context beyond them: the endpoint requires OAuth and does not support API keys, which affects how an agent must authenticate. It stops short of describing return shape or failure behavior.

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

Conciseness4/5

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

Three short sentences, front-loaded with the operation before the auth caveat, with little waste. 'Reads account data' is mildly vague filler but the rest earns its place.

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?

For a single-item getter with a 100%-documented schema, full safety annotations, and no output schema, the description covers what an agent needs to call it correctly, including the OAuth caveat. The missing piece is routing guidance against list_purchases.

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 description coverage is 100%, so both parameters (account, purchase_id) are already documented in the schema. The description adds no format, default, or constraint detail beyond that; baseline 3 applies.

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?

States a specific verb+resource ('Get a purchase') that reads clearly as a single-item retrieval. It distinguishes itself implicitly from create_purchase and list_purchases via the verb, but never names them, so differentiation is left to inference.

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

Usage Guidelines2/5

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

There is no guidance on when to use this versus list_purchases or the other purchase siblings, and no stated prerequisites beyond auth. The 'Reads account data' sentence gestures at context but does not tell the agent when this tool is the right choice.

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

get_sequenceGet a sequenceC

Read-onlyIdempotent

Get a sequence. Reads account data.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`include`	No
`sequence_id`	Yes	Positive sequence id.

TDQS

C2.4/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds nothing beyond restating that it reads ('Reads account data'), providing no extra behavioral context.

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

Conciseness3/5

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

Very short and front-loaded, which is good. But the space is spent on a generic purpose statement plus a vague 'Reads account data' clause that does not earn its place by clarifying usage.

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

Completeness2/5

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

For a 3-parameter tool with an undocumented 'include' param and no output schema, the description should carry more load. It provides essentially no guidance on parameters or behavior, leaving the agent under-informed versus the sibling set.

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

Parameters2/5

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

Schema coverage is 67%, with the 'include' parameter having no description. The description mentions no parameters at all, so it cannot compensate for the undocumented 'include' field or clarify what should be included.

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

Purpose3/5

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

The description states a generic verb+resource ('Get a sequence'), so an agent knows it retrieves a sequence. However, it does not differentiate from siblings like list_sequences or get_sequence_email, and the trailing 'Reads account data' is ambiguous for a sequence-fetching tool.

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

Usage Guidelines2/5

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

There is no indication of when to use this tool versus alternatives (e.g., list_sequences to enumerate, get_sequence_email to fetch a specific email). No prerequisites or context are provided.

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

get_sequence_emailGet a sequence emailC

Read-onlyIdempotent

Get a sequence email. Reads account data.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`include`	No
`email_id`	Yes	Positive email id.
`sequence_id`	Yes	Positive sequence id.

TDQS

C2.1/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only "Reads account data," which is redundant with readOnlyHint and unclear about what account data actually means here. No return shape, permission, or failure behavior is disclosed.

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

Conciseness3/5

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

Two short sentences that are front-loaded and free of padding, but the second sentence earns no place — it conveys neither behavior nor usage. The brevity here reflects under-specification rather than disciplined concision.

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

Completeness2/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 should carry more burden, yet it never indicates what a returned sequence email contains or what `include` does. For a 4-parameter fetch tool with a hidden optional parameter, this leaves meaningful gaps an agent would have to guess at.

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

Parameters2/5

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

Schema coverage is 75%, below the 80% baseline, so the description is expected to compensate — and it does not. The undocumented `include` parameter (likely controlling what related data is expanded) is never explained, despite being the one parameter whose semantics are not self-evident. email_id and sequence_id are already described adequately in the schema.

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

Purpose2/5

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

"Get a sequence email" is a verbatim restatement of the title, adding no scope or specificity beyond the name. It does not distinguish this tool from adjacent siblings such as list_sequence_emails, get_sequence, or get_email_stats. The second sentence ("Reads account data") is ambiguous about whether it fetches account data or an email belonging to a sequence, muddying rather than clarifying the purpose.

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

Usage Guidelines2/5

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

No when-to-use guidance is given, and no alternative is named even though list_sequence_emails (bulk) and get_sequence (parent) are obvious adjacent choices. An agent must infer that this is the single-item fetch from the tool name alone.

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

get_snippetGet a snippetC

Read-onlyIdempotent

Get a snippet. Reads account data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`snippet_id`	Yes	Positive snippet id.

TDQS

C2.4/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description's only added claim, "Reads account data," is vague and does not clarify what a snippet is, whether it is scoped to the given account, or any error/absence behavior — so it adds little 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.

Conciseness3/5

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

The description is short and front-loaded, which is appropriate for a simple read tool. However, the second sentence ("Reads account data") is vague filler that does not clearly earn its place, and the overall brevity here reflects under-specification rather than deliberate economy.

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

Completeness3/5

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, annotations, and no output schema, the description is minimally sufficient to invoke correctly. It nonetheless omits what a snippet represents and any scoping/return context, leaving it adequate but bare.

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 description coverage is 100%, so both parameters (account and snippet_id) are fully documented in the schema, including defaults and the positive-integer constraint. The description contributes nothing further about parameters, which is the expected baseline of 3 when the schema does the heavy lifting.

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

Purpose2/5

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

"Get a snippet" simply restates the tool name and title, giving no differentiation from siblings like list_snippets, update_snippet, or create_snippet. While "get" and "snippet" identify a verb and resource, the sentence adds no information an agent couldn't infer from the name alone.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus list_snippets, get_snippet-adjacent retrieval tools, or update_snippet. No preconditions, no alternatives, no exclusions are stated anywhere in the description.

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

get_subscriberGet a subscriberC

Read-onlyIdempotent

Get a subscriber. Reads account data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`subscriber_id`	Yes	Positive subscriber id.

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the read-only nature is fully covered by structured data. The description adds only the vague "Reads account data," which neither explains error/not-found behavior nor adds any behavioral detail 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.

Conciseness3/5

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

The definition is very short and front-loads the purpose, but the second sentence "Reads account data" is filler that does not earn its place and is arguably ambiguous for a subscriber-fetching tool.

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

Completeness3/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 should ideally indicate what fields a fetched subscriber returns; instead it offers only the ambiguous "account data." For a simple get-by-id tool with a fully documented schema and covering annotations, this is minimally adequate but leaves a visible gap.

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 description coverage is 100%, so both subscriber_id and account are already well documented in the schema (including the KIT_ACCOUNTS defaulting behavior). The description adds no parameter meaning beyond that, so the baseline of 3 applies.

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 gives a clear verb+resource ("Get a subscriber") and the singular form implicitly distinguishes it from list_subscribers/search_subscribers. However, the second sentence ("Reads account data") is vague and does not help differentiate it from siblings such as get_subscriber_stats or get_account.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives like list_subscribers, search_subscribers, or get_subscriber_stats, nor any stated prerequisites such as whether the subscriber must exist.

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

get_subscriber_statsList stats for a subscriberC

Read-onlyIdempotent

List stats for a subscriber. Reads account data.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`subscriber_id`	Yes	Positive subscriber id.
`email_sent_after`	No
`email_sent_before`	No

TDQS

C2.7/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description's 'Reads account data' adds no meaningful behavioral context beyond what the annotations already convey, and it omits details like pagination, rate limits, or return format.

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

Conciseness4/5

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

The description is brief and front-loaded with the core action. The second sentence ('Reads account data') is somewhat redundant given the readOnly annotation, but it does not bloat the text significantly.

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

Completeness2/5

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

For a 4-parameter tool with no output schema and only 50% schema description coverage, the description is too sparse. It does not explain the two undocumented date parameters, the account selection behavior, or what the stats contain.

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

Parameters2/5

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

Schema description coverage is only 50%; email_sent_after and email_sent_before lack schema descriptions. The description does not mention any parameters or compensate for those undocumented date filters, leaving their semantics unclear.

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?

States a specific verb ('List') and resource ('stats for a subscriber'), making the purpose clear. However, it does not explicitly differentiate itself from sibling stats tools like get_email_stats or get_growth_stats, so it falls short of a 5.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as get_email_stats, get_growth_stats, or get_subscriber. There are no when-to-use or when-not-to-use conditions stated.

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

get_webhook_endpointGet a webhook endpointB

Read-onlyIdempotent

Get a webhook endpoint. Reads account data. Webhook response secrets are redacted; new signing secrets are saved only to a private local file.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`webhook_endpoint_id`	Yes	Positive webhook endpoint id.

TDQS

B3.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior beyond that: response secrets are redacted, and a new signing secret is written only to a private local file — a surprising side effect for a 'read' operation that the schema and annotations do not reveal.

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

Conciseness4/5

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

Three short clauses, no filler, and the most important behavioral detail (secret redaction/local file write) is placed where the agent will see it. Slightly weakened by the vague, low-value sentence 'Reads account data.'

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

Completeness3/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 should describe what is actually returned; instead it only says secrets are redacted and file-saved. The account-scoping and ID requirements are covered by the schema, and annotations carry the safety profile, so this is adequate but leaves the return shape unexplained.

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 description coverage is 100%, so both parameters (account and webhook_endpoint_id) are fully documented in the schema. The description adds nothing further about parameter meaning, which is acceptable here — baseline 3 applies when the schema does the heavy lifting.

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

Purpose3/5

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

The description says 'Get a webhook endpoint,' which is a clear verb+resource but is nearly a verbatim restatement of the title. It also fails to distinguish this tool from the near-identical siblings list_webhook_endpoints and get_webhook, so an agent gets no disambiguation signal.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus list_webhook_endpoints, get_webhook, or update_webhook_endpoint. 'Reads account data' is a vague statement of an effect, not a usage condition, and no prerequisites or exclusions are given.

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

list_accountsList configured accountsA

Read-onlyIdempotent

List private account labels and configured auth methods, without returning credentials or token-file paths. Does not contact Kit.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar is lower. The description still adds real value: it states credentials and token-file paths are withheld from the result and that no remote call is made, both of which are behavioral facts not derivable from the annotations alone.

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

Conciseness5/5

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

Two short sentences, zero waste. The primary action is front-loaded and the two constraints (no secrets, no network) follow immediately.

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 does a good job sketching the return contents (labels, auth methods) and what is excluded. Safety is fully covered by annotations. Minor gap: no indication of result shape or ordering, though for a zero-parameter list tool this is not critical.

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

Parameters4/5

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

The tool takes zero parameters, so there is nothing to document and the schema is trivially complete. The baseline for a parameterless tool applies; no compensating detail is needed.

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?

Names a specific verb and resource ('List private account labels and configured auth methods') and clarifies what it does not return. It does not, however, differentiate itself from the sibling get_account, which an agent may reasonably confuse with it.

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

Usage Guidelines3/5

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

Implicit usage: the phrase 'Does not contact Kit' hints this is a local/offline inspection tool, and 'list' implies enumeration vs get_account's single fetch. But there is no explicit when-to-use or when-not-to-use guidance relative to get_account.

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

list_broadcastsList broadcastsC

Read-onlyIdempotent

List broadcasts. Reads account data.

ParametersJSON Schema

Name	Required	Description
`slim`	No
`after`	No
`before`	No
`status`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`per_page`	No
`all_pages`	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.
`sent_after`	No
`sent_before`	No
`include_total_count`	No

TDQS

C2.2/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description's only added claim, 'Reads account data,' is vague and adds no behavioral context about pagination, scoping, or result caps. It does not contradict the annotations, but it adds little.

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

Conciseness3/5

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

It is short and front-loaded with the operation name, which is good. But the second sentence ('Reads account data') is redundant given the readOnlyHint annotation and does not earn its place in such a minimal description.

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

Completeness2/5

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

For an 11-parameter listing tool with no output schema, the description omits filtering semantics, pagination behavior, and default account resolution. Only a few schema fields (account, all_pages, max_items) are self-documented, so an agent has an incomplete picture of how to call this correctly.

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

Parameters1/5

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

Schema description coverage is only 27% across 11 parameters, so the description carries the burden of explaining them. It mentions nothing: not the date range filters (after/before/sent_after/sent_before), the status enum, slim, per_page, or all_pages. The undocumented parameters are left entirely opaque.

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

Purpose3/5

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

States a specific verb and resource ('List broadcasts'), which is enough to know the general operation. However, it gives no differentiation from siblings such as get_broadcast, list_broadcast_stats, or get_broadcast_stats, which all deal with the same domain. 'Reads account data' is filler that does not sharpen the purpose.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus get_broadcast, list_broadcast_stats, or the other broadcast siblings. No prerequisites, filters, or exclusions are mentioned. The agent is left to infer everything from the name.

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

list_broadcast_statsGet stats for a list of broadcastsC

Read-onlyIdempotent

Get stats for a list of broadcasts. Reads account data.

ParametersJSON Schema

Name	Required	Description
`after`	No
`before`	No
`status`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`per_page`	No
`all_pages`	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.
`sent_after`	No
`sent_before`	No
`include_total_count`	No

TDQS

C2.4/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered structurally. The description's only addition, 'Reads account data,' is vague and adds little scope information; it says nothing about pagination across the 10 parameters or what account-context behavior means.

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

Conciseness3/5

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

Two short sentences, front-loaded, with no padding or wasted phrases. However, this brevity comes from omission rather than efficiency; for a 10-parameter tool the size is inappropriate.

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

Completeness2/5

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

With 10 parameters, no output schema, and 0 required fields, the description should at least sketch the filtering and paging model. It covers neither, and gives no indication of what stats are returned or how account selection interacts with the results.

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

Parameters1/5

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

Schema description coverage is only 30%, so the description is expected to compensate for the ~7 undocumented parameters (after, before, status, per_page, sent_after, sent_before, include_total_count). It mentions no parameters at all, leaving filtering and pagination semantics entirely unexplained.

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 states a clear verb+resource combination: retrieving statistics for multiple broadcasts. This is distinguishable in principle from the singular get_broadcast_stats, but the description never names that sibling or explains the list-vs-single relationship, so an agent must infer it.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as get_broadcast_stats or list_broadcasts, despite the sibling set containing several near-identical names. An agent gets zero routing help from the description.

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

list_colorsList colorsC

Read-onlyIdempotent

List colors. Reads account data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered structurally. "Reads account data" merely restates readOnlyHint at account scope and adds no new behavioral detail such as return shape, pagination, or scope of visible colors.

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

Conciseness3/5

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

Two short fragments with zero filler and the action is front-loaded, but the brevity reflects under-specification rather than efficiency. Nothing is wasted, yet almost nothing is conveyed beyond the tool name.

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

Completeness3/5

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

For a single-optional-parameter, read-only listing tool with full schema coverage and rich annotations, and no output schema to explain, the description is minimally adequate. It still leaves the domain meaning of "colors" and the relationship to `update_colors` unstated, so it is not fully complete.

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?

There is one optional parameter and schema description coverage is 100%, so the `account` parameter, its default chain (KIT_DEFAULT_ACCOUNT / first configured account), and its source (KIT_ACCOUNTS) are already fully documented in the schema. The description contributes nothing about the parameter, so the baseline 3 applies.

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 states a specific verb ("List") and resource ("colors"), so an agent knows exactly what operation is performed. It does not, however, distinguish this from the sibling `update_colors`, and gives no hint at what a "color" object represents in this system. Clear but undifferentiated from siblings.

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

Usage Guidelines2/5

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

"Reads account data" hints at the context of use (account-scoped reads) but stops far short of guidance. There is no statement of when to call this tool, when not to, or how it relates to `update_colors` or `get_account`. An agent must infer usage entirely.

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

list_custom_fieldsList custom fieldsC

Read-onlyIdempotent

List custom fields. Reads account data.

ParametersJSON Schema

Name	Required	Description
`after`	No
`before`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`per_page`	No
`all_pages`	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.
`include_total_count`	No

TDQS

C2.6/5.0

Behavior2/5

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

'Reads account data' merely restates readOnlyHint=true that annotations already declare explicitly, adding no new behavioral context. Nothing is said about pagination behavior, result ordering, or account scoping, even though the tool is openWorld and the pagination semantics are non-trivial.

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

Conciseness3/5

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

Two short, front-loaded sentences with no noise, but the second sentence ('Reads account data') is filler that duplicates the annotation rather than doing work. Concise, yet under-specified for a 7-parameter tool.

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

Completeness2/5

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

For a paginated 7-parameter list tool with no output schema and 43% schema coverage, the description is far too thin. It omits pagination/cursor behavior, account-scoping interactions, and result shape, leaving the agent without enough to call it correctly.

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

Parameters2/5

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

Schema description coverage is only 43% (after, before, per_page, and include_total_count are undocumented), so the description carries real burden here. It provides zero parameter guidance, leaving half the parameters with no meaning documented anywhere.

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?

States a specific verb+resource ('List custom fields'), which is clear and unambiguous. However, it does not differentiate from the CRUD siblings (create_custom_field, update_custom_field, delete_custom_field, bulk_create_custom_fields), so an agent gets no help distinguishing the read variant from the write variants.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no exclusions, and no reference to alternatives such as get/list siblings or the bulk/update counterparts. The agent must infer that this is the read-all path for custom fields entirely on its own.

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

list_email_templatesList email templatesC

Read-onlyIdempotent

List email templates. Reads account data.

ParametersJSON Schema

Name	Required	Description
`after`	No
`before`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`per_page`	No
`all_pages`	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.
`include_total_count`	No

TDQS

C2.4/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description's only addition, 'Reads account data', is essentially a restatement of readOnlyHint and contributes no new behavioral context such as pagination semantics or result shape.

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

Conciseness3/5

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

Two short sentences are front-loaded and free of bloat, but the brevity comes at the cost of substance rather than through efficient expression. It is appropriately sized for what it says, nothing more.

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

Completeness2/5

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

A 7-parameter list tool with pagination controls, no output schema, and 43% schema coverage demands more than two sentences. Cursor parameters and total-count behavior are unexplained, and the return shape is not described.

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

Parameters1/5

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

Schema description coverage is only 43%: after, before, per_page, and include_total_count carry no descriptions, and the description provides no parameter semantics at all. With low coverage, the description is required to compensate, and it does not.

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?

States a specific verb (List) and resource (email templates), so an agent knows exactly what is returned. It does not differentiate itself from related listing siblings such as list_snippets or list_sequences, and adds no scope qualifier, but the core 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.

Usage Guidelines2/5

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

No indication of when to use this tool versus alternatives, nor any prerequisites. 'Reads account data' is a vague statement about data access, not guidance on invocation context.

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

list_formsList formsC

Read-onlyIdempotent

List forms. Reads account data.

ParametersJSON Schema

Name	Required	Description
`type`	No
`after`	No
`before`	No
`status`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`include`	No
`per_page`	No
`all_pages`	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.
`include_total_count`	No

TDQS

C2.6/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered without the description. The only added behavioral claim, 'Reads account data,' restates what readOnlyHint implies and says nothing about pagination (all_pages/max_items) or result shape.

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

Conciseness3/5

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

Two short sentences with no filler and the operation name front-loaded, so it is structurally sound. However, the brevity comes at the cost of under-specification rather than genuine conciseness.

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

Completeness2/5

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

For a 10-parameter listing tool with no output schema and low schema coverage, the description leaves out filtering semantics, pagination behavior, and result limits. Annotations cover the safety profile, but the definition is still too thin for an agent to invoke it confidently.

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

Parameters2/5

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

Only 3 of 10 parameters (account, all_pages, max_items) have schema descriptions, and the description adds nothing to clarify the remaining seven, including the status enum and the cursor params after/before. It does not compensate for the 30% coverage gap.

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?

States a clear verb+resource (list forms) with the added scope note that it reads account data. This is unambiguous, though it does nothing to differentiate the tool from siblings like list_subscribers_for_form or bulk_add_subscribers_to_forms.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. 'Reads account data' is a scope remark, not a usage condition, so an agent gets no help choosing this over related form/subscriber tools.

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

list_postsList postsC

Read-onlyIdempotent

List posts. Reads account data.

ParametersJSON Schema

Name	Required	Description
`after`	No
`before`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`per_page`	No
`all_pages`	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.
`include_content`	No
`include_total_count`	No

TDQS

C2.4/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds only 'Reads account data,' which is vague and partially redundant with the readOnly annotation, offering no additional behavioral context like pagination defaults, rate limits, or what 'account data' entails.

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

Conciseness4/5

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

The description is extremely concise (two short sentences) with no wasted words. However, this brevity comes at the cost of usefulness, and the second sentence is vague rather than front-loading critical information.

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

Completeness2/5

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

Given 8 parameters, 38% schema coverage, no output schema, and no annotations beyond standard hints, the description is insufficient. It fails to explain pagination behavior, filtering options, or return structure, leaving the agent without necessary context to invoke the tool correctly.

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

Parameters2/5

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

Schema description coverage is 38%, so the description must compensate for several undocumented parameters (after, before, per_page, include_content, include_total_count). The description adds no parameter detail at all, leaving over half the parameters without explanation in either schema or description.

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

Purpose3/5

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

The description states a verb+resource ('List posts') but this is essentially a restatement of the title and name. It does not distinguish from the sibling 'get_post' or explain what a 'post' is, leaving the agent to infer scope without additional specificity.

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

Usage Guidelines2/5

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

No when-to-use guidance is provided. The description does not mention alternatives like get_post for a single post, nor does it indicate context such as needing a specific account or filtering. Usage is left entirely to inference.

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

list_purchasesList purchasesC

Read-onlyIdempotent

List purchases. Reads account data. Requires OAuth; API keys are not supported for this endpoint.

ParametersJSON Schema

Name	Required	Description
`after`	No
`before`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`per_page`	No
`all_pages`	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.
`include_total_count`	No

TDQS

C2.9/5.0

Behavior4/5

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

Annotations already cover read-only/idempotent/open-world behavior, so the bar is lower, and the description adds a genuinely useful auth constraint: OAuth is required and API keys are rejected for this endpoint. That is operationally important context an agent cannot infer from the annotations or schema, though it omits rate limits and pagination behavior.

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

Conciseness4/5

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

Three short, front-loaded sentences with no padding and the auth constraint stated plainly. The first sentence is redundant with the title, costing it the top score, but overall structure is tight.

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

Completeness2/5

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

For a 7-parameter, cursor-paginated list tool with no output schema, the description is notably thin: it never explains the after/before cursors, per_page, or truncation behavior that the schema leaves undocumented. It covers auth but leaves the caller without enough to invoke the filtering/pagination surface correctly.

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

Parameters2/5

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

Schema description coverage is only 43%: after, before, per_page, and include_total_count have no schema descriptions at all. The description adds nothing about these parameters, offering no filter, cursor, or pagination semantics to compensate for the coverage gap.

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

Purpose3/5

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

The description gives a clear verb+resource ('List purchases'), which maps cleanly against siblings like get_purchase and create_purchase, but the opening sentence is a verbatim restatement of the title. Beyond that tautology it adds only 'Reads account data' and auth notes, with no scope, filtering, or result-shape detail.

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

Usage Guidelines2/5

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

No when-to-use guidance and no routing to alternatives (e.g., get_purchase for a single purchase). The 'Reads account data' clause hints at read access but does not tell the agent when this tool is the right choice over its siblings.

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

list_segmentsList segmentsC

Read-onlyIdempotent

List segments. Reads account data.

ParametersJSON Schema

Name	Required	Description
`after`	No
`before`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`per_page`	No
`all_pages`	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.
`include_total_count`	No

TDQS

C2.4/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered. 'Reads account data' merely echoes the read-only nature and adds nothing about pagination, rate limits, or account scoping that the annotations and schema do not already imply.

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

Conciseness3/5

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

The description is short and front-loaded, but the second sentence ('Reads account data.') contributes almost no information beyond the annotations. It is concise for the wrong reason: under-specification rather than disciplined editing.

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

Completeness2/5

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

For a tool with 7 parameters, no output schema, and only 43% schema description coverage, two terse sentences are insufficient. The description omits default page behavior, cursor semantics, and what a 'segment' contains, all of which an agent needs to call this list tool correctly.

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

Parameters2/5

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

Schema description coverage is only 43% (7 parameters, 4 undocumented: after, before, per_page, include_total_count), so the description should compensate for the gap. Instead it says nothing about any parameter, leaving the pagination and count parameters entirely opaque to the agent.

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

Purpose3/5

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

The description gives a verb and a resource ('List segments'), so the basic operation is identifiable, but it is essentially a restatement of the tool name and adds no scope, filter, or sibling differentiation. An agent cannot tell from this text how list_segments relates to list_sequences, list_subscribers, or the other list_* tools.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool rather than another list tool, nor any prerequisites or exclusions. 'Reads account data' describes a trait, not a selection condition, so the agent is left to infer usage entirely from the name and siblings.

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

list_sequence_emailsList sequence emailsC

Read-onlyIdempotent

List sequence emails. Reads account data.

ParametersJSON Schema

Name	Required	Description
`after`	No
`before`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`include`	No
`per_page`	No
`all_pages`	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.
`sequence_id`	Yes	Positive sequence id.
`include_content`	No
`include_total_count`	No

TDQS

C2.7/5.0

Behavior3/5

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds only 'Reads account data,' which is vague and adds little beyond what annotations already provide. With annotations carrying the burden, a 3 is appropriate.

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

Conciseness4/5

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

Two short sentences are front-loaded and efficient, though the second sentence is vague and borderline filler. No wasted length, but the content is thin.

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

Completeness2/5

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

With 10 parameters, 40% schema coverage, and no output schema, the description is far too sparse. It fails to explain pagination behavior, what 'sequence emails' actually returns, or how this differs from sibling sequence tools.

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

Parameters2/5

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

Schema coverage is 40%, so six parameters (after, before, include, per_page, include_content, include_total_count) lack descriptions anywhere. The description adds no parameter meaning, leaving a significant gap.

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

Purpose3/5

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

The description states a verb and resource ('List sequence emails'), giving clear basic purpose. However, it doesn't distinguish this tool from siblings like 'get_sequence_email' or 'list_sequences', leaving scope ambiguous within the sequence family.

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

Usage Guidelines2/5

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

No when-to-use context, no exclusions, and no alternatives named. The agent must infer from the name alone whether this returns emails in a sequence, sends them, or something else.

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

list_sequencesList sequencesC

Read-onlyIdempotent

List sequences. Reads account data.

ParametersJSON Schema

Name	Required	Description
`after`	No
`before`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`include`	No
`per_page`	No
`all_pages`	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.
`include_total_count`	No

TDQS

C2.3/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description's only addition, 'Reads account data,' adds no real behavioral value and hints at scoping that is not explained, so it does not clear the lowered bar for annotated tools.

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?

Two short sentences are not bloated, but this is under-specification presented as brevity rather than genuine conciseness. The text is too thin to earn its place as a tool definition for an eight-parameter listing endpoint.

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

Completeness2/5

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

For an eight-parameter paginated list tool with no output schema and a partially documented schema, the description leaves critical gaps: what a sequence is, cursor semantics, and the relationship between all_pages, per_page, and max_items. It is not sufficient for correct invocation.

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

Parameters2/5

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

Eight parameters with only 38% schema description coverage (after, before, include, per_page, include_total_count are undocumented in the schema), and the description supplies no parameter meaning at all. With coverage well below the 50% threshold, the description needed to compensate and does not.

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

Purpose3/5

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

The first sentence gives a clear verb+resource ('List sequences'), but it does nothing to distinguish this tool from the many other list_* siblings such as list_sequence_emails, list_segments, or list_broadcasts. The second sentence, 'Reads account data,' is vague and even mildly confusing since it suggests account-level data rather than sequences.

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

Usage Guidelines2/5

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

No when-to-use guidance, no mention of alternatives, and no exclusions. An agent cannot tell from the description when to reach for list_sequences versus list_sequence_emails or get_sequence; it must infer everything from the name.

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

list_snippetsList snippetsD

Read-onlyIdempotent

List snippets. Reads account data.

ParametersJSON Schema

Name	Required	Description
`after`	No
`before`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`archived`	No
`per_page`	No
`all_pages`	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.
`snippet_type`	No
`include_content`	No
`include_total_count`	No

TDQS

D1.9/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so safety behavior is covered structurally. "Reads account data" adds nothing beyond the readOnlyHint annotation and omits pagination behavior, multi-account resolution, and truncation semantics, which are the genuinely useful unknowns here.

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?

The two sentences are short but the problem is under-specification rather than conciseness. Nothing is front-loaded or prioritized, and both sentences are too thin to orient the caller on a 10-parameter listing tool.

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

Completeness1/5

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

With 10 optional parameters, 30% schema coverage, no output schema, and no sibling differentiation, the description is nowhere near complete enough to invoke this tool correctly. Field names like snippet_type and include_content are left entirely to inference.

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

Parameters2/5

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

Only 30% of the 10 parameters carry schema descriptions, so the burden falls on the description to compensate for the rest. It explains none of them — after, before, archived, per_page, snippet_type, include_content, and include_total_count are undocumented in both places, leaving seven parameters with zero semantic guidance.

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

Purpose2/5

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

"List snippets" merely restates the tool name and title without adding a specific verb-plus-scope framing. It never distinguishes this from siblings like get_snippet, create_snippet, or update_snippet, so the agent gets no help disambiguating the read-many operation from the read-one or write operations.

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

Usage Guidelines2/5

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

The second sentence, "Reads account data," gives no when-to-use context, no prerequisites, and no alternatives. An agent cannot tell from this whether list_snippets is preferred over get_snippet or how it relates to archived or filtered retrieval.

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

list_subscribersList subscribersC

Read-onlyIdempotent

List subscribers. Reads account data.

ParametersJSON Schema

Name	Required	Description
`slim`	No
`after`	No
`before`	No
`status`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`include`	No
`per_page`	No
`all_pages`	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.
`sort_field`	No
`sort_order`	No
`created_after`	No
`email_address`	No
`updated_after`	No
`created_before`	No
`updated_before`	No
`include_total_count`	No

TDQS

C2/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered by structured fields. The description adds nothing beyond that — it doesn't mention pagination behavior, page-size handling, sorting, or result truncation, which are the real behavioral traits an agent would need for a 17-parameter list tool.

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?

It is short, but the second sentence earns no place and the whole is under-specified rather than concise. Nothing meaningful is front-loaded beyond the tool name being restated.

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

Completeness1/5

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

For a 17-parameter tool with 18% schema coverage and no output schema, the description should carry substantial weight on filtering, pagination, and return shape. Instead it provides two sentences of content, none of which helps an agent call the tool correctly.

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

Parameters1/5

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

Schema description coverage is only 18%, so the description must compensate — and it does not mention a single parameter. Key semantics like the 'slim' flag, 'include' expansions, date-range filters, sort fields, and the all_pages/max_items truncation contract are left entirely to the thin schema, which documents only three of seventeen parameters.

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

Purpose3/5

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

The first sentence states a clear verb+resource ('List subscribers'), but the second sentence 'Reads account data' is vague filler that does not describe the resource being listed and borders on misleading, since subscribers are not account data. There is no differentiation from the many sibling listing tools (search_subscribers, filter_subscribers, list_subscribers_for_form, list_subscribers_for_tag) despite them being obvious alternatives.

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

Usage Guidelines2/5

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

No when-to-use guidance is given. Nothing tells the agent how this differs from filter_subscribers or search_subscribers, or when each filtering parameter family applies. 'Reads account data' is not usage guidance.

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

list_subscribers_for_formList subscribers for a formC

Read-onlyIdempotent

List subscribers for a form. Reads account data.

ParametersJSON Schema

Name	Required	Description
`slim`	No
`after`	No
`before`	No
`status`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`form_id`	Yes	Positive form id.
`per_page`	No
`all_pages`	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.
`added_after`	No
`added_before`	No
`created_after`	No
`created_before`	No
`include_total_count`	No

TDQS

C2.7/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. 'Reads account data' merely restates readOnlyHint and adds essentially no new behavioral context (no pagination defaults, no result-count behavior).

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

Conciseness4/5

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

Two short, front-loaded sentences with no filler. It is efficient, though the brevity reflects under-specification rather than disciplined conciseness.

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

Completeness2/5

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

For a 14-parameter listing tool with low schema coverage and no output schema, the description omits any discussion of pagination, filtering, or return shape. It leaves the agent to reconstruct usage entirely from the schema.

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

Parameters2/5

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

Schema description coverage is only 29% across 14 parameters; several (slim, after, before, status, per_page, added_*/created_* date filters, include_total_count) have no documentation in the schema. The description adds no parameter meaning whatsoever to compensate for that gap.

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?

States a specific verb (List), resource (subscribers), and scope (for a form), which cleanly separates it from list_subscribers (all subscribers) and list_subscribers_for_sequence/tag. However, it does not explicitly name or contrast with those siblings, so an agent must infer the distinction.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as filter_subscribers or search_subscribers. 'Reads account data' is a note about behavior, not a condition for selecting this tool.

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

list_subscribers_for_sequenceList subscribers for a sequenceC

Read-onlyIdempotent

List subscribers for a sequence. Reads account data.

ParametersJSON Schema

Name	Required	Description
`after`	No
`before`	No
`status`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`per_page`	No
`all_pages`	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.
`added_after`	No
`sequence_id`	Yes	Positive sequence id.
`added_before`	No
`created_after`	No
`created_before`	No
`include_total_count`	No

TDQS

C2.6/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered elsewhere. The description's only addition, 'Reads account data,' is vague and does not explain the account scoping, pagination behavior, or that results may be truncated by max_items.

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

Conciseness3/5

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

Two short sentences with no filler, so it is not bloated. But brevity comes at the cost of substance; the second sentence adds little, and nothing about the tool's many options is front-loaded.

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

Completeness2/5

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

For a 13-parameter list tool with pagination controls, date filters, a status enum, and no output schema, the description should explain filtering and paging expectations. As written it leaves the agent to discover all of that from the schema and annotations alone.

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

Parameters2/5

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

With 13 parameters and only 31% schema description coverage, the description carries a real burden here and supplies essentially nothing about filtering semantics (status enum, added_/created_ date windows, include_total_count, cursor handling). The phrase 'for a sequence' restates the required sequence_id at most.

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?

States a specific verb and resource (list subscribers) scoped to a sequence, which is clearer than a bare 'list'. However, it offers no differentiation from the several close siblings that do the same thing for other containers (list_subscribers_for_form, list_subscribers_for_tag, list_subscribers), leaving the agent to infer the distinction from names alone.

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

Usage Guidelines2/5

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

The description gives no when-to-use guidance, no prerequisites, and does not name any alternative such as filter_subscribers or list_subscribers for cases where the agent wants unsegmented or cross-sequence results. The only steer is the tool name itself.

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

list_subscribers_for_tagList subscribers for a tagC

Read-onlyIdempotent

List subscribers for a tag. Reads account data.

ParametersJSON Schema

Name	Required	Description
`slim`	No
`after`	No
`before`	No
`status`	No
`tag_id`	Yes	Positive tag id.
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`per_page`	No
`all_pages`	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.
`tagged_after`	No
`created_after`	No
`tagged_before`	No
`created_before`	No
`include_total_count`	No

TDQS

C2.4/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered without the description. 'Reads account data' hints at account scoping but is vague and adds little beyond what the account parameter and annotations already convey; nothing is said about pagination behavior or result truncation.

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

Conciseness3/5

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

Two short sentences with no padding and the purpose front-loaded. The brevity is not the problem here — the omission of any substantive details is, so it lands at minimum viable rather than efficient.

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

Completeness1/5

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

A 14-parameter, filter-heavy list tool with 29% schema coverage, no output schema, and no annotations explaining return shape. The description supplies none of the missing filtering, pagination, or account-selection context an agent needs to call it correctly.

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

Parameters1/5

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

Schema description coverage is only 29% across 14 parameters, so the description carries a heavy compensation burden — and it explains none of them. The status enum filter, the all_pages/max_items pagination pair, the four date-range parameters, and include_total_count are all left undocumented in prose.

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?

States a specific verb and resource (list subscribers scoped to a tag), which is clear on its own. However, it does nothing to distinguish itself from near-identical siblings such as list_subscribers_for_form and list_subscribers_for_sequence, so the agent must infer the distinction from the names alone.

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

Usage Guidelines2/5

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

No when-to-use guidance, no mention of alternatives, and no prerequisites beyond the required tag_id. The agent gets no help deciding this tool versus list_subscribers, filter_subscribers, or search_subscribers.

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

list_subscriber_tagsList tags for a subscriberC

Read-onlyIdempotent

List tags for a subscriber. Reads account data.

ParametersJSON Schema

Name	Required	Description
`after`	No
`before`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`per_page`	No
`all_pages`	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.
`subscriber_id`	Yes	Positive subscriber id.
`include_total_count`	No

TDQS

C2.6/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered elsewhere. The added sentence 'Reads account data' is close to a restatement of readOnlyHint and says nothing about pagination, scoping, or the account-selection behavior that the tool actually exposes.

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

Conciseness3/5

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

Very short and front-loaded with no filler sentences, which is good. But the second sentence adds almost no information, so the brevity comes from under-specification rather than efficiency.

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

Completeness2/5

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

For a read tool with 8 parameters, half of them undocumented, and no output schema, the description leaves too much unsaid. Pagination semantics and account selection are handled only inside the schema and are never surfaced to the agent.

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

Parameters2/5

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

Schema coverage is only 50% across 8 parameters, and the description supplies no parameter detail at all. Nothing explains cursor parameters (after/before), all_pages/max_items pagination, or the include_total_count flag, so the description fails to compensate for the coverage gap.

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?

States a specific verb and resource ('List tags for a subscriber'), so the agent knows exactly what it returns. It does not, however, distinguish itself from nearby siblings such as list_tags or list_subscribers_for_tag, leaving the direction of the relationship implicit.

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

Usage Guidelines2/5

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

No when-to-use guidance, no prerequisites, and no mention of alternatives. With siblings like list_tags and list_subscribers_for_tag in the same family, the agent must guess which direction of lookup applies.

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

list_tagsList tagsC

Read-onlyIdempotent

List tags. Reads account data.

ParametersJSON Schema

Name	Required	Description
`after`	No
`before`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`include`	No
`per_page`	No
`all_pages`	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.
`include_total_count`	No

TDQS

C2.3/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered elsewhere. 'Reads account data' adds only marginal scoping context and omits pagination behavior, truncation semantics, or rate limits that matter for an 8-param listing tool.

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?

Two very short sentences are front-loaded but this is under-specification rather than conciseness. Nothing is wasted, but almost nothing is supplied either.

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

Completeness2/5

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

For a tool with 8 parameters, 38% schema coverage, no output schema, and many sibling tag tools, this description is far too thin. It neither explains pagination/cursor semantics nor routes among alternative tools.

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

Parameters2/5

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

Schema description coverage is only 38%, so the description is expected to compensate for undocumented parameters such as 'after', 'before', 'include', 'per_page', and 'include_total_count'. It provides none of that; only account/all_pages/max_items carry schema descriptions.

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

Purpose3/5

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

States a verb and resource ('List tags'), so the basic operation is inferable. However, it does nothing to distinguish itself from close siblings like list_subscriber_tags and list_subscribers_for_tag, nor does it explain what a 'tag' resource represents here.

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

Usage Guidelines2/5

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

No when-to-use, when-not-to-use, or alternative-tool guidance is given. The agent must guess whether this is the right tag-listing tool versus list_subscriber_tags or list_subscribers_for_tag.

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

list_webhook_endpointsList webhook endpointsB

Read-onlyIdempotent

List webhook endpoints. Reads account data. Webhook response secrets are redacted; new signing secrets are saved only to a private local file.

ParametersJSON Schema

Name	Required	Description
`after`	No
`before`	No
`status`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`per_page`	No
`all_pages`	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.
`include_total_count`	No

TDQS

B3.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered structurally. The description earns credit by disclosing non-obvious behavior beyond the annotations: webhook response secrets are redacted and new signing secrets are written only to a private local file — a critical surprise an agent would otherwise miss.

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

Conciseness4/5

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

Three short sentences, front-loaded with the core purpose, then the scope, then the security caveat. Nothing is padded, though the middle sentence ('Reads account data') is close to filler next to the annotations.

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

Completeness3/5

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

For an 8-parameter list tool with no output schema and partial schema coverage, the description covers the distinctive secret-handling behavior but omits filtering, pagination, and default behavior (e.g., all_pages/max_items semantics). It is adequate but leaves real gaps for correct invocation.

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

Parameters2/5

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

Eight parameters with only 38% schema description coverage, and the description supplies no parameter meaning at all. Undocumented parameters such as after, before, per_page, and include_total_count receive no explanation in either place, so the description fails to compensate for the coverage gap.

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 states a specific verb and resource ('List webhook endpoints') and adds a useful scope note ('Reads account data'), so an agent knows this is a read operation over webhook endpoint records. It doesn't distinguish itself from the sibling list_webhooks, but the verb+resource pairing is clear.

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

Usage Guidelines2/5

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

There is no guidance on when to use this versus list_webhooks, get_webhook_endpoint, or list_webhooks, nor any stated prerequisites or conditions. 'Reads account data' describes what the tool touches rather than when to pick it.

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

list_webhooksList webhooksB

Read-onlyIdempotent

List webhooks. Reads account data. Webhook response secrets are redacted; new signing secrets are saved only to a private local file.

ParametersJSON Schema

Name	Required	Description
`after`	No
`before`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`per_page`	No
`all_pages`	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.
`include_total_count`	No

TDQS

B3/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description still adds genuinely useful, non-obvious behavior: response secrets are redacted, and new signing secrets are written only to a private local file rather than returned. The signing-secret sentence reads as possible boilerplate for a pure list operation, which keeps this from a 5.

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

Conciseness4/5

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

Three short sentences with the purpose front-loaded and no padding. The final clause about signing secrets is arguably off-topic for a read-only list, but the overall structure is tight and readable.

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

Completeness3/5

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

For a zero-required-parameter read-only list tool with full annotations, the description is serviceable, and the redaction note is valuable. However, it leaves the 43%-covered pagination parameters unexplained and gives no routing guidance against 'list_webhook_endpoints', both of which an agent needs for correct invocation.

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

Parameters2/5

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

Schema description coverage is only 43%: 'after', 'before', 'per_page', and 'include_total_count' are undocumented in the schema. The description supplies no compensating meaning for any parameter, so pagination and cursor behavior remain opaque. Low coverage demanded compensation that is entirely absent.

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

Purpose3/5

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

The opening sentence 'List webhooks' states a verb and resource, but it is essentially a restatement of the tool name/title rather than an elaboration. Crucially, it never distinguishes this from the adjacent sibling 'list_webhook_endpoints', so an agent cannot tell the two apart from the description alone. Purpose is legible but thin.

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

Usage Guidelines2/5

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

There is no when-to-use, when-not-to-use, or alternative-tool guidance. With 'list_webhook_endpoints' in the sibling set, some routing hint was warranted. The description states no context for selection at all.

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

pin_subscriber_locationPin a subscriber's locationA

Destructive

Pin a subscriber's location. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`location`	No
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.
`subscriber_id`	Yes	Positive subscriber id.

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is partly covered. The description adds value beyond that by naming the blast radius ('delivery, audience membership, published data or irreversible state') and the confirm gate, though 'May affect' is hedged rather than precise.

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

Conciseness4/5

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

Two short sentences, front-loaded with the action and followed by impact plus the confirm requirement; nothing is wasted. It is slightly under-specified rather than verbose, which is the right side of the trade-off.

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?

For a 6-parameter, nested-object, no-output-schema mutation tool, the description covers the destructive impact and the confirm gate, which are the two things an agent most needs. The remaining gap is the location payload structure, which the schema handles.

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 83%, so the schema already documents subscriber_id, confirm, account, payload and payload_file. The description only echoes the confirm requirement and adds no detail on the location object fields or the payload/location mutual exclusivity, so it is at the baseline.

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 states a specific verb and resource ('Pin a subscriber's location'), matching the title and clearly identifying the operation. It does not name the sibling tools (update_subscriber_location, delete_subscriber_location) it must be distinguished from, but the action itself is unambiguous.

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

Usage Guidelines3/5

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

It gives one concrete prerequisite ('Requires confirm=true'), which is genuinely useful for invocation. However, it never states when to prefer this over update_subscriber_location or delete_subscriber_location, nor what conditions make pinning appropriate, leaving the selection logic to inference.

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

revoke_previous_webhook_secretRevoke the previous webhook endpoint secretA

Destructive

Revoke the previous webhook endpoint secret. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true. Webhook response secrets are redacted; new signing secrets are saved only to a private local file.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`webhook_endpoint_id`	Yes	Positive webhook endpoint id.

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description still adds real value beyond them: it discloses that webhook response secrets are redacted and that new signing secrets are written only to a private local file, which tells the agent what it will and will not get back. The 'may affect delivery, audience membership, published data' clause is generic boilerplate for a secret revocation.

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

Conciseness4/5

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

Three tight sentences, front-loaded with the action and its prerequisite, with no filler. The middle sentence about blast radius is broad boilerplate, which keeps it short of a 5.

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?

No output schema exists, and the description compensates by explaining the return-side handling of secrets (redaction, private local file). Combined with the confirm prerequisite, an agent has enough to call this safely; only the relationship to rotate_webhook_secret is left implicit.

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

Parameters4/5

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

Schema coverage is 100% so the baseline would be 3, but the description adds a requirement the schema does not enforce: confirm is not in the required array, yet the description states confirm=true is mandatory, and it warns to set it only for this exact action. That is meaningful semantics beyond the structured fields.

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?

States a specific verb and resource (revoke the previous webhook endpoint secret), and the word 'previous' implies it acts on a superseded secret rather than the active one. It does not, however, explicitly name rotate_webhook_secret or delete_webhook_endpoint, both of which live in the sibling list and could be confused with this action.

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

Usage Guidelines3/5

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

Gives one concrete prerequisite ('Requires confirm=true'), which is genuine usage guidance, but offers no when-to-use versus rotate_webhook_secret or delete_webhook_endpoint, and no statement of when revocation is inappropriate. Usage is implied rather than routed.

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

rotate_webhook_secretRotate a webhook endpoint secretB

Destructive

Rotate a webhook endpoint secret. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true. Webhook response secrets are redacted; new signing secrets are saved only to a private local file.

ParametersJSON Schema

Name	Required	Description
`force`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`secret_name`	Yes	New private filename under KIT_PRIVATE_DIR. Required before creating/rotating a signing secret; never overwritten.
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.
`webhook_endpoint_id`	Yes	Positive webhook endpoint id.

TDQS

B3.3/5.0

Behavior2/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and non-idempotent, so the general warning 'May affect delivery, audience membership, published data or irreversible state' is boilerplate that doesn't specify what this particular rotation destroys. The useful concrete detail is that new signing secrets go only to a private local file and webhook responses are redacted – that is real value beyond annotations. However, the description concludes after this single concrete note and leaves the 409 overlap behavior almost entirely to the schema.

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

Conciseness5/5

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

Three short sentences, no rambling, front-loaded with the action. The private-file caveat is placed at the end where it matters most.

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

Completeness3/5

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

For a destructive, 7-parameter mutation with no output schema, the description gives the essential confirm requirement and the local-file side effect, but it does not explain the 409 overlap window that force specifically addresses, nor what 'affect delivery' concretely means. Adequate but leaves important operational context to the schema.

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 86%, so the schema already documents all 7 parameters thoroughly, including the force 409 semantics and secret_name pattern. The description repeats the confirm requirement but adds no parameter meaning beyond what the schema already states. Baseline 3 is correct.

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?

States a specific verb and resource: 'Rotate a webhook endpoint secret.' Clear what it does, though it doesn't explicitly differentiate from the sibling revoke_previous_webhook_secret, which handles the earlier secret.

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

Usage Guidelines3/5

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

Mentions 'Requires confirm=true,' which is implied usage guidance, but there is no explicit when-to-use vs. when-not or alternative tool routing. The condition for confirm is left to the confirm parameter's schema description.

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

search_subscribersFind subscribers by exact emailB

Read-onlyIdempotent

Compatibility alias for list_subscribers with a required exact email_address filter.

ParametersJSON Schema

Name	Required	Description
`slim`	No
`after`	No
`before`	No
`status`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`include`	No
`per_page`	No
`all_pages`	No	Read successive cursor pages, bounded by max_items (default 1000). Default false returns one API page.
`max_items`	No	Maximum records when all_pages=true. A capped result reports truncation and its continuation cursor.
`sort_field`	No
`sort_order`	No
`created_after`	No
`email_address`	Yes
`updated_after`	No
`created_before`	No
`updated_before`	No
`include_total_count`	No

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the meaningful behavioral fact that this is a compatibility alias rather than a primary tool. It does not describe pagination behavior, though the schema covers all_pages/max_items.

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

Conciseness5/5

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

A single, front-loaded sentence with no filler; the required filter is stated up front and nothing is redundant.

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

Completeness2/5

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

For a 17-parameter tool with 18% schema description coverage and no output schema, a one-line description is inadequate. Annotations cover the safety profile, but an agent still lacks guidance on the many filter, sort, and pagination parameters. The definition is under-specified relative to the tool's complexity.

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

Parameters2/5

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

Schema description coverage is only 18% (3 of 17 params documented), so the description carries a heavy burden it does not meet. It adds one useful semantic detail — that email_address is an 'exact' match — but leaves the other 14 parameters, including the status/sort enums and pagination controls, unexplained. It compensates only marginally for the coverage gap.

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 a specific verb (search/find), resource (subscribers), and scope (required exact email_address filter), and explicitly identifies the sibling it aliases (list_subscribers). An agent can tell what it does and how it differs from list_subscribers. The 'compatibility alias' framing slightly muddies whether it is a distinct capability or a legacy shim, keeping it from a 5.

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

Usage Guidelines3/5

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

Calling it a 'compatibility alias for list_subscribers' implies it exists for backward compatibility and that list_subscribers is the preferred tool, but this is left implicit. There is no explicit when-to-use/when-not guidance or statement of which alternative to prefer for new work.

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

tag_subscriberTag a subscriber by email addressA

Destructive

Tag a subscriber by email address. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`tag_id`	Yes	Positive tag id.
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.
`email_address`	No

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds valuable unannotated context: the side effects ('delivery, audience membership, published data or irreversible state') and the confirm=true gate.

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

Conciseness5/5

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

Two tight sentences with the action front-loaded and the side-effect/confirmation caveat following. No wasted words.

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?

For a destructive mutation with no output schema, the description pairs the annotations with the effect scope and confirmation requirement, which is nearly everything an agent needs. It could note the by-email vs by-id routing, but coverage is solid.

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 high (83%), so the schema already documents parameters well, and the nested payload/email_address semantics live there. The description only restates the email key and the confirm requirement, adding little beyond the schema — baseline 3.

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?

States a specific verb+resource ('Tag a subscriber by email address'), and the 'by email address' qualifier implicitly distinguishes it from the sibling tag_subscriber_by_id. It is clear and specific, though it doesn't explicitly name the by-id sibling to fully disambiguate.

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

Usage Guidelines3/5

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

The 'Requires confirm=true' line gives a concrete precondition for invocation, but there is no statement of when to prefer this over tag_subscriber_by_id, bulk_tag_subscribers, or untag_subscriber. Usage is implied rather than routed.

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

tag_subscriber_by_idTag a subscriberA

Destructive

Tag a subscriber. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`tag_id`	Yes	Positive tag id.
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`subscriber_id`	Yes	Positive subscriber id.

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds valuable behavioral context beyond the annotations: it specifies possible effects on delivery, audience membership, published data, and irreversible state, and it states the confirm=true requirement.

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

Conciseness5/5

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

Two tightly constructed sentences with the core action front-loaded. Every sentence earns its place: the first states the action, the second provides consequence and confirmation requirements.

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

Completeness3/5

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

The description adds key risk and confirm context, and annotations cover the safety profile, but it leaves a meaningful gap: it does not help the agent distinguish this by-ID tool from sibling tag_subscriber, nor does it mention the account parameter beyond the schema.

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 description coverage is 100%, so the schema already documents subscriber_id, tag_id, account, and confirm. The description only repeats the confirm parameter requirement and adds no syntax, format, or meaning beyond what the schema provides.

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?

States a specific verb and resource: 'Tag a subscriber.' It is clear what the tool does, but it does not distinguish this from sibling tools like tag_subscriber, untag_subscriber, or bulk_tag_subscribers, nor does it call out the 'by ID' scoping implied by its name.

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

Usage Guidelines2/5

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

The description gives a precondition ('Requires confirm=true') and a risk warning, but it provides no when-to-use guidance, no when-not-to-use guidance, and no routing to alternatives such as tag_subscriber or bulk_tag_subscribers.

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

unsubscribeUnsubscribe subscriberA

Destructive

Unsubscribe subscriber. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`subscriber_id`	Yes	Positive subscriber id.

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds real value beyond that: the effect scope ('delivery, audience membership, published data or irreversible state') and the mandatory confirm guard, telling the agent a write requires explicit user intent. The effect list is somewhat hedged ('May affect'), which keeps it short of a 5.

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

Conciseness4/5

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

Two short sentences with the destructive scope front-loaded and the confirm requirement last. Nothing is padded; it could be marginally tightened but there is no wasted framing.

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?

For a destructive, non-idempotent mutation with no output schema, the description covers the essential unknowns: that it is irreversible, what it touches, and that confirm=true is mandatory. It does not state reversibility of the unsubscribe (e.g., whether the subscriber can be resubscribed) or auth/scope requirements, leaving minor gaps.

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 description coverage is 100% – account, confirm, and subscriber_id each carry their own schema description, including the caution on confirm. The description only echoes the confirm requirement, adding no syntax, format, or defaulting detail beyond the schema, so the baseline 3 applies.

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 states a specific verb+resource ('Unsubscribe subscriber'), matching the title but naming the operation precisely. It does not differentiate itself from a nearby sibling like delete_subscriber, which is a plausible confusion given both remove a subscriber, but the intent is unambiguous on its own.

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

Usage Guidelines3/5

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

It gives one hard prerequisite ('Requires confirm=true'), which is genuine usage guidance. However, it offers no when-to-use/when-not guidance relative to siblings such as delete_subscriber or untag_subscriber, so the agent must infer which removal operation is appropriate.

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

untag_subscriberRemove tag from subscriberB

Destructive

Remove tag from subscriber. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`tag_id`	Yes	Positive tag id.
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`subscriber_id`	Yes	Positive subscriber id.

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is largely covered. The description adds only the confirm=true gate and a boilerplate hedging clause ("May affect delivery, audience membership, published data or irreversible state") that is not specific about which side effects actually occur.

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

Conciseness4/5

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

Three short sentences, front-loaded with the action and followed by consequences and the confirmation gate. Nothing is padded, though the middle consequence sentence is generic enough that it arguably wastes a slot.

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

Completeness3/5

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

This is a destructive, non-idempotent mutation with no output schema, and the description does cover the confirm gate and warns of side effects. It still omits the most decision-relevant facts — how this differs from untag_subscriber_by_email and what exactly is destroyed — so it is adequate but with clear gaps.

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 description coverage is 100% and all four parameters — including confirm and account — are documented in the schema itself. The description repeats the confirm requirement without adding format, syntax, or defaulting detail beyond what the schema already provides, so the baseline of 3 applies.

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?

States a specific verb and resource ("Remove tag from subscriber") matching the title, so the agent knows exactly what the call does. It does not, however, differentiate itself from the near-identical sibling untag_subscriber_by_email or from bulk_remove_tags_from_subscribers, leaving the agent to infer the distinction from names alone.

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

Usage Guidelines2/5

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

The only usage rule offered is "Requires confirm=true" – a precondition, not routing guidance. There is no statement of when to prefer this over untag_subscriber_by_email, bulk_remove_tags_from_subscribers, or delete_subscriber, so alternative selection is left entirely to inference.

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

untag_subscriber_by_emailRemove tag from subscriber by email addressA

Destructive

Remove tag from subscriber by email address. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`tag_id`	Yes	Positive tag id.
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`email_address`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds value beyond that by naming the blast radius (delivery, audience membership, published data, irreversible state) and the confirm gate, telling the agent this is not a silent toggle. It is somewhat generic phrasing, but it is real added context.

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

Conciseness4/5

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

Three short sentences, front-loaded with the action and its target, then the risk scope, then the precondition. No redundant filler; the only mild overlap is restating the confirm requirement that the schema also mentions.

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?

For a destructive mutation with no output schema, the description covers the action, the identifier, the risk scope, and the confirm gate. The main remaining gap is disambiguating from the id-based sibling, which is not addressed.

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 description coverage is 75%, and the schema itself documents tag_id, account, and confirm. email_address carries no schema description, and the description only restates that it identifies the subscriber, adding little syntax or format detail. Baseline 3 applies since the schema does most of the work.

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

Purpose5/5

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

The description gives a specific verb (Remove), resource (tag), and target identified by scope (subscriber by email address). The 'by email address' qualifier distinguishes it from the sibling untag_subscriber, which presumably targets by id, letting an agent route correctly without opening either schema.

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

Usage Guidelines3/5

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

It states a hard prerequisite ('Requires confirm=true'), which is genuine operational guidance a caller must honor. However, it never says when to choose this over the untag_subscriber (id-based) variant, nor any exclusion conditions, so context of use remains implied rather than explicit.

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

update_broadcastUpdate a broadcastA

Destructive

Update a broadcast. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`public`	No	`true` to publish this broadcast to the web. The broadcast will appear in a newsletter feed on your Creator Profile and Landing Pages.
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`content`	No
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`send_at`	No	The scheduled send time for this broadcast in ISO8601 format. If no timezone is provided, UTC is assumed.
`subject`	No
`description`	No
`broadcast_id`	Yes	Positive broadcast id.
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.
`preview_text`	No
`published_at`	No	The published timestamp to display in ISO8601 format. If no timezone is provided, UTC is assumed.
`email_address`	No	The sending email address to use. Uses the account's sending email address if not provided.
`thumbnail_alt`	No
`thumbnail_url`	No
`email_template_id`	No	Id of the email template to use. Uses the account's default template if not provided. 'Starting point' template is not supported.
`subscriber_filter`	No
`allow_starting_point`	No	Explicitly allow replacing a Starting point template body, as described in Kit’s current content-field documentation. Review the complete rendered HTML first.

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety bar is lower, yet the description adds real value: it enumerates what can be affected (delivery, audience membership, published data, irreversible state) and states the confirm=true requirement. It doesn't describe reversibility per-field or auth needs beyond confirm.

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

Conciseness5/5

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

Two compact sentences with zero filler; the impact warning and the confirm prerequisite are front-loaded. Nothing is wasted.

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

Completeness3/5

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

For an 18-param destructive mutation with a rich nested schema and no output schema, the description covers the safety profile adequately but omits return behavior and gives no guidance on the payload vs. individual flags distinction. It's minimally complete but leaves meaningful gaps for a tool this complex.

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 61%, so the schema already documents many params (content, payload, send_at, subscriber_filter, email_address, etc.). The description only surfaces confirm=true, leaving the other 17 params to the schema. Baseline 3 is appropriate for this coverage level with minimal description-side parameter detail.

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?

Clear verb+resource ('Update a broadcast') and it cites the affected domains (delivery, audience membership, published data, irreversible state), which distinguishes it from create_broadcast and delete_broadcast. It stops short of naming those siblings explicitly, so it lands just under a 5.

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

Usage Guidelines3/5

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

The description implies when the tool is used (modifying an existing broadcast) but gives no explicit when-to-use vs. when-not-to-use guidance or alternatives. The 'Requires confirm=true' clause is a procedural precondition that helps, but it isn't framed as decision guidance.

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

update_colorsUpdate colorsC

Update colors. Changes account configuration.

ParametersJSON Schema

Name	Required	Description
`colors`	No	An array of up to 10 color hex codes
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.

TDQS

C2.9/5.0

Behavior3/5

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

Annotations already declare this is a non-read-only, non-idempotent, open-world mutation with destructiveHint=false. The description adds only that it changes account configuration, which is marginally useful context beyond the annotations but omits whether colors are replaced or appended, what auth is needed, and whether unspecified colors are cleared.

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

Conciseness4/5

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

Two short sentences, front-loaded and free of filler. It is efficient, though the first sentence duplicates the tool name and the second is somewhat vague.

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

Completeness3/5

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

Given a four-parameter mutation with full schema coverage and annotations, the description is minimally adequate. However, it does not clarify the operation's effect on account configuration or how colors are applied, leaving a meaningful gap for a configuration-changing tool.

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 description coverage is 100%, so parameter meanings are already fully documented by the schema itself. The description adds no additional parameter semantics, making the baseline 3 appropriate.

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

Purpose3/5

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

"Update colors" restates the tool name and title almost verbatim, and "Changes account configuration" is a vague elaboration rather than a specific statement of what the color update affects. It does not distinguish itself from the sibling list_colors or explain what 'colors' means in this context, leaving the agent to infer the scope.

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

Usage Guidelines2/5

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

The description offers no when-to-use guidance, no prerequisites, and no alternatives. The sibling list_colors exists but is not mentioned, and there is no indication of when updating colors is appropriate versus other account-configuration operations.

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

update_custom_fieldUpdate a custom fieldC

Update a custom field. Changes account configuration.

ParametersJSON Schema

Name	Required	Description
`label`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.
`custom_field_id`	Yes	Positive custom field id.

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so safety basics are covered. The only added context is the vague note that it 'Changes account configuration', which doesn't explain what gets modified, whether updates are reversible, or permission requirements. Much more could be said for a mutation tool.

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

Conciseness4/5

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

Two short sentences with no filler; the purpose is front-loaded. However, the second sentence is low-information and could be removed without losing clarity, keeping it just shy of a 5.

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

Completeness2/5

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

The tool has 5 parameters, nested objects, and one required id, but the description omits any detail on partial vs. full updates, how payload interacts with individual body flags, or permission requirements. With no output schema and thin annotations, the description leaves substantial gaps for an agent to operate correctly.

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 description coverage is 80%, so the schema already documents account, payload, payload_file, and custom_field_id well. The description adds no parameter-level meaning beyond what is in the schema, which matches the baseline 3 when schema coverage is high.

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?

States a specific verb+resource ('Update a custom field'), which is clear on its own and distinguishes the tool from siblings like create_custom_field, delete_custom_field, and bulk_update_subscriber_custom_field_values. The second sentence adds no additional purpose clarity.

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

Usage Guidelines2/5

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 such as bulk_update_subscriber_custom_field_values or create_custom_field. No prerequisites or conditions are stated, so an agent must infer usage entirely from the name and schema.

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

update_sequenceUpdate a sequenceA

Destructive

Update a sequence. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`hold`	No	When `true`, subscribers added via Visual Automations stay in the sequence after receiving the last email.
`name`	No	The name of the sequence.
`active`	No	`true` to activate the sequence, `false` to deactivate it.
`repeat`	No	When `true`, subscribers can restart the sequence multiple times.
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`send_days`	No	The days of the week to send the sequence on. Must be one of: `monday`, `tuesday`, `wednesday`, `thursday`, `friday`, `saturday`, `sunday`.
`send_hour`	No	The hour of the day to send the sequence at. Must be an integer between 0 and 23.
`time_zone`	No	The timezone to use for the sequence. Must be a valid IANA timezone string.
`sequence_id`	Yes	Positive sequence id.
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.
`email_address`	No	The sending email address to use. Uses the account's sending email address if not provided.
`email_template_id`	No	Id of the email template to use.
`exclude_subscriber_sources`	No

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety bar is lower. The description still adds real value by naming what may be affected ("delivery, audience membership, published data or irreversible state") and surfacing the confirm=true requirement, going beyond the raw hints.

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

Conciseness5/5

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

Two sentences, both front-loaded: the action first, then the risk scope, then the confirm requirement. No filler, and the most important constraint (irreversibility + confirm) is not buried.

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

Completeness3/5

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

For a 15-parameter, nested-object, destructive mutation with no output schema, the description is thin: it never clarifies how payload, payload_file, and individual body flags relate, nor the account selector. The schema carries that load, but the description is only minimally complete for the tool's complexity.

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 description coverage is 93%, so the schema already documents all 15 parameters thoroughly (payload vs flags, payload_file, account, send_days, etc.). The description adds no parameter-level detail beyond restating the confirm requirement, so the baseline 3 applies.

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 states a clear verb+resource ("Update a sequence"), so an agent knows it mutates an existing sequence. However it does not differentiate from close siblings like update_sequence_email, update_broadcast, or create_sequence, leaving the agent to infer scope from the name alone.

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

Usage Guidelines2/5

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

It states the precondition "Requires confirm=true," which is a useful invocation rule, but gives no when-to-use/when-not guidance and never names an alternative (e.g. update_sequence_email) that would help the agent pick the right sibling. Context for choosing this tool is absent.

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

update_sequence_emailUpdate a sequence emailB

Destructive

Update a sequence email. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`content`	No	New HTML body content of the email
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`subject`	No	New subject line for the email
`email_id`	Yes	Positive email id.
`position`	No	New zero-based position of the email in the sequence
`published`	No	Pass `true` to publish a draft email or `false` to unpublish it
`send_days`	No
`delay_unit`	No	New delay unit. Use `days` for schedule-aware delivery, `hours` for a fixed hourly delay
`delay_value`	No	New delay value
`sequence_id`	Yes	Positive sequence id.
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.
`preview_text`	No	New preview text shown in email clients before the email is opened
`email_template_id`	No	New email template ID for layout and styling. Pass `null` to clear

TDQS

B3.2/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds real value on top by enumerating what can be affected — delivery behavior, audience membership, published data, irreversible state — and by flagging the confirm=true gate, which tells the agent this is a high-consequence mutation rather than a routine edit.

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

Conciseness5/5

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

Two short sentences with the impact warning front-loaded ahead of the confirmation requirement. No filler, no repetition of schema detail.

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

Completeness3/5

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

With 15 parameters, a nested payload object, three mutually exclusive body-input styles, and no output schema, the description is thin, though the 93% schema coverage absorbs most of the burden. It conveys risk and the confirm gate but says nothing about choosing between individual flags, payload, and payload_file, or about partial-update semantics.

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 description coverage is 93%, so the schema already documents all 15 parameters, including the nested payload fields, send_days reset semantics, and the payload/payload_file mutual exclusion. The description reinforces confirm=true but contributes no syntax, format, or constraint detail the schema does not already provide; baseline 3 is appropriate.

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

Purpose3/5

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

The description states a verb+resource ("Update a sequence email") but this largely restates the name and title verbatim, adding no differentiation from siblings like create_sequence_email or delete_sequence_email. The second sentence does broaden the picture by naming impact areas (delivery, audience membership, published data), which gives some sense of scope beyond a pure tautology.

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

Usage Guidelines2/5

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

The only actionable guidance is "Requires confirm=true," which is a precondition rather than a when-to-use rule. It never says when to choose this tool over delete_sequence_email, update_sequence, or create_sequence_email, and gives no conditions under which it should be avoided.

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

update_snippetUpdate a snippetA

Destructive

Update a snippet. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`snippet_id`	Yes	Positive snippet id.

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds real value beyond them by specifying the blast radius ("May affect delivery, audience membership, published data or irreversible state") and reiterating the confirm gate, telling the agent what is actually at risk.

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

Conciseness5/5

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

Two tight sentences, front-loaded with the action and immediately followed by the risk disclosure and precondition. No filler and nothing that fails to earn its place.

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?

For a non-idempotent, destructive mutation with no output schema and full annotation coverage, the description supplies the missing pieces an agent needs: the affected domains and the confirmation requirement. It is nearly complete, with only explicit sibling routing left implicit.

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 description coverage is 100%, so all three parameters (account, confirm, snippet_id) are already documented in the schema. The description's mention of confirm=true reinforces but does not extend the schema's own note that it should be set "only when the user asked for exactly this action," so baseline 3 applies.

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 states a clear verb+resource ("Update a snippet"), which cleanly separates it from create_snippet, get_snippet, and list_snippets in the sibling set. It stops short of explicitly naming or contrasting those siblings, so it lands at 4 rather than 5.

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

Usage Guidelines3/5

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

The description supplies one precondition ("Requires confirm=true") which is genuine usage guidance. However, it gives no when-to-use vs. when-not context against alternatives and does not explain what scenario warrants updating a snippet versus recreating it.

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

update_subscriberUpdate a subscriberA

Destructive

Update a subscriber. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`fields`	No
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`first_name`	No
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.
`email_address`	No
`subscriber_id`	Yes	Positive subscriber id.

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is partly covered. The description still adds real value by enumerating the blast radius — delivery, audience membership, published data, irreversible state — and the confirm requirement, which goes beyond the structured hints.

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

Conciseness4/5

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

Two short sentences with the tool identified first and the risk/confirmation guidance front-loaded; no filler. It is terse enough that it could have afforded one more sentence of useful context without becoming bloated.

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

Completeness3/5

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

With 8 parameters, nested objects, and no output schema, the description omits the response shape (e.g. the warnings array mentioned only in the schema) and the relationship between the body-flag and payload-based invocation styles. It covers the mutation's risk but not enough for an agent to fully call it correctly.

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 63% across 8 parameters, so the schema carries most parameter documentation. The description only surfaces the confirm flag (already documented in the schema) and says nothing about the payload/payload_file alternatives, the fields map, or which attributes are updatable, so it does not compensate for the coverage gap.

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 states a specific verb and resource ('Update a subscriber') and hints at the scope of the mutation (delivery, audience membership, published data, irreversible state). It is clear, but it does not distinguish this tool from near-siblings like bulk_update_subscriber_custom_field_values or update_subscriber_location.

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

Usage Guidelines3/5

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

'Requires confirm=true' gives a hard prerequisite and implies the action needs explicit user intent, which is useful gating guidance. However, there is no statement of when to choose this over the sibling update tools or any exclusions.

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

update_subscriber_locationUpdate a subscriber's pinned locationA

Destructive

Update a subscriber's pinned location. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`location`	No
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.
`subscriber_id`	Yes	Positive subscriber id.

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true, idempotentHint=false, and openWorldHint=true, but the description adds real value beyond them by naming downstream effects ('delivery, audience membership, published data') and 'irreversible state,' plus the confirm gate. It stops short of describing auth/account requirements or what exactly is overwritten.

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

Conciseness5/5

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

Three short sentences with no filler, and the safety-critical confirmation requirement is stated up front. Every sentence carries distinct information.

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?

For a destructive, non-idempotent mutation with a nested body, the description covers the confirmation gate and the affected-state risk, and there is no output schema to explain. It would be stronger if it clarified how to choose among the payload, location, and payload_file input forms.

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 description coverage is 83%, so the schema largely documents the parameters itself, including the nested location object with six required fields. The description only adds the confirm requirement, leaving payload/payload_file/account alternatives to the schema, so the baseline 3 applies.

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?

States a specific verb ('Update') and resource ('a subscriber's pinned location'), which is precise enough to distinguish it from most siblings. It does not explicitly contrast with the nearby pin_subscriber_location and delete_subscriber_location tools, which is the only missing differentiation.

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

Usage Guidelines3/5

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

States a hard precondition ('Requires confirm=true') and the confirm parameter reinforces it with 'Set true only when the user asked for exactly this action.' However, it gives no guidance on when to update versus pin or delete a location, which is the likely confusion point among siblings.

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

update_tag_nameUpdate tag nameC

Update tag name. Changes account configuration.

ParametersJSON Schema

Name	Required	Description
`name`	No
`tag_id`	Yes	Positive tag id.
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.

TDQS

C2.8/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description's only added behavioral claim is 'Changes account configuration,' which is vague and does not disclose what specifically changes, whether the change is reversible, what permissions are required, or any rate limits. It adds little beyond the structured safety hints.

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

Conciseness3/5

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

The description is short and front-loads the core action in the first sentence. However, the second sentence, 'Changes account configuration,' is vague filler that does not earn its place and could mislead. It is concise but not well-structured enough for a higher score.

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

Completeness2/5

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

For a mutation tool with 5 parameters, a nested payload object, and no output schema, the description is too thin. It does not explain how individual body flags interact with payload or payload_file, does not mention account selection, and does not clarify the scope of the update. The structured fields carry most of the burden, leaving the description incomplete.

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 description coverage is 80%, so the schema already documents most parameters (tag_id, account, payload, payload_file). The description adds no parameter-level meaning, but per the rubric a baseline of 3 is appropriate when schema coverage is high and the description does not compensate further.

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 first sentence gives a specific verb and resource: 'Update tag name.' It is clear what the tool does, but it does not differentiate itself from sibling tools like create_tag or bulk_create_tags. The second sentence, 'Changes account configuration,' is vague and does not sharpen the purpose.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention create_tag, bulk_create_tags, or any other tag-related sibling, nor does it state prerequisites or exclusions. The agent is left to infer usage from the name alone.

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

update_webhook_endpointUpdate a webhook endpointA

Destructive

Update a webhook endpoint. May affect delivery, audience membership, published data or irreversible state. Requires confirm=true. Webhook response secrets are redacted; new signing secrets are saved only to a private local file.

ParametersJSON Schema

Name	Required	Description
`url`	No
`name`	No
`events`	No
`status`	No	Endpoint status. One of: `active`, `disabled`.
`account`	No	Named private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
`description`	No
`payload_file`	No	Local JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.
`webhook_endpoint_id`	Yes	Positive webhook endpoint id.

TDQS

A3.7/5.0

Behavior4/5

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

Beyond the annotations (destructiveHint=true, idempotentHint=false), it adds genuinely useful behavior: the confirm gate, that changes may be irreversible, that response secrets are redacted, and that new signing secrets land in a private local file. Consistent with the declared annotations.

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

Conciseness4/5

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

Three short sentences, front-loaded with the purpose and the confirm requirement. The 'delivery, audience membership, published data or irreversible state' clause is somewhat scattershot boilerplate but still earns its place as a caution.

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?

For a destructive, non-idempotent 10-parameter mutation with no output schema, the description covers the safety profile, the confirm gate, and the unusual secret-file behavior. Idempotency and partial-update semantics are left to the schema but are not critical omissions.

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 60% with 10 parameters including nested payload/payload_file. The description touches only confirm and secret handling, adding little beyond the schema on the body-vs-flags conflict or the events-replacement semantics that matter most here.

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?

States a clear verb+resource ('Update a webhook endpoint') and is distinguishable from siblings like create_webhook_endpoint, delete_webhook_endpoint and rotate_webhook_secret by name alone. It does not explicitly name which sibling to prefer for related operations, so it stops short of 5.

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

Usage Guidelines3/5

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

It gives a prerequisite ('Requires confirm=true') and warns of side effects, which implies cautious use, but never states when to update versus rotate the secret, revoke a secret, or delete the endpoint. Usage context is implied rather than explicit.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

48 tool updatesv3.0.0Oct 7, 2026

Changedadd_subscriber_to_form1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

Changedadd_subscriber_to_form_by_id1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

Changedadd_subscriber_to_sequence1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

Changedadd_subscriber_to_sequence_by_id1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

Changedbulk_add_subscribers_to_forms8 fields changed

addedInput schema / $defs

Added value: +{
+  "additions": {
+    "items": {
+      "additionalProperties": false,
+      "properties": {
+        "form_id": {
+          "type": [
+            "integer",
+            "null"
+          ]
+        },
+        "referrer": {
+          "type": "string"
+        },
+        "subscriber_id": {
+          "type": [
+            "integer",
+            "null"
+          ]
+        }
+      },
+      "required": [
+        "form_id",
+        "subscriber_id"
+      ],
+      "type": "object"
+    },
+    "type": "array"
+  }
+}

addedInput schema / properties / additions / $ref
```
Added value: +"#/$defs/additions"
```

removedInput schema / properties / additions / items

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "form_id": {
-      "type": [
-        "integer",
-        "null"
-      ]
-    },
-    "referrer": {
-      "type": "string"
-    },
-    "subscriber_id": {
-      "type": [
-        "integer",
-        "null"
-      ]
-    }
-  },
-  "required": [
-    "form_id",
-    "subscriber_id"
-  ],
-  "type": "object"
-}

removedInput schema / properties / additions / type
```
Removed value: -"array"
```

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / payload / properties / additions / $ref
```
Added value: +"#/$defs/additions"
```

removedInput schema / properties / payload / properties / additions / items

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "form_id": {
-      "type": [
-        "integer",
-        "null"
-      ]
-    },
-    "referrer": {
-      "type": "string"
-    },
-    "subscriber_id": {
-      "type": [
-        "integer",
-        "null"
-      ]
-    }
-  },
-  "required": [
-    "form_id",
-    "subscriber_id"
-  ],
-  "type": "object"
-}

removedInput schema / properties / payload / properties / additions / type
```
Removed value: -"array"
```

Changedbulk_create_custom_fields1 field changed

removedInput schema / properties / confirm

Removed value: -{
-  "description": "Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user.",
-  "type": "boolean"
-}

Changedbulk_create_subscribers8 fields changed

addedInput schema / $defs

Added value: +{
+  "subscribers": {
+    "items": {
+      "additionalProperties": false,
+      "properties": {
+        "email_address": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "first_name": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "state": {
+          "enum": [
+            "active",
+            "cancelled",
+            "bounced",
+            "complained",
+            "inactive"
+          ],
+          "type": [
+            "string",
+            "null"
+          ]
+        }
+      },
+      "type": "object"
+    },
+    "type": "array"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / payload / properties / subscribers / $ref
```
Added value: +"#/$defs/subscribers"
```

removedInput schema / properties / payload / properties / subscribers / items

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "email_address": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "first_name": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "state": {
-      "enum": [
-        "active",
-        "cancelled",
-        "bounced",
-        "complained",
-        "inactive"
-      ],
-      "type": [
-        "string",
-        "null"
-      ]
-    }
-  },
-  "type": "object"
-}

removedInput schema / properties / payload / properties / subscribers / type
```
Removed value: -"array"
```
addedInput schema / properties / subscribers / $ref
```
Added value: +"#/$defs/subscribers"
```

removedInput schema / properties / subscribers / items

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "email_address": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "first_name": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "state": {
-      "enum": [
-        "active",
-        "cancelled",
-        "bounced",
-        "complained",
-        "inactive"
-      ],
-      "type": [
-        "string",
-        "null"
-      ]
-    }
-  },
-  "type": "object"
-}

removedInput schema / properties / subscribers / type
```
Removed value: -"array"
```

Changedbulk_create_tags1 field changed

removedInput schema / properties / confirm

Removed value: -{
-  "description": "Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user.",
-  "type": "boolean"
-}

Changedbulk_delete_tags10 fields changed

addedInput schema / $defs

Added value: +{
+  "tags": {
+    "description": "Tags to delete, identified by `id`. Batches of 100 or fewer are processed synchronously (200); larger batches are queued and processed asynchronously (202).",
+    "items": {
+      "additionalProperties": false,
+      "properties": {
+        "id": {
+          "description": "The id of the tag to delete.",
+          "type": "integer"
+        }
+      },
+      "required": [
+        "id"
+      ],
+      "type": "object"
+    },
+    "type": "array"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / payload / properties / tags / $ref
```
Added value: +"#/$defs/tags"
```

removedInput schema / properties / payload / properties / tags / description

Removed value: -"Tags to delete, identified by `id`. Batches of 100 or fewer are processed synchronously (200); larger batches are queued and processed asynchronously (202)."

removedInput schema / properties / payload / properties / tags / items

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "id": {
-      "description": "The id of the tag to delete.",
-      "type": "integer"
-    }
-  },
-  "required": [
-    "id"
-  ],
-  "type": "object"
-}

removedInput schema / properties / payload / properties / tags / type
```
Removed value: -"array"
```
addedInput schema / properties / tags / $ref
```
Added value: +"#/$defs/tags"
```

removedInput schema / properties / tags / description

Removed value: -"Tags to delete, identified by `id`. Batches of 100 or fewer are processed synchronously (200); larger batches are queued and processed asynchronously (202)."

removedInput schema / properties / tags / items

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "id": {
-      "description": "The id of the tag to delete.",
-      "type": "integer"
-    }
-  },
-  "required": [
-    "id"
-  ],
-  "type": "object"
-}

removedInput schema / properties / tags / type
```
Removed value: -"array"
```

Changedbulk_remove_tags_from_subscribers1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

Changedbulk_tag_subscribers8 fields changed

addedInput schema / $defs

Added value: +{
+  "taggings": {
+    "items": {
+      "additionalProperties": false,
+      "properties": {
+        "subscriber_id": {
+          "type": [
+            "integer",
+            "null"
+          ]
+        },
+        "tag_id": {
+          "type": [
+            "integer",
+            "null"
+          ]
+        }
+      },
+      "required": [
+        "tag_id",
+        "subscriber_id"
+      ],
+      "type": "object"
+    },
+    "type": "array"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / payload / properties / taggings / $ref
```
Added value: +"#/$defs/taggings"
```

removedInput schema / properties / payload / properties / taggings / items

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "subscriber_id": {
-      "type": [
-        "integer",
-        "null"
-      ]
-    },
-    "tag_id": {
-      "type": [
-        "integer",
-        "null"
-      ]
-    }
-  },
-  "required": [
-    "tag_id",
-    "subscriber_id"
-  ],
-  "type": "object"
-}

removedInput schema / properties / payload / properties / taggings / type
```
Removed value: -"array"
```
addedInput schema / properties / taggings / $ref
```
Added value: +"#/$defs/taggings"
```

removedInput schema / properties / taggings / items

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "subscriber_id": {
-      "type": [
-        "integer",
-        "null"
-      ]
-    },
-    "tag_id": {
-      "type": [
-        "integer",
-        "null"
-      ]
-    }
-  },
-  "required": [
-    "tag_id",
-    "subscriber_id"
-  ],
-  "type": "object"
-}

removedInput schema / properties / taggings / type
```
Removed value: -"array"
```

Changedbulk_update_subscriber_custom_field_values8 fields changed

addedInput schema / $defs

Added value: +{
+  "custom_field_values": {
+    "items": {
+      "additionalProperties": false,
+      "properties": {
+        "subscriber_custom_field_id": {
+          "type": "integer"
+        },
+        "subscriber_id": {
+          "type": [
+            "integer",
+            "null"
+          ]
+        },
+        "value": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "subscriber_id",
+        "subscriber_custom_field_id",
+        "value"
+      ],
+      "type": "object"
+    },
+    "type": "array"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / custom_field_values / $ref
```
Added value: +"#/$defs/custom_field_values"
```

removedInput schema / properties / custom_field_values / items

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "subscriber_custom_field_id": {
-      "type": "integer"
-    },
-    "subscriber_id": {
-      "type": [
-        "integer",
-        "null"
-      ]
-    },
-    "value": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "subscriber_id",
-    "subscriber_custom_field_id",
-    "value"
-  ],
-  "type": "object"
-}

removedInput schema / properties / custom_field_values / type
```
Removed value: -"array"
```
addedInput schema / properties / payload / properties / custom_field_values / $ref
```
Added value: +"#/$defs/custom_field_values"
```

removedInput schema / properties / payload / properties / custom_field_values / items

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "subscriber_custom_field_id": {
-      "type": "integer"
-    },
-    "subscriber_id": {
-      "type": [
-        "integer",
-        "null"
-      ]
-    },
-    "value": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "subscriber_id",
-    "subscriber_custom_field_id",
-    "value"
-  ],
-  "type": "object"
-}

removedInput schema / properties / payload / properties / custom_field_values / type
```
Removed value: -"array"
```

Changedcreate_broadcast16 fields changed

addedInput schema / $defs

Added value: +{
+  "all_item": {
+    "additionalProperties": false,
+    "properties": {
+      "ids": {
+        "items": {
+          "type": "integer"
+        },
+        "type": "array"
+      },
+      "type": {
+        "description": "`segment` or `tag`",
+        "enum": [
+          "segment",
+          "tag"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "type",
+      "ids"
+    ],
+    "type": "object"
+  },
+  "content": {
+    "description": "The HTML content of the email. On a `Classic` template this is the body, and the template adds the design around it when the broadcast is sent. On a `Starting point` template the design lives in the body, so this is the complete email: keep the wrappers, images, inline styles and Liquid tags, including `{{ unsubscribe_url }}` and `{{ address }}`. Without an unsubscribe link the broadcast can't be sent. A read returns the string that was written, so `GET`, `PUT`, `GET` round-trips, apart from Kit's own \"Built with Kit\" badge, which a `Starting point` write takes out of the body and re-applies when the email renders. A broadcast built in Kit's editor reads back as Kit's rendered HTML instead, and writing that back replaces its individually-editable blocks with one HTML block. Sending `content` in the same request as a `Starting point` `email_template_id` also needs `allow_starting_point: true`. Omit `content` and name a `Starting point` template in `email_template_id` to create the broadcast with that template's own design.",
+    "type": "string"
+  },
+  "subscriber_filter": {
+    "description": "Filters your subscribers. At this time, we only support using only one filter group type via the API (e.g. `all`, `any`, or `none` but no combinations). If nothing is provided, will default to all of your subscribers.",
+    "items": {
+      "additionalProperties": false,
+      "minProperties": 1,
+      "properties": {
+        "all": {
+          "description": "Filters your subscribers using a logical AND of all provided segment and tag ids, i.e. a subscriber would have to be part of all segments and tags provided",
+          "items": {
+            "$ref": "#/$defs/all_item"
+          },
+          "type": "array"
+        },
+        "any": {
+          "description": "Filters your subscribers using a logical OR of all provided segment and tag ids, i.e. a subscriber would have to be part of at least one of the segments or tags provided",
+          "items": {
+            "$ref": "#/$defs/all_item"
+          },
+          "type": [
+            "array",
+            "null"
+          ]
+        },
+        "none": {
+          "description": "Filters your subscribers using a logical NOT of all provided segment and tag ids, i.e. a subscriber would have to be in none of the segments or tags provided",
+          "items": {
+            "$ref": "#/$defs/all_item"
+          },
+          "type": [
+            "array",
+            "null"
+          ]
+        }
+      },
+      "required": [
+        "all",
+        "any",
+        "none"
+      ],
+      "type": "object"
+    },
+    "type": "array"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / content / $ref
```
Added value: +"#/$defs/content"
```

removedInput schema / properties / content / description

Removed value: -"The HTML content of the email. On a `Classic` template this is the body, and the template adds the design around it when the broadcast is sent. On a `Starting point` template the design lives in the body, so this is the complete email: keep the wrappers, images, inline styles and Liquid tags, including `{{ unsubscribe_url }}` and `{{ address }}`. Without an unsubscribe link the broadcast can't be sent. A read returns the string that was written, so `GET`, `PUT`, `GET` round-trips, apart from Kit's own \"Built with Kit\" badge, which a `Starting point` write takes out of the body and re-applies when the email renders. A broadcast built in Kit's editor reads back as Kit's rendered HTML instead, and writing that back replaces its individually-editable blocks with one HTML block. Sending `content` in the same request as a `Starting point` `email_template_id` also needs `allow_starting_point: true`. Omit `content` and name a `Starting point` template in `email_template_id` to create the broadcast with that template's own design."

removedInput schema / properties / content / type
```
Removed value: -"string"
```
addedInput schema / properties / payload / properties / content / $ref
```
Added value: +"#/$defs/content"
```

removedInput schema / properties / payload / properties / content / description

Removed value: -"The HTML content of the email. On a `Classic` template this is the body, and the template adds the design around it when the broadcast is sent. On a `Starting point` template the design lives in the body, so this is the complete email: keep the wrappers, images, inline styles and Liquid tags, including `{{ unsubscribe_url }}` and `{{ address }}`. Without an unsubscribe link the broadcast can't be sent. A read returns the string that was written, so `GET`, `PUT`, `GET` round-trips, apart from Kit's own \"Built with Kit\" badge, which a `Starting point` write takes out of the body and re-applies when the email renders. A broadcast built in Kit's editor reads back as Kit's rendered HTML instead, and writing that back replaces its individually-editable blocks with one HTML block. Sending `content` in the same request as a `Starting point` `email_template_id` also needs `allow_starting_point: true`. Omit `content` and name a `Starting point` template in `email_template_id` to create the broadcast with that template's own design."

removedInput schema / properties / payload / properties / content / type
```
Removed value: -"string"
```
addedInput schema / properties / payload / properties / subscriber_filter / $ref
```
Added value: +"#/$defs/subscriber_filter"
```

removedInput schema / properties / payload / properties / subscriber_filter / description

Removed value: -"Filters your subscribers. At this time, we only support using only one filter group type via the API (e.g. `all`, `any`, or `none` but no combinations). If nothing is provided, will default to all of your subscribers."

removedInput schema / properties / payload / properties / subscriber_filter / items

Removed value: -{
-  "additionalProperties": false,
-  "minProperties": 1,
-  "properties": {
-    "all": {
-      "description": "Filters your subscribers using a logical AND of all provided segment and tag ids, i.e. a subscriber would have to be part of all segments and tags provided",
-      "items": {
-        "additionalProperties": false,
-        "properties": {
-          "ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          },
-          "type": {
-            "description": "`segment` or `tag`",
-            "enum": [
-              "segment",
-              "tag"
-            ],
-            "type": "string"
-          }
-        },
-        "required": [
-          "type",
-          "ids"
-        ],
-        "type": "object"
-      },
-      "type": "array"
-    },
-    "any": {
-      "description": "Filters your subscribers using a logical OR of all provided segment and tag ids, i.e. a subscriber would have to be part of at least one of the segments or tags provided",
-      "items": {
-        "additionalProperties": false,
-        "properties": {
-          "ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          },
-          "type": {
-            "description": "`segment` or `tag`",
-            "enum": [
-              "segment",
-              "tag"
-            ],
-            "type": "string"
-          }
-        },
-        "required": [
-          "type",
-          "ids"
-        ],
-        "type": "object"
-      },
-      "type": [
-        "array",
-        "null"
-      ]
-    },
-    "none": {
-      "description": "Filters your subscribers using a logical NOT of all provided segment and tag ids, i.e. a subscriber would have to be in none of the segments or tags provided",
-      "items": {
-        "additionalProperties": false,
-        "properties": {
-          "ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          },
-          "type": {
-            "description": "`segment` or `tag`",
-            "enum": [
-              "segment",
-              "tag"
-            ],
-            "type": "string"
-          }
-        },
-        "required": [
-          "type",
-          "ids"
-        ],
-        "type": "object"
-      },
-      "type": [
-        "array",
-        "null"
-      ]
-    }
-  },
-  "required": [
-    "all",
-    "any",
-    "none"
-  ],
-  "type": "object"
-}

removedInput schema / properties / payload / properties / subscriber_filter / type
```
Removed value: -"array"
```
addedInput schema / properties / subscriber_filter / $ref
```
Added value: +"#/$defs/subscriber_filter"
```

removedInput schema / properties / subscriber_filter / description

Removed value: -"Filters your subscribers. At this time, we only support using only one filter group type via the API (e.g. `all`, `any`, or `none` but no combinations). If nothing is provided, will default to all of your subscribers."

removedInput schema / properties / subscriber_filter / items

Removed value: -{
-  "additionalProperties": false,
-  "minProperties": 1,
-  "properties": {
-    "all": {
-      "description": "Filters your subscribers using a logical AND of all provided segment and tag ids, i.e. a subscriber would have to be part of all segments and tags provided",
-      "items": {
-        "additionalProperties": false,
-        "properties": {
-          "ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          },
-          "type": {
-            "description": "`segment` or `tag`",
-            "enum": [
-              "segment",
-              "tag"
-            ],
-            "type": "string"
-          }
-        },
-        "required": [
-          "type",
-          "ids"
-        ],
-        "type": "object"
-      },
-      "type": "array"
-    },
-    "any": {
-      "description": "Filters your subscribers using a logical OR of all provided segment and tag ids, i.e. a subscriber would have to be part of at least one of the segments or tags provided",
-      "items": {
-        "additionalProperties": false,
-        "properties": {
-          "ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          },
-          "type": {
-            "description": "`segment` or `tag`",
-            "enum": [
-              "segment",
-              "tag"
-            ],
-            "type": "string"
-          }
-        },
-        "required": [
-          "type",
-          "ids"
-        ],
-        "type": "object"
-      },
-      "type": [
-        "array",
-        "null"
-      ]
-    },
-    "none": {
-      "description": "Filters your subscribers using a logical NOT of all provided segment and tag ids, i.e. a subscriber would have to be in none of the segments or tags provided",
-      "items": {
-        "additionalProperties": false,
-        "properties": {
-          "ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          },
-          "type": {
-            "description": "`segment` or `tag`",
-            "enum": [
-              "segment",
-              "tag"
-            ],
-            "type": "string"
-          }
-        },
-        "required": [
-          "type",
-          "ids"
-        ],
-        "type": "object"
-      },
-      "type": [
-        "array",
-        "null"
-      ]
-    }
-  },
-  "required": [
-    "all",
-    "any",
-    "none"
-  ],
-  "type": "object"
-}

removedInput schema / properties / subscriber_filter / type
```
Removed value: -"array"
```

Changedcreate_custom_field1 field changed

removedInput schema / properties / confirm

Removed value: -{
-  "description": "Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user.",
-  "type": "boolean"
-}

Changedcreate_purchase12 fields changed

addedInput schema / $defs

Added value: +{
+  "purchase": {
+    "additionalProperties": false,
+    "properties": {
+      "currency": {
+        "description": "3 letter currency code (e.g. `USD`)",
+        "type": "string"
+      },
+      "discount": {
+        "format": "float",
+        "type": "number"
+      },
+      "email_address": {
+        "description": "The subscriber that the purchase belongs to",
+        "type": "string"
+      },
+      "products": {
+        "description": "Array of purchased products",
+        "items": {
+          "additionalProperties": false,
+          "properties": {
+            "lid": {
+              "description": "Each product should have a unique `lid` (i.e., line item identifier) for this purchase.",
+              "type": "string"
+            },
+            "name": {
+              "description": "Product name",
+              "type": "string"
+            },
+            "pid": {
+              "description": "This is your identifier for a product. Each product provided in the `products` array must have a unique pid. Variants of the same product should have the same pid.",
+              "type": "string"
+            },
+            "quantity": {
+              "description": "Product quantity",
+              "type": "integer"
+            },
+            "sku": {
+              "description": "Product sku",
+              "type": "string"
+            },
+            "unit_price": {
+              "description": "Product price",
+              "format": "float",
+              "type": "number"
+            }
+          },
+          "required": [
+            "name",
+            "pid",
+            "lid",
+            "quantity",
+            "unit_price",
+            "sku"
+          ],
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "shipping": {
+        "type": "integer"
+      },
+      "status": {
+        "type": "string"
+      },
+      "subtotal": {
+        "format": "float",
+        "type": "number"
+      },
+      "tax": {
+        "format": "float",
+        "type": "number"
+      },
+      "total": {
+        "format": "float",
+        "type": "number"
+      },
+      "transaction_id": {
+        "type": "string"
+      },
+      "transaction_time": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "email_address",
+      "transaction_id",
+      "status",
+      "subtotal",
+      "tax",
+      "shipping",
+      "discount",
+      "total",
+      "currency",
+      "transaction_time",
+      "products"
+    ],
+    "type": "object"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / payload / properties / purchase / $ref
```
Added value: +"#/$defs/purchase"
```
removedInput schema / properties / payload / properties / purchase / additionalProperties
```
Removed value: -false
```

removedInput schema / properties / payload / properties / purchase / properties

Removed value: -{
-  "currency": {
-    "description": "3 letter currency code (e.g. `USD`)",
-    "type": "string"
-  },
-  "discount": {
-    "format": "float",
-    "type": "number"
-  },
-  "email_address": {
-    "description": "The subscriber that the purchase belongs to",
-    "type": "string"
-  },
-  "products": {
-    "description": "Array of purchased products",
-    "items": {
-      "additionalProperties": false,
-      "properties": {
-        "lid": {
-          "description": "Each product should have a unique `lid` (i.e., line item identifier) for this purchase.",
-          "type": "string"
-        },
-        "name": {
-          "description": "Product name",
-          "type": "string"
-        },
-        "pid": {
-          "description": "This is your identifier for a product. Each product provided in the `products` array must have a unique pid. Variants of the same product should have the same pid.",
-          "type": "string"
-        },
-        "quantity": {
-          "description": "Product quantity",
-          "type": "integer"
-        },
-        "sku": {
-          "description": "Product sku",
-          "type": "string"
-        },
-        "unit_price": {
-          "description": "Product price",
-          "format": "float",
-          "type": "number"
-        }
-      },
-      "required": [
-        "name",
-        "pid",
-        "lid",
-        "quantity",
-        "unit_price",
-        "sku"
-      ],
-      "type": "object"
-    },
-    "type": "array"
-  },
-  "shipping": {
-    "type": "integer"
-  },
-  "status": {
-    "type": "string"
-  },
-  "subtotal": {
-    "format": "float",
-    "type": "number"
-  },
-  "tax": {
-    "format": "float",
-    "type": "number"
-  },
-  "total": {
-    "format": "float",
-    "type": "number"
-  },
-  "transaction_id": {
-    "type": "string"
-  },
-  "transaction_time": {
-    "type": "string"
-  }
-}

removedInput schema / properties / payload / properties / purchase / required

Removed value: -[
-  "email_address",
-  "transaction_id",
-  "status",
-  "subtotal",
-  "tax",
-  "shipping",
-  "discount",
-  "total",
-  "currency",
-  "transaction_time",
-  "products"
-]

removedInput schema / properties / payload / properties / purchase / type
```
Removed value: -"object"
```
addedInput schema / properties / purchase / $ref
```
Added value: +"#/$defs/purchase"
```
removedInput schema / properties / purchase / additionalProperties
```
Removed value: -false
```

removedInput schema / properties / purchase / properties

Removed value: -{
-  "currency": {
-    "description": "3 letter currency code (e.g. `USD`)",
-    "type": "string"
-  },
-  "discount": {
-    "format": "float",
-    "type": "number"
-  },
-  "email_address": {
-    "description": "The subscriber that the purchase belongs to",
-    "type": "string"
-  },
-  "products": {
-    "description": "Array of purchased products",
-    "items": {
-      "additionalProperties": false,
-      "properties": {
-        "lid": {
-          "description": "Each product should have a unique `lid` (i.e., line item identifier) for this purchase.",
-          "type": "string"
-        },
-        "name": {
-          "description": "Product name",
-          "type": "string"
-        },
-        "pid": {
-          "description": "This is your identifier for a product. Each product provided in the `products` array must have a unique pid. Variants of the same product should have the same pid.",
-          "type": "string"
-        },
-        "quantity": {
-          "description": "Product quantity",
-          "type": "integer"
-        },
-        "sku": {
-          "description": "Product sku",
-          "type": "string"
-        },
-        "unit_price": {
-          "description": "Product price",
-          "format": "float",
-          "type": "number"
-        }
-      },
-      "required": [
-        "name",
-        "pid",
-        "lid",
-        "quantity",
-        "unit_price",
-        "sku"
-      ],
-      "type": "object"
-    },
-    "type": "array"
-  },
-  "shipping": {
-    "type": "integer"
-  },
-  "status": {
-    "type": "string"
-  },
-  "subtotal": {
-    "format": "float",
-    "type": "number"
-  },
-  "tax": {
-    "format": "float",
-    "type": "number"
-  },
-  "total": {
-    "format": "float",
-    "type": "number"
-  },
-  "transaction_id": {
-    "type": "string"
-  },
-  "transaction_time": {
-    "type": "string"
-  }
-}

removedInput schema / properties / purchase / required

Removed value: -[
-  "email_address",
-  "transaction_id",
-  "status",
-  "subtotal",
-  "tax",
-  "shipping",
-  "discount",
-  "total",
-  "currency",
-  "transaction_time",
-  "products"
-]

removedInput schema / properties / purchase / type
```
Removed value: -"object"
```

Changedcreate_sequence10 fields changed

addedInput schema / $defs

Added value: +{
+  "exclude_subscriber_sources": {
+    "description": "The subscriber sources to exclude from the sequence.",
+    "items": {
+      "additionalProperties": false,
+      "properties": {
+        "ids": {
+          "items": {
+            "description": "The ids of the subscriber sources to exclude.",
+            "type": "integer"
+          },
+          "type": "array"
+        },
+        "type": {
+          "description": "The type of subscriber source to exclude. Must be one of: `tag`, `sequence`, `form`, `segment`.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "type",
+        "ids"
+      ],
+      "type": "object"
+    },
+    "type": "array"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / exclude_subscriber_sources / $ref
```
Added value: +"#/$defs/exclude_subscriber_sources"
```
removedInput schema / properties / exclude_subscriber_sources / description
```
Removed value: -"The subscriber sources to exclude from the sequence."
```

removedInput schema / properties / exclude_subscriber_sources / items

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "ids": {
-      "items": {
-        "description": "The ids of the subscriber sources to exclude.",
-        "type": "integer"
-      },
-      "type": "array"
-    },
-    "type": {
-      "description": "The type of subscriber source to exclude. Must be one of: `tag`, `sequence`, `form`, `segment`.",
-      "type": "string"
-    }
-  },
-  "required": [
-    "type",
-    "ids"
-  ],
-  "type": "object"
-}

removedInput schema / properties / exclude_subscriber_sources / type
```
Removed value: -"array"
```
addedInput schema / properties / payload / properties / exclude_subscriber_sources / $ref
```
Added value: +"#/$defs/exclude_subscriber_sources"
```
removedInput schema / properties / payload / properties / exclude_subscriber_sources / description
```
Removed value: -"The subscriber sources to exclude from the sequence."
```

removedInput schema / properties / payload / properties / exclude_subscriber_sources / items

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "ids": {
-      "items": {
-        "description": "The ids of the subscriber sources to exclude.",
-        "type": "integer"
-      },
-      "type": "array"
-    },
-    "type": {
-      "description": "The type of subscriber source to exclude. Must be one of: `tag`, `sequence`, `form`, `segment`.",
-      "type": "string"
-    }
-  },
-  "required": [
-    "type",
-    "ids"
-  ],
-  "type": "object"
-}

removedInput schema / properties / payload / properties / exclude_subscriber_sources / type
```
Removed value: -"array"
```

Changedcreate_sequence_email10 fields changed

addedInput schema / $defs

Added value: +{
+  "send_days": {
+    "description": "Days of the week this email may be sent. Defaults to all 7 days (inherits the sequence schedule). Pass a subset to restrict delivery, or `null` to reset to all days",
+    "items": {
+      "type": "string"
+    },
+    "type": [
+      "array",
+      "null"
+    ]
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / payload / properties / send_days / $ref
```
Added value: +"#/$defs/send_days"
```

removedInput schema / properties / payload / properties / send_days / description

Removed value: -"Days of the week this email may be sent. Defaults to all 7 days (inherits the sequence schedule). Pass a subset to restrict delivery, or `null` to reset to all days"

removedInput schema / properties / payload / properties / send_days / items
```
Removed value: -{
-  "type": "string"
-}
```
removedInput schema / properties / payload / properties / send_days / type
```
Removed value: -[
-  "array",
-  "null"
-]
```
addedInput schema / properties / send_days / $ref
```
Added value: +"#/$defs/send_days"
```

removedInput schema / properties / send_days / description

Removed value: -"Days of the week this email may be sent. Defaults to all 7 days (inherits the sequence schedule). Pass a subset to restrict delivery, or `null` to reset to all days"

removedInput schema / properties / send_days / items
```
Removed value: -{
-  "type": "string"
-}
```
removedInput schema / properties / send_days / type
```
Removed value: -[
-  "array",
-  "null"
-]
```

Changedcreate_snippet1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

Changedcreate_subscriber18 fields changed

addedInput schema / $defs

Added value: +{
+  "fields": {
+    "additionalProperties": {
+      "type": "string"
+    },
+    "description": "Custom field values keyed by the custom field's `key` (e.g. `last_name`, not `Last Name`). Unknown keys are ignored and reported in the response `warnings` array.",
+    "type": "object"
+  },
+  "state": {
+    "description": "Create subscriber in this state (`active`, `bounced`, `cancelled`, `complained` or `inactive`). Defaults to `active`.",
+    "enum": [
+      "active",
+      "cancelled",
+      "bounced",
+      "complained",
+      "inactive"
+    ],
+    "type": [
+      "string",
+      "null"
+    ]
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / fields / $ref
```
Added value: +"#/$defs/fields"
```
removedInput schema / properties / fields / additionalProperties
```
Removed value: -{
-  "type": "string"
-}
```

removedInput schema / properties / fields / description

Removed value: -"Custom field values keyed by the custom field's `key` (e.g. `last_name`, not `Last Name`). Unknown keys are ignored and reported in the response `warnings` array."

removedInput schema / properties / fields / type
```
Removed value: -"object"
```
addedInput schema / properties / payload / properties / fields / $ref
```
Added value: +"#/$defs/fields"
```
removedInput schema / properties / payload / properties / fields / additionalProperties
```
Removed value: -{
-  "type": "string"
-}
```

removedInput schema / properties / payload / properties / fields / description

Removed value: -"Custom field values keyed by the custom field's `key` (e.g. `last_name`, not `Last Name`). Unknown keys are ignored and reported in the response `warnings` array."

removedInput schema / properties / payload / properties / fields / type
```
Removed value: -"object"
```
addedInput schema / properties / payload / properties / state / $ref
```
Added value: +"#/$defs/state"
```

removedInput schema / properties / payload / properties / state / description

Removed value: -"Create subscriber in this state (`active`, `bounced`, `cancelled`, `complained` or `inactive`). Defaults to `active`."

removedInput schema / properties / payload / properties / state / enum

Removed value: -[
-  "active",
-  "cancelled",
-  "bounced",
-  "complained",
-  "inactive"
-]

removedInput schema / properties / payload / properties / state / type
```
Removed value: -[
-  "string",
-  "null"
-]
```
addedInput schema / properties / state / $ref
```
Added value: +"#/$defs/state"
```

removedInput schema / properties / state / description

Removed value: -"Create subscriber in this state (`active`, `bounced`, `cancelled`, `complained` or `inactive`). Defaults to `active`."

removedInput schema / properties / state / enum

Removed value: -[
-  "active",
-  "cancelled",
-  "bounced",
-  "complained",
-  "inactive"
-]

removedInput schema / properties / state / type
```
Removed value: -[
-  "string",
-  "null"
-]
```

Changedcreate_tag1 field changed

removedInput schema / properties / confirm

Removed value: -{
-  "description": "Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user.",
-  "type": "boolean"
-}

Changedcreate_webhook12 fields changed

addedInput schema / $defs

Added value: +{
+  "event": {
+    "additionalProperties": false,
+    "properties": {
+      "custom_field_id": {},
+      "form_id": {},
+      "initiator_value": {},
+      "name": {
+        "type": "string"
+      },
+      "product_id": {},
+      "sequence_id": {},
+      "tag_id": {}
+    },
+    "required": [
+      "name",
+      "form_id",
+      "tag_id",
+      "sequence_id",
+      "product_id",
+      "initiator_value"
+    ],
+    "type": "object"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / event / $ref
```
Added value: +"#/$defs/event"
```
removedInput schema / properties / event / additionalProperties
```
Removed value: -false
```

removedInput schema / properties / event / properties

Removed value: -{
-  "custom_field_id": {},
-  "form_id": {},
-  "initiator_value": {},
-  "name": {
-    "type": "string"
-  },
-  "product_id": {},
-  "sequence_id": {},
-  "tag_id": {}
-}

removedInput schema / properties / event / required

Removed value: -[
-  "name",
-  "form_id",
-  "tag_id",
-  "sequence_id",
-  "product_id",
-  "initiator_value"
-]

removedInput schema / properties / event / type
```
Removed value: -"object"
```
addedInput schema / properties / payload / properties / event / $ref
```
Added value: +"#/$defs/event"
```
removedInput schema / properties / payload / properties / event / additionalProperties
```
Removed value: -false
```

removedInput schema / properties / payload / properties / event / properties

Removed value: -{
-  "custom_field_id": {},
-  "form_id": {},
-  "initiator_value": {},
-  "name": {
-    "type": "string"
-  },
-  "product_id": {},
-  "sequence_id": {},
-  "tag_id": {}
-}

removedInput schema / properties / payload / properties / event / required

Removed value: -[
-  "name",
-  "form_id",
-  "tag_id",
-  "sequence_id",
-  "product_id",
-  "initiator_value"
-]

removedInput schema / properties / payload / properties / event / type
```
Removed value: -"object"
```

Changedcreate_webhook_endpoint10 fields changed

addedInput schema / $defs

Added value: +{
+  "events": {
+    "description": "Event types this endpoint subscribes to (e.g. `subscriber.created`). On update, the list supplied here replaces the endpoint's full subscription list.",
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / events / $ref
```
Added value: +"#/$defs/events"
```

removedInput schema / properties / events / description

Removed value: -"Event types this endpoint subscribes to (e.g. `subscriber.created`). On update, the list supplied here replaces the endpoint's full subscription list."

removedInput schema / properties / events / items
```
Removed value: -{
-  "type": "string"
-}
```
removedInput schema / properties / events / type
```
Removed value: -"array"
```
addedInput schema / properties / payload / properties / events / $ref
```
Added value: +"#/$defs/events"
```

removedInput schema / properties / payload / properties / events / description

Removed value: -"Event types this endpoint subscribes to (e.g. `subscriber.created`). On update, the list supplied here replaces the endpoint's full subscription list."

removedInput schema / properties / payload / properties / events / items
```
Removed value: -{
-  "type": "string"
-}
```
removedInput schema / properties / payload / properties / events / type
```
Removed value: -"array"
```

Changeddelete_broadcast1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_custom_field1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_sequence1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_sequence_email1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_subscriber_location1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_webhook1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_webhook_endpoint1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

Changedfilter_subscribers35 fields changed

addedInput schema / $defs

Added value: +{
+  "all": {
+    "description": "Array of filter conditions where ALL must be met (AND logic)",
+    "items": {
+      "additionalProperties": false,
+      "description": "A filter condition with type and optional parameters. Used within the 'all' array for complex filtering where multiple conditions must be met.",
+      "properties": {
+        "after": {
+          "description": "Start date (YYYY-MM-DD). For 'subscribed' type, filters by subscriber_created_at. For engagement types, filters by event date. Not applicable for 'tags', 'subscriber_state', 'attribution', or 'custom_field' types.",
+          "format": "date",
+          "type": "string"
+        },
+        "any": {
+          "description": "Array of OR conditions. Subscriber activity must match ANY of these conditions. Engagement types accept broadcasts/URLs; 'tags' accepts tag id matchers; 'attribution' accepts attribution sub-conditions ('forms' or 'kit_source'). Not applicable for 'subscribed', 'subscriber_state', 'custom_field', or 'location' types.",
+          "items": {
+            "oneOf": [
+              {
+                "additionalProperties": false,
+                "description": "Filter by specific broadcast IDs. Subscriber must have interacted with ANY of the specified broadcasts.",
+                "properties": {
+                  "ids": {
+                    "description": "Array of broadcast IDs. Subscriber must match ANY of these.",
+                    "items": {
+                      "type": "integer"
+                    },
+                    "type": "array"
+                  },
+                  "type": {
+                    "description": "Must be 'broadcasts'",
+                    "enum": [
+                      "broadcasts"
+                    ],
+                    "type": "string"
+                  }
+                },
+                "required": [
+                  "type",
+                  "ids"
+                ],
+                "title": "Broadcasts",
+                "type": "object"
+              },
+              {
+                "additionalProperties": false,
+                "description": "Filter by URL patterns. Only applicable for 'clicks' type. Subscriber must have clicked ANY of the specified URLs.",
+                "properties": {
+                  "ids": {
+                    "description": "Array of URL IDs. Subscriber must have clicked ANY of these.",
+                    "items": {
+                      "type": "integer"
+                    },
+                    "type": "array"
+                  },
+                  "matching": {
+                    "default": "exact",
+                    "description": "URL matching strategy",
+                    "enum": [
+                      "exact",
+                      "contains",
+                      "starts_with",
+                      "ends_with"
+                    ],
+                    "type": "string"
+                  },
+                  "type": {
+                    "description": "Must be 'urls'",
+                    "enum": [
+                      "urls"
+                    ],
+                    "type": "string"
+                  },
+                  "urls": {
+                    "description": "Array of URL patterns. Subscriber must have clicked ANY of these.",
+                    "items": {
+                      "type": "string"
+                    },
+                    "type": "array"
+                  }
+                },
+                "required": [
+                  "type"
+                ],
+                "title": "URLs (clicks only)",
+                "type": "object"
+              },
+              {
+                "additionalProperties": false,
+                "description": "Match a list of ids. Used by the 'tags' filter to select tag ids.",
+                "properties": {
+                  "matching": {
+                    "description": "Ids the filter should match against.",
+                    "items": {
+                      "type": "integer"
+                    },
+                    "type": "array"
+                  },
+                  "type": {
+                    "description": "Must be 'ids'",
+                    "enum": [
+                      "ids"
+                    ],
+                    "type": "string"
+                  }
+                },
+                "required": [
+                  "type",
+                  "matching"
+                ],
+                "title": "Tag ids (tags only)",
+                "type": "object"
+              },
+              {
+                "additionalProperties": false,
+                "description": "Attribution sub-condition: matches subscribers whose original signup attribution points at one of the given form / landing-page ids. Ids may refer to either a form or a legacy landing page : the attribution source does not distinguish between the two.",
+                "properties": {
+                  "ids": {
+                    "description": "Form / landing-page ids the subscriber's attribution should match.",
+                    "items": {
+                      "type": "integer"
+                    },
+                    "type": "array"
+                  },
+                  "type": {
+                    "description": "Must be 'forms'",
+                    "enum": [
+                      "forms"
+                    ],
+                    "type": "string"
+                  }
+                },
+                "required": [
+                  "type",
+                  "ids"
+                ],
+                "title": "Forms (attribution only)",
+                "type": "object"
+              },
+              {
+                "additionalProperties": false,
+                "description": "Attribution sub-condition: matches subscribers whose original signup attribution row matches any combination of the supplied Kit source fields. All fields are optional; supplied fields are ANDed together against the same attribution row, and array fields (`source_ids`, `source_names`, `mechanism_ids`) match any value in the array. Known `source_type` values include `form_subscription` (form / landing-page signup), `api_subscription` (added via the API), and `manual` (added by the creator). Multiple entries in the parent `attribution` filter's `any` array are OR-ed together (consistent with `any` semantics elsewhere in this endpoint), so use separate entries to express \"kit_source A OR kit_source B\".",
+                "properties": {
+                  "mechanism": {
+                    "description": "Match attribution rows whose `kit_source_mechanism` equals this value.",
+                    "type": "string"
+                  },
+                  "mechanism_ids": {
+                    "description": "Match attribution rows whose `kit_source_mechanism_id` is in this list.",
+                    "items": {
+                      "type": "integer"
+                    },
+                    "type": "array"
+                  },
+                  "source_ids": {
+                    "description": "Match attribution rows whose `kit_source_id` is in this list.",
+                    "items": {
+                      "type": "integer"
+                    },
+                    "type": "array"
+                  },
+                  "source_names": {
+                    "description": "Match attribution rows whose `kit_source_name` is in this list.",
+                    "items": {
+                      "type": "string"
+                    },
+                    "type": "array"
+                  },
+                  "source_type": {
+                    "description": "Match attribution rows whose `kit_source_type` equals this value.",
+                    "type": "string"
+                  },
+                  "type": {
+                    "description": "Must be 'kit_source'",
+                    "enum": [
+                      "kit_source"
+                    ],
+                    "type": "string"
+                  }
+                },
+                "required": [
+                  "type"
+                ],
+                "title": "Kit source (attribution only)",
+                "type": "object"
+              }
+            ]
+          },
+          "type": "array"
+        },
+        "before": {
+          "description": "End date (YYYY-MM-DD). For 'subscribed' type, filters by subscriber_created_at. For engagement types, filters by event date. Not applicable for 'tags', 'subscriber_state', 'attribution', or 'custom_field' types.",
+          "format": "date",
+          "type": "string"
+        },
+        "comparison": {
+          "description": "How `value` is matched against the stored custom-field value. `is` is exact equality, `contains` is a case-insensitive substring (blank `value` matches any subscriber that has a value stored for the field), `has_value` matches any non-empty stored value (ignores `value`), `greater_than` / `greater_than_or_equal` / `less_than` / `less_than_or_equal` compare numerically. Only applicable for 'custom_field' type.",
+          "enum": [
+            "is",
+            "contains",
+            "has_value",
+            "greater_than",
+            "greater_than_or_equal",
+            "less_than",
+            "less_than_or_equal"
+          ],
+          "type": "string"
+        },
+        "count_greater_than": {
+          "description": "Minimum count (exclusive). Only applicable for engagement types ('opens', 'clicks', 'sent', 'delivered').",
+          "type": "integer"
+        },
+        "count_greater_than_or_equal": {
+          "description": "Minimum count (inclusive). Only applicable for engagement types ('opens', 'clicks', 'sent', 'delivered').",
+          "type": "integer"
+        },
+        "count_less_than": {
+          "description": "Maximum count (exclusive). Only applicable for engagement types ('opens', 'clicks', 'sent', 'delivered').",
+          "type": "integer"
+        },
+        "count_less_than_or_equal": {
+          "description": "Maximum count (inclusive). Only applicable for engagement types ('opens', 'clicks', 'sent', 'delivered').",
+          "type": "integer"
+        },
+        "latitude": {
+          "description": "Center latitude (decimal degrees). Required for the 'location' type. Combined with `longitude` and `radius` to form a bounding box around the point.",
+          "format": "float",
+          "type": "number"
+        },
+        "longitude": {
+          "description": "Center longitude (decimal degrees). Required for the 'location' type.",
+          "format": "float",
+          "type": "number"
+        },
+        "radius": {
+          "description": "Radius around (`latitude`, `longitude`) in miles. Required for the 'location' type. Subscribers whose primary location falls inside the bounding box pass the filter.",
+          "type": "number"
+        },
+        "states": {
+          "description": "Subscriber lifecycle states. Required for 'subscriber_state' type; ignored for other types. Subscribers matching any of the listed states pass the filter. Strongly recommended to use `['active']` unless you specifically need other states : most subscriber-facing queries elsewhere in the app scope to active subscribers by default.",
+          "items": {
+            "enum": [
+              "active",
+              "inactive",
+              "bounced",
+              "cancelled",
+              "complained"
+            ],
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "subscriber_custom_field_id": {
+          "description": "Id of the custom field whose stored value is being filtered on. Required for 'custom_field' type; ignored for other types.",
+          "type": "integer"
+        },
+        "type": {
+          "description": "Type of filter condition. `attribution` matches subscribers by their *original signup attribution* : supports two sub-conditions: `forms` matches by the form / landing-page id the subscriber signed up through, and `kit_source` matches by any combination of the underlying Kit source fields (source type, source id, source name, mechanism, mechanism id). Attribution is the original signup source; it does not track current subscription state. `custom_field` matches subscribers by the value they have stored for a particular custom field, identified by `subscriber_custom_field_id`. `location` matches subscribers whose primary location falls within a `radius` (miles) of (`latitude`, `longitude`). All three fields are required.",
+          "enum": [
+            "opens",
+            "clicks",
+            "sent",
+            "delivered",
+            "subscribed",
+            "subscriber_state",
+            "tags",
+            "attribution",
+            "custom_field",
+            "location"
+          ],
+          "type": "string"
+        },
+        "value": {
+          "description": "Value to compare against. Used by 'custom_field' type together with `comparison`. For the numeric comparisons (`greater_than`, `greater_than_or_equal`, `less_than`, `less_than_or_equal`) the value is parsed as a number; non-numeric stored values are excluded. Ignored when `comparison` is `has_value`.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "type"
+      ],
+      "type": "object"
+    },
+    "type": "array"
+  },
+  "counting_mode": {
+    "description": "Controls how engagement-filter count thresholds are tallied. `raw` (default) counts every event : five opens of the same email = five. `unique_email` counts distinct emails on which the action occurred : five opens of the same email = one. Applies to every engagement filter (opens, clicks, sent, delivered) in the request; ignored for other filter types.",
+    "enum": [
+      "raw",
+      "unique_email"
+    ],
+    "type": "string"
+  },
+  "include": {
+    "description": "Optional. Array of `{ type, ...config }` objects naming additional fields to embed on each subscriber row. Valid types: `attribution`, `tags`, `location`, `canceled_at`, `stats`, `custom_fields`. The `stats` type accepts an optional `range: { start, end }` (YYYY-MM-DD dates, defaulting to the last 90 days). The `custom_fields` type adds a `fields` object with all account custom field values (null for fields the subscriber has not set).",
+    "items": {
+      "additionalProperties": false,
+      "properties": {
+        "range": {
+          "additionalProperties": false,
+          "description": "Only used by the `stats` type. Date window for the engagement stats. Defaults to the last 90 days; clamped to the account's data-retention window.",
+          "properties": {
+            "end": {
+              "format": "date",
+              "type": "string"
+            },
+            "start": {
+              "format": "date",
+              "type": "string"
+            }
+          },
+          "type": "object"
+        },
+        "type": {
+          "enum": [
+            "attribution",
+            "tags",
+            "location",
+            "canceled_at",
+            "stats",
+            "custom_fields"
+          ],
+          "type": "string"
+        }
+      },
+      "required": [
+        "type"
+      ],
+      "type": "object"
+    },
+    "type": "array"
+  },
+  "sort_field": {
+    "default": "created_at",
+    "description": "Field to order results by. Base columns (`id`, `first_name`, `email_address`, `created_at`) order by that subscriber attribute. `engagement__ ` orders by an engagement stat over the trailing 90 days: counts (`sent`, `opens`, `clicks`) and rates (`open_rate`, `click_rate`); subscribers with no sends order as 0. `location__distance` orders by great-circle distance and requires a `location` filter in the same request : its `latitude`/`longitude` supply the origin, and subscribers without a primary location are excluded. Distance defaults to nearest-first (`sort_order` defaults to `asc` for this field); pass `sort_order=desc` for farthest-first.",
+    "enum": [
+      "id",
+      "first_name",
+      "email_address",
+      "created_at",
+      "engagement__sent",
+      "engagement__opens",
+      "engagement__clicks",
+      "engagement__open_rate",
+      "engagement__click_rate",
+      "location__distance"
+    ],
+    "type": "string"
+  }
+}

addedInput schema / properties / all / $ref
```
Added value: +"#/$defs/all"
```

removedInput schema / properties / all / description

Removed value: -"Array of filter conditions where ALL must be met (AND logic)"

removedInput schema / properties / all / items

Removed value: -{
-  "additionalProperties": false,
-  "description": "A filter condition with type and optional parameters. Used within the 'all' array for complex filtering where multiple conditions must be met.",
-  "properties": {
-    "after": {
-      "description": "Start date (YYYY-MM-DD). For 'subscribed' type, filters by subscriber_created_at. For engagement types, filters by event date. Not applicable for 'tags', 'subscriber_state', 'attribution', or 'custom_field' types.",
-      "format": "date",
-      "type": "string"
-    },
-    "any": {
-      "description": "Array of OR conditions. Subscriber activity must match ANY of these conditions. Engagement types accept broadcasts/URLs; 'tags' accepts tag id matchers; 'attribution' accepts attribution sub-conditions ('forms' or 'kit_source'). Not applicable for 'subscribed', 'subscriber_state', 'custom_field', or 'location' types.",
-      "items": {
-        "oneOf": [
-          {
-            "additionalProperties": false,
-            "description": "Filter by specific broadcast IDs. Subscriber must have interacted with ANY of the specified broadcasts.",
-            "properties": {
-              "ids": {
-                "description": "Array of broadcast IDs. Subscriber must match ANY of these.",
-                "items": {
-                  "type": "integer"
-                },
-                "type": "array"
-              },
-              "type": {
-                "description": "Must be 'broadcasts'",
-                "enum": [
-                  "broadcasts"
-                ],
-                "type": "string"
-              }
-            },
-            "required": [
-              "type",
-              "ids"
-            ],
-            "title": "Broadcasts",
-            "type": "object"
-          },
-          {
-            "additionalProperties": false,
-            "description": "Filter by URL patterns. Only applicable for 'clicks' type. Subscriber must have clicked ANY of the specified URLs.",
-            "properties": {
-              "ids": {
-                "description": "Array of URL IDs. Subscriber must have clicked ANY of these.",
-                "items": {
-                  "type": "integer"
-                },
-                "type": "array"
-              },
-              "matching": {
-                "default": "exact",
-                "description": "URL matching strategy",
-                "enum": [
-                  "exact",
-                  "contains",
-                  "starts_with",
-                  "ends_with"
-                ],
-                "type": "string"
-              },
-              "type": {
-                "description": "Must be 'urls'",
-                "enum": [
-                  "urls"
-                ],
-                "type": "string"
-              },
-              "urls": {
-                "description": "Array of URL patterns. Subscriber must have clicked ANY of these.",
-                "items": {
-                  "type": "string"
-                },
-                "type": "array"
-              }
-            },
-            "required": [
-              "type"
-            ],
-            "title": "URLs (clicks only)",
-            "type": "object"
-          },
-          {
-            "additionalProperties": false,
-            "description": "Match a list of ids. Used by the 'tags' filter to select tag ids.",
-            "properties": {
-              "matching": {
-                "description": "Ids the filter should match against.",
-                "items": {
-                  "type": "integer"
-                },
-                "type": "array"
-              },
-              "type": {
-                "description": "Must be 'ids'",
-                "enum": [
-                  "ids"
-                ],
-                "type": "string"
-              }
-            },
-            "required": [
-              "type",
-              "matching"
-            ],
-            "title": "Tag ids (tags only)",
-            "type": "object"
-          },
-          {
-            "additionalProperties": false,
-            "description": "Attribution sub-condition: matches subscribers whose original signup attribution points at one of the given form / landing-page ids. Ids may refer to either a form or a legacy landing page : the attribution source does not distinguish between the two.",
-            "properties": {
-              "ids": {
-                "description": "Form / landing-page ids the subscriber's attribution should match.",
-                "items": {
-                  "type": "integer"
-                },
-                "type": "array"
-              },
-              "type": {
-                "description": "Must be 'forms'",
-                "enum": [
-                  "forms"
-                ],
-                "type": "string"
-              }
-            },
-            "required": [
-              "type",
-              "ids"
-            ],
-            "title": "Forms (attribution only)",
-            "type": "object"
-          },
-          {
-            "additionalProperties": false,
-            "description": "Attribution sub-condition: matches subscribers whose original signup attribution row matches any combination of the supplied Kit source fields. All fields are optional; supplied fields are ANDed together against the same attribution row, and array fields (`source_ids`, `source_names`, `mechanism_ids`) match any value in the array. Known `source_type` values include `form_subscription` (form / landing-page signup), `api_subscription` (added via the API), and `manual` (added by the creator). Multiple entries in the parent `attribution` filter's `any` array are OR-ed together (consistent with `any` semantics elsewhere in this endpoint), so use separate entries to express \"kit_source A OR kit_source B\".",
-            "properties": {
-              "mechanism": {
-                "description": "Match attribution rows whose `kit_source_mechanism` equals this value.",
-                "type": "string"
-              },
-              "mechanism_ids": {
-                "description": "Match attribution rows whose `kit_source_mechanism_id` is in this list.",
-                "items": {
-                  "type": "integer"
-                },
-                "type": "array"
-              },
-              "source_ids": {
-                "description": "Match attribution rows whose `kit_source_id` is in this list.",
-                "items": {
-                  "type": "integer"
-                },
-                "type": "array"
-              },
-              "source_names": {
-                "description": "Match attribution rows whose `kit_source_name` is in this list.",
-                "items": {
-                  "type": "string"
-                },
-                "type": "array"
-              },
-              "source_type": {
-                "description": "Match attribution rows whose `kit_source_type` equals this value.",
-                "type": "string"
-              },
-              "type": {
-                "description": "Must be 'kit_source'",
-                "enum": [
-                  "kit_source"
-                ],
-                "type": "string"
-              }
-            },
-            "required": [
-              "type"
-            ],
-            "title": "Kit source (attribution only)",
-            "type": "object"
-          }
-        ]
-      },
-      "type": "array"
-    },
-    "before": {
-      "description": "End date (YYYY-MM-DD). For 'subscribed' type, filters by subscriber_created_at. For engagement types, filters by event date. Not applicable for 'tags', 'subscriber_state', 'attribution', or 'custom_field' types.",
-      "format": "date",
-      "type": "string"
-    },
-    "comparison": {
-      "description": "How `value` is matched against the stored custom-field value. `is` is exact equality, `contains` is a case-insensitive substring (blank `value` matches any subscriber that has a value stored for the field), `has_value` matches any non-empty stored value (ignores `value`), `greater_than` / `greater_than_or_equal` / `less_than` / `less_than_or_equal` compare numerically. Only applicable for 'custom_field' type.",
-      "enum": [
-        "is",
-        "contains",
-        "has_value",
-        "greater_than",
-        "greater_than_or_equal",
-        "less_than",
-        "less_than_or_equal"
-      ],
-      "type": "string"
-    },
-    "count_greater_than": {
-      "description": "Minimum count (exclusive). Only applicable for engagement types ('opens', 'clicks', 'sent', 'delivered').",
-      "type": "integer"
-    },
-    "count_greater_than_or_equal": {
-      "description": "Minimum count (inclusive). Only applicable for engagement types ('opens', 'clicks', 'sent', 'delivered').",
-      "type": "integer"
-    },
-    "count_less_than": {
-      "description": "Maximum count (exclusive). Only applicable for engagement types ('opens', 'clicks', 'sent', 'delivered').",
-      "type": "integer"
-    },
-    "count_less_than_or_equal": {
-      "description": "Maximum count (inclusive). Only applicable for engagement types ('opens', 'clicks', 'sent', 'delivered').",
-      "type": "integer"
-    },
-    "latitude": {
-      "description": "Center latitude (decimal degrees). Required for the 'location' type. Combined with `longitude` and `radius` to form a bounding box around the point.",
-      "format": "float",
-      "type": "number"
-    },
-    "longitude": {
-      "description": "Center longitude (decimal degrees). Required for the 'location' type.",
-      "format": "float",
-      "type": "number"
-    },
-    "radius": {
-      "description": "Radius around (`latitude`, `longitude`) in miles. Required for the 'location' type. Subscribers whose primary location falls inside the bounding box pass the filter.",
-      "type": "number"
-    },
-    "states": {
-      "description": "Subscriber lifecycle states. Required for 'subscriber_state' type; ignored for other types. Subscribers matching any of the listed states pass the filter. Strongly recommended to use `['active']` unless you specifically need other states : most subscriber-facing queries elsewhere in the app scope to active subscribers by default.",
-      "items": {
-        "enum": [
-          "active",
-          "inactive",
-          "bounced",
-          "cancelled",
-          "complained"
-        ],
-        "type": "string"
-      },
-      "type": "array"
-    },
-    "subscriber_custom_field_id": {
-      "description": "Id of the custom field whose stored value is being filtered on. Required for 'custom_field' type; ignored for other types.",
-      "type": "integer"
-    },
-    "type": {
-      "description": "Type of filter condition. `attribution` matches subscribers by their *original signup attribution* : supports two sub-conditions: `forms` matches by the form / landing-page id the subscriber signed up through, and `kit_source` matches by any combination of the underlying Kit source fields (source type, source id, source name, mechanism, mechanism id). Attribution is the original signup source; it does not track current subscription state. `custom_field` matches subscribers by the value they have stored for a particular custom field, identified by `subscriber_custom_field_id`. `location` matches subscribers whose primary location falls within a `radius` (miles) of (`latitude`, `longitude`). All three fields are required.",
-      "enum": [
-        "opens",
-        "clicks",
-        "sent",
-        "delivered",
-        "subscribed",
-        "subscriber_state",
-        "tags",
-        "attribution",
-        "custom_field",
-        "location"
-      ],
-      "type": "string"
-    },
-    "value": {
-      "description": "Value to compare against. Used by 'custom_field' type together with `comparison`. For the numeric comparisons (`greater_than`, `greater_than_or_equal`, `less_than`, `less_than_or_equal`) the value is parsed as a number; non-numeric stored values are excluded. Ignored when `comparison` is `has_value`.",
-      "type": "string"
-    }
-  },
-  "required": [
-    "type"
-  ],
-  "type": "object"
-}

removedInput schema / properties / all / type
```
Removed value: -"array"
```
addedInput schema / properties / counting_mode / $ref
```
Added value: +"#/$defs/counting_mode"
```

removedInput schema / properties / counting_mode / description

Removed value: -"Controls how engagement-filter count thresholds are tallied. `raw` (default) counts every event : five opens of the same email = five. `unique_email` counts distinct emails on which the action occurred : five opens of the same email = one. Applies to every engagement filter (opens, clicks, sent, delivered) in the request; ignored for other filter types."

removedInput schema / properties / counting_mode / enum
```
Removed value: -[
-  "raw",
-  "unique_email"
-]
```
removedInput schema / properties / counting_mode / type
```
Removed value: -"string"
```
addedInput schema / properties / include / $ref
```
Added value: +"#/$defs/include"
```

removedInput schema / properties / include / description

Removed value: -"Optional. Array of `{ type, ...config }` objects naming additional fields to embed on each subscriber row. Valid types: `attribution`, `tags`, `location`, `canceled_at`, `stats`, `custom_fields`. The `stats` type accepts an optional `range: { start, end }` (YYYY-MM-DD dates, defaulting to the last 90 days). The `custom_fields` type adds a `fields` object with all account custom field values (null for fields the subscriber has not set)."

removedInput schema / properties / include / items

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "range": {
-      "additionalProperties": false,
-      "description": "Only used by the `stats` type. Date window for the engagement stats. Defaults to the last 90 days; clamped to the account's data-retention window.",
-      "properties": {
-        "end": {
-          "format": "date",
-          "type": "string"
-        },
-        "start": {
-          "format": "date",
-          "type": "string"
-        }
-      },
-      "type": "object"
-    },
-    "type": {
-      "enum": [
-        "attribution",
-        "tags",
-        "location",
-        "canceled_at",
-        "stats",
-        "custom_fields"
-      ],
-      "type": "string"
-    }
-  },
-  "required": [
-    "type"
-  ],
-  "type": "object"
-}

removedInput schema / properties / include / type
```
Removed value: -"array"
```
addedInput schema / properties / payload / properties / all / $ref
```
Added value: +"#/$defs/all"
```

removedInput schema / properties / payload / properties / all / description

Removed value: -"Array of filter conditions where ALL must be met (AND logic)"

removedInput schema / properties / payload / properties / all / items

Removed value: -{
-  "additionalProperties": false,
-  "description": "A filter condition with type and optional parameters. Used within the 'all' array for complex filtering where multiple conditions must be met.",
-  "properties": {
-    "after": {
-      "description": "Start date (YYYY-MM-DD). For 'subscribed' type, filters by subscriber_created_at. For engagement types, filters by event date. Not applicable for 'tags', 'subscriber_state', 'attribution', or 'custom_field' types.",
-      "format": "date",
-      "type": "string"
-    },
-    "any": {
-      "description": "Array of OR conditions. Subscriber activity must match ANY of these conditions. Engagement types accept broadcasts/URLs; 'tags' accepts tag id matchers; 'attribution' accepts attribution sub-conditions ('forms' or 'kit_source'). Not applicable for 'subscribed', 'subscriber_state', 'custom_field', or 'location' types.",
-      "items": {
-        "oneOf": [
-          {
-            "additionalProperties": false,
-            "description": "Filter by specific broadcast IDs. Subscriber must have interacted with ANY of the specified broadcasts.",
-            "properties": {
-              "ids": {
-                "description": "Array of broadcast IDs. Subscriber must match ANY of these.",
-                "items": {
-                  "type": "integer"
-                },
-                "type": "array"
-              },
-              "type": {
-                "description": "Must be 'broadcasts'",
-                "enum": [
-                  "broadcasts"
-                ],
-                "type": "string"
-              }
-            },
-            "required": [
-              "type",
-              "ids"
-            ],
-            "title": "Broadcasts",
-            "type": "object"
-          },
-          {
-            "additionalProperties": false,
-            "description": "Filter by URL patterns. Only applicable for 'clicks' type. Subscriber must have clicked ANY of the specified URLs.",
-            "properties": {
-              "ids": {
-                "description": "Array of URL IDs. Subscriber must have clicked ANY of these.",
-                "items": {
-                  "type": "integer"
-                },
-                "type": "array"
-              },
-              "matching": {
-                "default": "exact",
-                "description": "URL matching strategy",
-                "enum": [
-                  "exact",
-                  "contains",
-                  "starts_with",
-                  "ends_with"
-                ],
-                "type": "string"
-              },
-              "type": {
-                "description": "Must be 'urls'",
-                "enum": [
-                  "urls"
-                ],
-                "type": "string"
-              },
-              "urls": {
-                "description": "Array of URL patterns. Subscriber must have clicked ANY of these.",
-                "items": {
-                  "type": "string"
-                },
-                "type": "array"
-              }
-            },
-            "required": [
-              "type"
-            ],
-            "title": "URLs (clicks only)",
-            "type": "object"
-          },
-          {
-            "additionalProperties": false,
-            "description": "Match a list of ids. Used by the 'tags' filter to select tag ids.",
-            "properties": {
-              "matching": {
-                "description": "Ids the filter should match against.",
-                "items": {
-                  "type": "integer"
-                },
-                "type": "array"
-              },
-              "type": {
-                "description": "Must be 'ids'",
-                "enum": [
-                  "ids"
-                ],
-                "type": "string"
-              }
-            },
-            "required": [
-              "type",
-              "matching"
-            ],
-            "title": "Tag ids (tags only)",
-            "type": "object"
-          },
-          {
-            "additionalProperties": false,
-            "description": "Attribution sub-condition: matches subscribers whose original signup attribution points at one of the given form / landing-page ids. Ids may refer to either a form or a legacy landing page : the attribution source does not distinguish between the two.",
-            "properties": {
-              "ids": {
-                "description": "Form / landing-page ids the subscriber's attribution should match.",
-                "items": {
-                  "type": "integer"
-                },
-                "type": "array"
-              },
-              "type": {
-                "description": "Must be 'forms'",
-                "enum": [
-                  "forms"
-                ],
-                "type": "string"
-              }
-            },
-            "required": [
-              "type",
-              "ids"
-            ],
-            "title": "Forms (attribution only)",
-            "type": "object"
-          },
-          {
-            "additionalProperties": false,
-            "description": "Attribution sub-condition: matches subscribers whose original signup attribution row matches any combination of the supplied Kit source fields. All fields are optional; supplied fields are ANDed together against the same attribution row, and array fields (`source_ids`, `source_names`, `mechanism_ids`) match any value in the array. Known `source_type` values include `form_subscription` (form / landing-page signup), `api_subscription` (added via the API), and `manual` (added by the creator). Multiple entries in the parent `attribution` filter's `any` array are OR-ed together (consistent with `any` semantics elsewhere in this endpoint), so use separate entries to express \"kit_source A OR kit_source B\".",
-            "properties": {
-              "mechanism": {
-                "description": "Match attribution rows whose `kit_source_mechanism` equals this value.",
-                "type": "string"
-              },
-              "mechanism_ids": {
-                "description": "Match attribution rows whose `kit_source_mechanism_id` is in this list.",
-                "items": {
-                  "type": "integer"
-                },
-                "type": "array"
-              },
-              "source_ids": {
-                "description": "Match attribution rows whose `kit_source_id` is in this list.",
-                "items": {
-                  "type": "integer"
-                },
-                "type": "array"
-              },
-              "source_names": {
-                "description": "Match attribution rows whose `kit_source_name` is in this list.",
-                "items": {
-                  "type": "string"
-                },
-                "type": "array"
-              },
-              "source_type": {
-                "description": "Match attribution rows whose `kit_source_type` equals this value.",
-                "type": "string"
-              },
-              "type": {
-                "description": "Must be 'kit_source'",
-                "enum": [
-                  "kit_source"
-                ],
-                "type": "string"
-              }
-            },
-            "required": [
-              "type"
-            ],
-            "title": "Kit source (attribution only)",
-            "type": "object"
-          }
-        ]
-      },
-      "type": "array"
-    },
-    "before": {
-      "description": "End date (YYYY-MM-DD). For 'subscribed' type, filters by subscriber_created_at. For engagement types, filters by event date. Not applicable for 'tags', 'subscriber_state', 'attribution', or 'custom_field' types.",
-      "format": "date",
-      "type": "string"
-    },
-    "comparison": {
-      "description": "How `value` is matched against the stored custom-field value. `is` is exact equality, `contains` is a case-insensitive substring (blank `value` matches any subscriber that has a value stored for the field), `has_value` matches any non-empty stored value (ignores `value`), `greater_than` / `greater_than_or_equal` / `less_than` / `less_than_or_equal` compare numerically. Only applicable for 'custom_field' type.",
-      "enum": [
-        "is",
-        "contains",
-        "has_value",
-        "greater_than",
-        "greater_than_or_equal",
-        "less_than",
-        "less_than_or_equal"
-      ],
-      "type": "string"
-    },
-    "count_greater_than": {
-      "description": "Minimum count (exclusive). Only applicable for engagement types ('opens', 'clicks', 'sent', 'delivered').",
-      "type": "integer"
-    },
-    "count_greater_than_or_equal": {
-      "description": "Minimum count (inclusive). Only applicable for engagement types ('opens', 'clicks', 'sent', 'delivered').",
-      "type": "integer"
-    },
-    "count_less_than": {
-      "description": "Maximum count (exclusive). Only applicable for engagement types ('opens', 'clicks', 'sent', 'delivered').",
-      "type": "integer"
-    },
-    "count_less_than_or_equal": {
-      "description": "Maximum count (inclusive). Only applicable for engagement types ('opens', 'clicks', 'sent', 'delivered').",
-      "type": "integer"
-    },
-    "latitude": {
-      "description": "Center latitude (decimal degrees). Required for the 'location' type. Combined with `longitude` and `radius` to form a bounding box around the point.",
-      "format": "float",
-      "type": "number"
-    },
-    "longitude": {
-      "description": "Center longitude (decimal degrees). Required for the 'location' type.",
-      "format": "float",
-      "type": "number"
-    },
-    "radius": {
-      "description": "Radius around (`latitude`, `longitude`) in miles. Required for the 'location' type. Subscribers whose primary location falls inside the bounding box pass the filter.",
-      "type": "number"
-    },
-    "states": {
-      "description": "Subscriber lifecycle states. Required for 'subscriber_state' type; ignored for other types. Subscribers matching any of the listed states pass the filter. Strongly recommended to use `['active']` unless you specifically need other states : most subscriber-facing queries elsewhere in the app scope to active subscribers by default.",
-      "items": {
-        "enum": [
-          "active",
-          "inactive",
-          "bounced",
-          "cancelled",
-          "complained"
-        ],
-        "type": "string"
-      },
-      "type": "array"
-    },
-    "subscriber_custom_field_id": {
-      "description": "Id of the custom field whose stored value is being filtered on. Required for 'custom_field' type; ignored for other types.",
-      "type": "integer"
-    },
-    "type": {
-      "description": "Type of filter condition. `attribution` matches subscribers by their *original signup attribution* : supports two sub-conditions: `forms` matches by the form / landing-page id the subscriber signed up through, and `kit_source` matches by any combination of the underlying Kit source fields (source type, source id, source name, mechanism, mechanism id). Attribution is the original signup source; it does not track current subscription state. `custom_field` matches subscribers by the value they have stored for a particular custom field, identified by `subscriber_custom_field_id`. `location` matches subscribers whose primary location falls within a `radius` (miles) of (`latitude`, `longitude`). All three fields are required.",
-      "enum": [
-        "opens",
-        "clicks",
-        "sent",
-        "delivered",
-        "subscribed",
-        "subscriber_state",
-        "tags",
-        "attribution",
-        "custom_field",
-        "location"
-      ],
-      "type": "string"
-    },
-    "value": {
-      "description": "Value to compare against. Used by 'custom_field' type together with `comparison`. For the numeric comparisons (`greater_than`, `greater_than_or_equal`, `less_than`, `less_than_or_equal`) the value is parsed as a number; non-numeric stored values are excluded. Ignored when `comparison` is `has_value`.",
-      "type": "string"
-    }
-  },
-  "required": [
-    "type"
-  ],
-  "type": "object"
-}

removedInput schema / properties / payload / properties / all / type
```
Removed value: -"array"
```
addedInput schema / properties / payload / properties / counting_mode / $ref
```
Added value: +"#/$defs/counting_mode"
```

removedInput schema / properties / payload / properties / counting_mode / description

Removed value: -"Controls how engagement-filter count thresholds are tallied. `raw` (default) counts every event : five opens of the same email = five. `unique_email` counts distinct emails on which the action occurred : five opens of the same email = one. Applies to every engagement filter (opens, clicks, sent, delivered) in the request; ignored for other filter types."

removedInput schema / properties / payload / properties / counting_mode / enum
```
Removed value: -[
-  "raw",
-  "unique_email"
-]
```
removedInput schema / properties / payload / properties / counting_mode / type
```
Removed value: -"string"
```
addedInput schema / properties / payload / properties / include / $ref
```
Added value: +"#/$defs/include"
```

removedInput schema / properties / payload / properties / include / description

Removed value: -"Optional. Array of `{ type, ...config }` objects naming additional fields to embed on each subscriber row. Valid types: `attribution`, `tags`, `location`, `canceled_at`, `stats`, `custom_fields`. The `stats` type accepts an optional `range: { start, end }` (YYYY-MM-DD dates, defaulting to the last 90 days). The `custom_fields` type adds a `fields` object with all account custom field values (null for fields the subscriber has not set)."

removedInput schema / properties / payload / properties / include / items

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "range": {
-      "additionalProperties": false,
-      "description": "Only used by the `stats` type. Date window for the engagement stats. Defaults to the last 90 days; clamped to the account's data-retention window.",
-      "properties": {
-        "end": {
-          "format": "date",
-          "type": "string"
-        },
-        "start": {
-          "format": "date",
-          "type": "string"
-        }
-      },
-      "type": "object"
-    },
-    "type": {
-      "enum": [
-        "attribution",
-        "tags",
-        "location",
-        "canceled_at",
-        "stats",
-        "custom_fields"
-      ],
-      "type": "string"
-    }
-  },
-  "required": [
-    "type"
-  ],
-  "type": "object"
-}

removedInput schema / properties / payload / properties / include / type
```
Removed value: -"array"
```
addedInput schema / properties / payload / properties / sort_field / $ref
```
Added value: +"#/$defs/sort_field"
```
removedInput schema / properties / payload / properties / sort_field / default
```
Removed value: -"created_at"
```

removedInput schema / properties / payload / properties / sort_field / description

Removed value: -"Field to order results by. Base columns (`id`, `first_name`, `email_address`, `created_at`) order by that subscriber attribute. `engagement__ ` orders by an engagement stat over the trailing 90 days: counts (`sent`, `opens`, `clicks`) and rates (`open_rate`, `click_rate`); subscribers with no sends order as 0. `location__distance` orders by great-circle distance and requires a `location` filter in the same request : its `latitude`/`longitude` supply the origin, and subscribers without a primary location are excluded. Distance defaults to nearest-first (`sort_order` defaults to `asc` for this field); pass `sort_order=desc` for farthest-first."

removedInput schema / properties / payload / properties / sort_field / enum

Removed value: -[
-  "id",
-  "first_name",
-  "email_address",
-  "created_at",
-  "engagement__sent",
-  "engagement__opens",
-  "engagement__clicks",
-  "engagement__open_rate",
-  "engagement__click_rate",
-  "location__distance"
-]

removedInput schema / properties / payload / properties / sort_field / type
```
Removed value: -"string"
```
addedInput schema / properties / sort_field / $ref
```
Added value: +"#/$defs/sort_field"
```
removedInput schema / properties / sort_field / default
```
Removed value: -"created_at"
```

removedInput schema / properties / sort_field / description

Removed value: -"Field to order results by. Base columns (`id`, `first_name`, `email_address`, `created_at`) order by that subscriber attribute. `engagement__ ` orders by an engagement stat over the trailing 90 days: counts (`sent`, `opens`, `clicks`) and rates (`open_rate`, `click_rate`); subscribers with no sends order as 0. `location__distance` orders by great-circle distance and requires a `location` filter in the same request : its `latitude`/`longitude` supply the origin, and subscribers without a primary location are excluded. Distance defaults to nearest-first (`sort_order` defaults to `asc` for this field); pass `sort_order=desc` for farthest-first."

removedInput schema / properties / sort_field / enum

Removed value: -[
-  "id",
-  "first_name",
-  "email_address",
-  "created_at",
-  "engagement__sent",
-  "engagement__opens",
-  "engagement__clicks",
-  "engagement__open_rate",
-  "engagement__click_rate",
-  "location__distance"
-]

removedInput schema / properties / sort_field / type
```
Removed value: -"string"
```

Changedpin_subscriber_location12 fields changed

addedInput schema / $defs

Added value: +{
+  "location": {
+    "additionalProperties": false,
+    "properties": {
+      "city": {
+        "type": "string"
+      },
+      "country_code": {
+        "type": "string"
+      },
+      "latitude": {
+        "format": "float",
+        "type": "number"
+      },
+      "longitude": {
+        "format": "float",
+        "type": "number"
+      },
+      "state_province": {
+        "type": "string"
+      },
+      "timezone": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "city",
+      "state_province",
+      "country_code",
+      "latitude",
+      "longitude",
+      "timezone"
+    ],
+    "type": "object"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / location / $ref
```
Added value: +"#/$defs/location"
```
removedInput schema / properties / location / additionalProperties
```
Removed value: -false
```

removedInput schema / properties / location / properties

Removed value: -{
-  "city": {
-    "type": "string"
-  },
-  "country_code": {
-    "type": "string"
-  },
-  "latitude": {
-    "format": "float",
-    "type": "number"
-  },
-  "longitude": {
-    "format": "float",
-    "type": "number"
-  },
-  "state_province": {
-    "type": "string"
-  },
-  "timezone": {
-    "type": "string"
-  }
-}

removedInput schema / properties / location / required

Removed value: -[
-  "city",
-  "state_province",
-  "country_code",
-  "latitude",
-  "longitude",
-  "timezone"
-]

removedInput schema / properties / location / type
```
Removed value: -"object"
```
addedInput schema / properties / payload / properties / location / $ref
```
Added value: +"#/$defs/location"
```
removedInput schema / properties / payload / properties / location / additionalProperties
```
Removed value: -false
```

removedInput schema / properties / payload / properties / location / properties

Removed value: -{
-  "city": {
-    "type": "string"
-  },
-  "country_code": {
-    "type": "string"
-  },
-  "latitude": {
-    "format": "float",
-    "type": "number"
-  },
-  "longitude": {
-    "format": "float",
-    "type": "number"
-  },
-  "state_province": {
-    "type": "string"
-  },
-  "timezone": {
-    "type": "string"
-  }
-}

removedInput schema / properties / payload / properties / location / required

Removed value: -[
-  "city",
-  "state_province",
-  "country_code",
-  "latitude",
-  "longitude",
-  "timezone"
-]

removedInput schema / properties / payload / properties / location / type
```
Removed value: -"object"
```

Changedrevoke_previous_webhook_secret1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

Changedrotate_webhook_secret8 fields changed

addedInput schema / $defs

Added value: +{
+  "force": {
+    "description": "Rotating again while a previous rotation's overlap window is still open returns `409` (see the responses below). Pass `true` to rotate anyway, immediately expiring the older secret.",
+    "type": "boolean"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / force / $ref
```
Added value: +"#/$defs/force"
```

removedInput schema / properties / force / description

Removed value: -"Rotating again while a previous rotation's overlap window is still open returns `409` (see the responses below). Pass `true` to rotate anyway, immediately expiring the older secret."

removedInput schema / properties / force / type
```
Removed value: -"boolean"
```
addedInput schema / properties / payload / properties / force / $ref
```
Added value: +"#/$defs/force"
```

removedInput schema / properties / payload / properties / force / description

Removed value: -"Rotating again while a previous rotation's overlap window is still open returns `409` (see the responses below). Pass `true` to rotate anyway, immediately expiring the older secret."

removedInput schema / properties / payload / properties / force / type
```
Removed value: -"boolean"
```

Changedtag_subscriber1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

Changedtag_subscriber_by_id1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

Changedunsubscribe1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

Changeduntag_subscriber1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

Changeduntag_subscriber_by_email1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

Changedupdate_broadcast16 fields changed

addedInput schema / $defs

Added value: +{
+  "content": {
+    "description": "The HTML content of the email. On a `Classic` template this is the body, and the template adds the design around it when the broadcast is sent. On a `Starting point` template the design lives in the body, so this is the complete email: keep the wrappers, images, inline styles and Liquid tags, including `{{ unsubscribe_url }}` and `{{ address }}`. Without an unsubscribe link the broadcast can't be sent. A read returns the string that was written, so `GET`, `PUT`, `GET` round-trips, apart from Kit's own \"Built with Kit\" badge, which a `Starting point` write takes out of the body and re-applies when the email renders. A broadcast built in Kit's editor reads back as Kit's rendered HTML instead, and writing that back replaces its individually-editable blocks with one HTML block. Sending `content` in the same request as a `Starting point` `email_template_id` also needs `allow_starting_point: true`.",
+    "type": "string"
+  },
+  "subscriber_filter": {
+    "description": "Filters your subscribers. At this time, we only support using only one filter group type via the API (e.g. `all`, `any`, or `none` but no combinations). If nothing is provided, will default to all of your subscribers.",
+    "items": {
+      "additionalProperties": false,
+      "minProperties": 1,
+      "properties": {
+        "all": {
+          "description": "Filters your subscribers using a logical AND of all provided segment and tag ids, i.e. a subscriber would have to be part of all segments and tags provided",
+          "items": {
+            "additionalProperties": false,
+            "properties": {
+              "ids": {
+                "items": {
+                  "type": "integer"
+                },
+                "type": "array"
+              },
+              "type": {
+                "description": "`segment` or `tag`",
+                "type": "string"
+              }
+            },
+            "required": [
+              "type",
+              "ids"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "any": {
+          "description": "Filters your subscribers using a logical OR of all provided segment and tag ids, i.e. a subscriber would have to be part of at least one of the segments or tags provided",
+          "items": {
+            "additionalProperties": false,
+            "properties": {
+              "ids": {
+                "items": {
+                  "type": "integer"
+                },
+                "type": "array"
+              },
+              "type": {
+                "description": "`segment` or `tag`",
+                "type": "string"
+              }
+            },
+            "required": [
+              "type",
+              "ids"
+            ],
+            "type": "object"
+          },
+          "type": [
+            "array",
+            "null"
+          ]
+        },
+        "none": {
+          "description": "Filters your subscribers using a logical NOT of all provided segment and tag ids, i.e. a subscriber would have to be in none of the segments or tags provided",
+          "items": {
+            "additionalProperties": false,
+            "properties": {
+              "ids": {
+                "items": {
+                  "type": "integer"
+                },
+                "type": "array"
+              },
+              "type": {
+                "description": "`segment` or `tag`",
+                "type": "string"
+              }
+            },
+            "required": [
+              "type",
+              "ids"
+            ],
+            "type": "object"
+          },
+          "type": [
+            "array",
+            "null"
+          ]
+        }
+      },
+      "required": [
+        "all",
+        "any",
+        "none"
+      ],
+      "type": "object"
+    },
+    "type": "array"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / content / $ref
```
Added value: +"#/$defs/content"
```

removedInput schema / properties / content / description

Removed value: -"The HTML content of the email. On a `Classic` template this is the body, and the template adds the design around it when the broadcast is sent. On a `Starting point` template the design lives in the body, so this is the complete email: keep the wrappers, images, inline styles and Liquid tags, including `{{ unsubscribe_url }}` and `{{ address }}`. Without an unsubscribe link the broadcast can't be sent. A read returns the string that was written, so `GET`, `PUT`, `GET` round-trips, apart from Kit's own \"Built with Kit\" badge, which a `Starting point` write takes out of the body and re-applies when the email renders. A broadcast built in Kit's editor reads back as Kit's rendered HTML instead, and writing that back replaces its individually-editable blocks with one HTML block. Sending `content` in the same request as a `Starting point` `email_template_id` also needs `allow_starting_point: true`."

removedInput schema / properties / content / type
```
Removed value: -"string"
```
addedInput schema / properties / payload / properties / content / $ref
```
Added value: +"#/$defs/content"
```

removedInput schema / properties / payload / properties / content / description

Removed value: -"The HTML content of the email. On a `Classic` template this is the body, and the template adds the design around it when the broadcast is sent. On a `Starting point` template the design lives in the body, so this is the complete email: keep the wrappers, images, inline styles and Liquid tags, including `{{ unsubscribe_url }}` and `{{ address }}`. Without an unsubscribe link the broadcast can't be sent. A read returns the string that was written, so `GET`, `PUT`, `GET` round-trips, apart from Kit's own \"Built with Kit\" badge, which a `Starting point` write takes out of the body and re-applies when the email renders. A broadcast built in Kit's editor reads back as Kit's rendered HTML instead, and writing that back replaces its individually-editable blocks with one HTML block. Sending `content` in the same request as a `Starting point` `email_template_id` also needs `allow_starting_point: true`."

removedInput schema / properties / payload / properties / content / type
```
Removed value: -"string"
```
addedInput schema / properties / payload / properties / subscriber_filter / $ref
```
Added value: +"#/$defs/subscriber_filter"
```

removedInput schema / properties / payload / properties / subscriber_filter / description

Removed value: -"Filters your subscribers. At this time, we only support using only one filter group type via the API (e.g. `all`, `any`, or `none` but no combinations). If nothing is provided, will default to all of your subscribers."

removedInput schema / properties / payload / properties / subscriber_filter / items

Removed value: -{
-  "additionalProperties": false,
-  "minProperties": 1,
-  "properties": {
-    "all": {
-      "description": "Filters your subscribers using a logical AND of all provided segment and tag ids, i.e. a subscriber would have to be part of all segments and tags provided",
-      "items": {
-        "additionalProperties": false,
-        "properties": {
-          "ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          },
-          "type": {
-            "description": "`segment` or `tag`",
-            "type": "string"
-          }
-        },
-        "required": [
-          "type",
-          "ids"
-        ],
-        "type": "object"
-      },
-      "type": "array"
-    },
-    "any": {
-      "description": "Filters your subscribers using a logical OR of all provided segment and tag ids, i.e. a subscriber would have to be part of at least one of the segments or tags provided",
-      "items": {
-        "additionalProperties": false,
-        "properties": {
-          "ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          },
-          "type": {
-            "description": "`segment` or `tag`",
-            "type": "string"
-          }
-        },
-        "required": [
-          "type",
-          "ids"
-        ],
-        "type": "object"
-      },
-      "type": [
-        "array",
-        "null"
-      ]
-    },
-    "none": {
-      "description": "Filters your subscribers using a logical NOT of all provided segment and tag ids, i.e. a subscriber would have to be in none of the segments or tags provided",
-      "items": {
-        "additionalProperties": false,
-        "properties": {
-          "ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          },
-          "type": {
-            "description": "`segment` or `tag`",
-            "type": "string"
-          }
-        },
-        "required": [
-          "type",
-          "ids"
-        ],
-        "type": "object"
-      },
-      "type": [
-        "array",
-        "null"
-      ]
-    }
-  },
-  "required": [
-    "all",
-    "any",
-    "none"
-  ],
-  "type": "object"
-}

removedInput schema / properties / payload / properties / subscriber_filter / type
```
Removed value: -"array"
```
addedInput schema / properties / subscriber_filter / $ref
```
Added value: +"#/$defs/subscriber_filter"
```

removedInput schema / properties / subscriber_filter / description

Removed value: -"Filters your subscribers. At this time, we only support using only one filter group type via the API (e.g. `all`, `any`, or `none` but no combinations). If nothing is provided, will default to all of your subscribers."

removedInput schema / properties / subscriber_filter / items

Removed value: -{
-  "additionalProperties": false,
-  "minProperties": 1,
-  "properties": {
-    "all": {
-      "description": "Filters your subscribers using a logical AND of all provided segment and tag ids, i.e. a subscriber would have to be part of all segments and tags provided",
-      "items": {
-        "additionalProperties": false,
-        "properties": {
-          "ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          },
-          "type": {
-            "description": "`segment` or `tag`",
-            "type": "string"
-          }
-        },
-        "required": [
-          "type",
-          "ids"
-        ],
-        "type": "object"
-      },
-      "type": "array"
-    },
-    "any": {
-      "description": "Filters your subscribers using a logical OR of all provided segment and tag ids, i.e. a subscriber would have to be part of at least one of the segments or tags provided",
-      "items": {
-        "additionalProperties": false,
-        "properties": {
-          "ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          },
-          "type": {
-            "description": "`segment` or `tag`",
-            "type": "string"
-          }
-        },
-        "required": [
-          "type",
-          "ids"
-        ],
-        "type": "object"
-      },
-      "type": [
-        "array",
-        "null"
-      ]
-    },
-    "none": {
-      "description": "Filters your subscribers using a logical NOT of all provided segment and tag ids, i.e. a subscriber would have to be in none of the segments or tags provided",
-      "items": {
-        "additionalProperties": false,
-        "properties": {
-          "ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          },
-          "type": {
-            "description": "`segment` or `tag`",
-            "type": "string"
-          }
-        },
-        "required": [
-          "type",
-          "ids"
-        ],
-        "type": "object"
-      },
-      "type": [
-        "array",
-        "null"
-      ]
-    }
-  },
-  "required": [
-    "all",
-    "any",
-    "none"
-  ],
-  "type": "object"
-}

removedInput schema / properties / subscriber_filter / type
```
Removed value: -"array"
```

Changedupdate_colors1 field changed

removedInput schema / properties / confirm

Removed value: -{
-  "description": "Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user.",
-  "type": "boolean"
-}

Changedupdate_custom_field1 field changed

removedInput schema / properties / confirm

Removed value: -{
-  "description": "Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user.",
-  "type": "boolean"
-}

Changedupdate_sequence10 fields changed

addedInput schema / $defs

Added value: +{
+  "exclude_subscriber_sources": {
+    "description": "The subscriber sources to exclude from the sequence.",
+    "items": {
+      "additionalProperties": false,
+      "properties": {
+        "ids": {
+          "items": {
+            "description": "The ids of the subscriber sources to exclude.",
+            "type": "integer"
+          },
+          "type": "array"
+        },
+        "type": {
+          "description": "The type of subscriber source to exclude. Must be one of: `tag`, `sequence`, `form`, `segment`.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "type",
+        "ids"
+      ],
+      "type": "object"
+    },
+    "type": "array"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / exclude_subscriber_sources / $ref
```
Added value: +"#/$defs/exclude_subscriber_sources"
```
removedInput schema / properties / exclude_subscriber_sources / description
```
Removed value: -"The subscriber sources to exclude from the sequence."
```

removedInput schema / properties / exclude_subscriber_sources / items

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "ids": {
-      "items": {
-        "description": "The ids of the subscriber sources to exclude.",
-        "type": "integer"
-      },
-      "type": "array"
-    },
-    "type": {
-      "description": "The type of subscriber source to exclude. Must be one of: `tag`, `sequence`, `form`, `segment`.",
-      "type": "string"
-    }
-  },
-  "required": [
-    "type",
-    "ids"
-  ],
-  "type": "object"
-}

removedInput schema / properties / exclude_subscriber_sources / type
```
Removed value: -"array"
```
addedInput schema / properties / payload / properties / exclude_subscriber_sources / $ref
```
Added value: +"#/$defs/exclude_subscriber_sources"
```
removedInput schema / properties / payload / properties / exclude_subscriber_sources / description
```
Removed value: -"The subscriber sources to exclude from the sequence."
```

removedInput schema / properties / payload / properties / exclude_subscriber_sources / items

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "ids": {
-      "items": {
-        "description": "The ids of the subscriber sources to exclude.",
-        "type": "integer"
-      },
-      "type": "array"
-    },
-    "type": {
-      "description": "The type of subscriber source to exclude. Must be one of: `tag`, `sequence`, `form`, `segment`.",
-      "type": "string"
-    }
-  },
-  "required": [
-    "type",
-    "ids"
-  ],
-  "type": "object"
-}

removedInput schema / properties / payload / properties / exclude_subscriber_sources / type
```
Removed value: -"array"
```

Changedupdate_sequence_email10 fields changed

addedInput schema / $defs

Added value: +{
+  "send_days": {
+    "description": "Days of the week this email may be sent. Pass a subset to restrict delivery, or `null` to reset to all days (inherits the sequence schedule)",
+    "items": {
+      "type": "string"
+    },
+    "type": [
+      "array",
+      "null"
+    ]
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / payload / properties / send_days / $ref
```
Added value: +"#/$defs/send_days"
```

removedInput schema / properties / payload / properties / send_days / description

Removed value: -"Days of the week this email may be sent. Pass a subset to restrict delivery, or `null` to reset to all days (inherits the sequence schedule)"

removedInput schema / properties / payload / properties / send_days / items
```
Removed value: -{
-  "type": "string"
-}
```
removedInput schema / properties / payload / properties / send_days / type
```
Removed value: -[
-  "array",
-  "null"
-]
```
addedInput schema / properties / send_days / $ref
```
Added value: +"#/$defs/send_days"
```

removedInput schema / properties / send_days / description

Removed value: -"Days of the week this email may be sent. Pass a subset to restrict delivery, or `null` to reset to all days (inherits the sequence schedule)"

removedInput schema / properties / send_days / items
```
Removed value: -{
-  "type": "string"
-}
```
removedInput schema / properties / send_days / type
```
Removed value: -[
-  "array",
-  "null"
-]
```

Changedupdate_snippet1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

Changedupdate_subscriber10 fields changed

addedInput schema / $defs

Added value: +{
+  "fields": {
+    "additionalProperties": {
+      "type": "string"
+    },
+    "description": "Custom field values keyed by the custom field's `key` (e.g. `last_name`, not `Last Name`). Unknown keys are ignored and reported in the response `warnings` array.",
+    "type": "object"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / fields / $ref
```
Added value: +"#/$defs/fields"
```
removedInput schema / properties / fields / additionalProperties
```
Removed value: -{
-  "type": "string"
-}
```

removedInput schema / properties / fields / description

Removed value: -"Custom field values keyed by the custom field's `key` (e.g. `last_name`, not `Last Name`). Unknown keys are ignored and reported in the response `warnings` array."

removedInput schema / properties / fields / type
```
Removed value: -"object"
```
addedInput schema / properties / payload / properties / fields / $ref
```
Added value: +"#/$defs/fields"
```
removedInput schema / properties / payload / properties / fields / additionalProperties
```
Removed value: -{
-  "type": "string"
-}
```

removedInput schema / properties / payload / properties / fields / description

Removed value: -"Custom field values keyed by the custom field's `key` (e.g. `last_name`, not `Last Name`). Unknown keys are ignored and reported in the response `warnings` array."

removedInput schema / properties / payload / properties / fields / type
```
Removed value: -"object"
```

Changedupdate_subscriber_location12 fields changed

addedInput schema / $defs

Added value: +{
+  "location": {
+    "additionalProperties": false,
+    "properties": {
+      "city": {
+        "type": "string"
+      },
+      "country_code": {
+        "type": "string"
+      },
+      "latitude": {
+        "format": "float",
+        "type": "number"
+      },
+      "longitude": {
+        "format": "float",
+        "type": "number"
+      },
+      "state_province": {
+        "type": "string"
+      },
+      "timezone": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "city",
+      "state_province",
+      "country_code",
+      "latitude",
+      "longitude",
+      "timezone"
+    ],
+    "type": "object"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / location / $ref
```
Added value: +"#/$defs/location"
```
removedInput schema / properties / location / additionalProperties
```
Removed value: -false
```

removedInput schema / properties / location / properties

Removed value: -{
-  "city": {
-    "type": "string"
-  },
-  "country_code": {
-    "type": "string"
-  },
-  "latitude": {
-    "format": "float",
-    "type": "number"
-  },
-  "longitude": {
-    "format": "float",
-    "type": "number"
-  },
-  "state_province": {
-    "type": "string"
-  },
-  "timezone": {
-    "type": "string"
-  }
-}

removedInput schema / properties / location / required

Removed value: -[
-  "city",
-  "state_province",
-  "country_code",
-  "latitude",
-  "longitude",
-  "timezone"
-]

removedInput schema / properties / location / type
```
Removed value: -"object"
```
addedInput schema / properties / payload / properties / location / $ref
```
Added value: +"#/$defs/location"
```
removedInput schema / properties / payload / properties / location / additionalProperties
```
Removed value: -false
```

removedInput schema / properties / payload / properties / location / properties

Removed value: -{
-  "city": {
-    "type": "string"
-  },
-  "country_code": {
-    "type": "string"
-  },
-  "latitude": {
-    "format": "float",
-    "type": "number"
-  },
-  "longitude": {
-    "format": "float",
-    "type": "number"
-  },
-  "state_province": {
-    "type": "string"
-  },
-  "timezone": {
-    "type": "string"
-  }
-}

removedInput schema / properties / payload / properties / location / required

Removed value: -[
-  "city",
-  "state_province",
-  "country_code",
-  "latitude",
-  "longitude",
-  "timezone"
-]

removedInput schema / properties / payload / properties / location / type
```
Removed value: -"object"
```

Changedupdate_tag_name1 field changed

removedInput schema / properties / confirm

Removed value: -{
-  "description": "Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user.",
-  "type": "boolean"
-}

Changedupdate_webhook_endpoint10 fields changed

addedInput schema / $defs

Added value: +{
+  "events": {
+    "description": "Event types this endpoint subscribes to (e.g. `subscriber.created`). On update, the list supplied here replaces the endpoint's full subscription list.",
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / events / $ref
```
Added value: +"#/$defs/events"
```

removedInput schema / properties / events / description

Removed value: -"Event types this endpoint subscribes to (e.g. `subscriber.created`). On update, the list supplied here replaces the endpoint's full subscription list."

removedInput schema / properties / events / items
```
Removed value: -{
-  "type": "string"
-}
```
removedInput schema / properties / events / type
```
Removed value: -"array"
```
addedInput schema / properties / payload / properties / events / $ref
```
Added value: +"#/$defs/events"
```

removedInput schema / properties / payload / properties / events / description

Removed value: -"Event types this endpoint subscribes to (e.g. `subscriber.created`). On update, the list supplied here replaces the endpoint's full subscription list."

removedInput schema / properties / payload / properties / events / items
```
Removed value: -{
-  "type": "string"
-}
```
removedInput schema / properties / payload / properties / events / type
```
Removed value: -"array"
```

85 tool updatesv2.0.1Oct 2, 2026
- First observedadd_subscriber_to_form
- First observedadd_subscriber_to_form_by_id
- First observedadd_subscriber_to_sequence
- First observedadd_subscriber_to_sequence_by_id
- First observedbulk_add_subscribers_to_forms
- First observedbulk_create_custom_fields
- First observedbulk_create_subscribers
- First observedbulk_create_tags
- First observedbulk_delete_tags
- First observedbulk_remove_tags_from_subscribers
- First observedbulk_tag_subscribers
- First observedbulk_update_subscriber_custom_field_values
- First observedcreate_broadcast
- First observedcreate_custom_field
- First observedcreate_purchase
- First observedcreate_sequence
- First observedcreate_sequence_email
- First observedcreate_snippet
- First observedcreate_subscriber
- First observedcreate_tag
- First observedcreate_webhook
- First observedcreate_webhook_endpoint
- First observeddelete_broadcast
- First observeddelete_custom_field
- First observeddelete_sequence
- First observeddelete_sequence_email
- First observeddelete_subscriber_location
- First observeddelete_webhook
- First observeddelete_webhook_endpoint
- First observedfilter_subscribers
- First observedget_account
- First observedget_broadcast
- First observedget_broadcast_clicks
- First observedget_broadcast_stats
- First observedget_creator_profile
- First observedget_email_stats
- First observedget_growth_stats
- First observedget_post
- First observedget_purchase
- First observedget_sequence
- First observedget_sequence_email
- First observedget_snippet
- First observedget_subscriber
- First observedget_subscriber_stats
- First observedget_webhook_endpoint
- First observedlist_accounts
- First observedlist_broadcast_stats
- First observedlist_broadcasts
- First observedlist_colors
- First observedlist_custom_fields
- First observedlist_email_templates
- First observedlist_forms
- First observedlist_posts
- First observedlist_purchases
- First observedlist_segments
- First observedlist_sequence_emails
- First observedlist_sequences
- First observedlist_snippets
- First observedlist_subscriber_tags
- First observedlist_subscribers
- First observedlist_subscribers_for_form
- First observedlist_subscribers_for_sequence
- First observedlist_subscribers_for_tag
- First observedlist_tags
- First observedlist_webhook_endpoints
- First observedlist_webhooks
- First observedpin_subscriber_location
- First observedrevoke_previous_webhook_secret
- First observedrotate_webhook_secret
- First observedsearch_subscribers
- First observedtag_subscriber
- First observedtag_subscriber_by_id
- First observedunsubscribe
- First observeduntag_subscriber
- First observeduntag_subscriber_by_email
- First observedupdate_broadcast
- First observedupdate_colors
- First observedupdate_custom_field
- First observedupdate_sequence
- First observedupdate_sequence_email
- First observedupdate_snippet
- First observedupdate_subscriber
- First observedupdate_subscriber_location
- First observedupdate_tag_name
- First observedupdate_webhook_endpoint

Deploy Server

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

TDQS

B3/5.0

Scored 2026-10-07 00:20 across 85 tools

Disambiguation4/5

Most tools target a distinct resource+action, but create/update/delete_webhook and the *_webhook_endpoint variants are near-duplicates, and list_subscribers/filter_subscribers/search_subscribers overlap. The by_id vs by_email variants are distinguishable via descriptions, keeping ambiguity limited.

Naming Consistency5/5

All tools use snake_case with a consistent verb_noun pattern (create_broadcast, list_subscribers, update_tag_name), and the bulk_ prefix is applied uniformly. Minor verb-only exceptions like unsubscribe and rotate_webhook_secret do not break the overall pattern.

Tool Count2/5

85 tools is far beyond the 3-15 range for well-scoped servers and imposes heavy selection load on an agent. While many map to real Kit API endpoints, the count is excessive for reliable tool choice.

Completeness4/5

Coverage spans subscribers, tags, forms, sequences, broadcasts, custom fields, webhooks, purchases, snippets, and stats with mostly full CRUD. Minor gaps exist (e.g., no delete_snippet, read-only posts/email templates/segments), but core workflows are supported.

Maintenance

ActivityNo data

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Mailchimp MCP by usefulapi A
io.usefulapi
Read audiences, members, campaigns and reports; add, update, tag and archive subscribers.
Email Marketing
181
Buttondown MCP by usefulapi A
io.usefulapi
Read Buttondown subscribers, emails, analytics and automations; add subscribers; write email drafts.
Email Marketing
251
MailerLite MCP by usefulapi A
io.usefulapi
Read subscribers, groups, campaigns, fields, segments, automations, webhooks; safe additive writes.
Email Marketing CRM
132
beehiivOAuth
com.beehiiv
Manage beehiiv newsletters, posts, podcasts, community, subscribers, and analytics.
Content Management Systems Email Marketing
11

Related MCP Servers

keila-mcp
Marketing Communication Customer Data Platforms
gwbischof
F
license
A
quality
D
maintenance
An MCP server for the Keila newsletter API that enables management of contacts, campaigns, segments, and senders. It allows users to create, schedule, and send newsletters directly through natural language interactions.
Updated 7 months ago (2026-03-11 00:43 UTC)
17
-
kit-mcp
Marketing App Automation Customer Data Platforms
dancumberland
A
license
A
quality
D
maintenance
An agent-optimized MCP server for Kit.com (formerly ConvertKit) that enables full management of email marketing campaigns, subscribers, and broadcasts. It provides 13 composite tools covering the entire Kit V4 API with built-in rate limiting and formatted responses for efficient AI interaction.
Updated 7 months ago (2026-03-17 19:12 UTC)
13
16 npm
2
MIT
Campaign Monitor MCP
Email Marketing
pauliowest
F
license
B
quality
D
maintenance
Enables management of email campaigns, subscribers, lists, segments, journeys, templates, transactional email, and client/account settings through the Campaign Monitor API via natural language.
Updated 5 months ago (2026-05-20 13:26 UTC)
100
1
-
Mailchimp MCP Server
Email Marketing
mattcoatsworth
F
license
Not graded
quality
D
maintenance
Enables interaction with the Mailchimp API for managing campaigns, lists, templates, reports, and automations through natural language.
Updated 2 years ago (2025-04-04 16:02 UTC)
3
-

Kit MCP Server & CLI

Two ways to use it

Command line

MCP server, for your AI app

Which one

Features

Contents

1. What you can ask it

What was actually checked

2. Quick install

3. Set up Kit access

Personal v4 API key

OAuth for full endpoint eligibility

4. Connect your client

Let an agent guide setup

5. Check it works

6. Output, flags and exit codes

Null is meaningful

Exit codes

7. MCP or CLI and token cost

Measuring the context and task cost

8. Every tool and argument

Shared input rules

Complete arguments

get_account

list_colors

update_colors

get_creator_profile

get_email_stats

get_growth_stats

list_broadcasts

create_broadcast

list_broadcast_stats

get_broadcast_clicks

get_broadcast_stats

delete_broadcast

get_broadcast

update_broadcast

bulk_create_custom_fields

bulk_update_subscriber_custom_field_values

list_custom_fields

create_custom_field

delete_custom_field

update_custom_field

list_email_templates

bulk_add_subscribers_to_forms

list_forms

list_subscribers_for_form

add_subscriber_to_form

add_subscriber_to_form_by_id

list_posts

get_post

list_purchases

create_purchase

get_purchase

list_segments

list_sequence_emails

create_sequence_email

delete_sequence_email

get_sequence_email

update_sequence_email

list_sequences

create_sequence

delete_sequence

get_sequence

update_sequence

list_subscribers_for_sequence

add_subscriber_to_sequence

add_subscriber_to_sequence_by_id

list_snippets

create_snippet

get_snippet

update_snippet

bulk_create_subscribers

list_subscribers

create_subscriber

filter_subscribers

get_subscriber

update_subscriber

unsubscribe