Sequenzy MCP Server
OfficialSequenzy MCP Server is an official MCP server for Sequenzy, an AI-powered email marketing platform, exposing 120+ tools to manage virtually all aspects of email marketing operations.
Account & Company Management: Get account info, switch/create companies, configure settings, generate API keys, manage sender websites, and retrieve integration guides.
Subscriber Management: Add, update, remove, and search subscribers by query, tags, list, segment, or status; fetch full profiles including tags, lists, enrollments, and activity.
Tags, Lists & Segments: Create, update, delete tags and subscriber lists; bulk-add/remove up to 500 subscribers; build dynamic segments with complex nested AND/OR filter logic (attributes, events, Stripe/commerce products, engagement metrics); preview segment counts.
Products & Digital Delivery: List, upsert, and delete products; attach/remove digital delivery files; sync Stripe product catalogs.
Audience Syncs (Meta Ads): List Meta ad accounts, create/update/delete audience syncs from segments to Meta custom audiences, and trigger immediate syncs.
Email Templates: Create, read, update, and delete reusable HTML or block-based email templates.
A/B Tests: Create campaign/sequence A/B tests, manage variants, view stats, and restart completed tests.
Campaigns: Create, update, schedule, send test emails, pause, resume, cancel, duplicate, delete, and resend to non-openers.
Landing Pages: Create, update, publish/unpublish, delete landing pages; connect and verify custom domains.
Sequences (Automations): Create AI-generated or explicit multi-step sequences; support diverse triggers; enroll/cancel subscribers (up to 500 at a time); insert steps, add if/else branches, configure discount actions, and enable/disable sequences.
Transactional Email: Create, update, and manage transactional templates; send single emails with variable personalization.
Analytics: Overview stats (7d/30d/90d), campaign/sequence performance with revenue attribution, raw event logs, subscriber activity, and deliverability health metrics.
Team & Inbox: Invite/list/remove team members; manage inbox conversations (read, reply, update status, mark as read).
Webhooks: Create, update, delete, test, list deliveries, and replay outbound webhook endpoints.
AI Generation: Generate email content, full multi-step sequences, and A/B subject line variants from prompts.
Allows syncing segments to Meta custom audiences for retargeting on Facebook.
Allows syncing segments to Meta custom audiences for retargeting on Instagram.
Allows syncing segments to Meta custom audiences for retargeting on Facebook and Instagram.
Allows listing products synced from Shopify.
Allows syncing Stripe product catalogs and managing products.
Allows listing products synced from WooCommerce.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Sequenzy MCP ServerCreate a 3-email welcome sequence for new signups"
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.
Sequenzy MCP Server
Official MCP server for Sequenzy, the AI-powered email marketing platform.
Connect Sequenzy to Claude Desktop, Claude Code, Codex, Cursor, Windsurf, VS Code Copilot, OpenClaw, and other MCP clients so your AI assistant can manage email operations with structured tools instead of hand-written API calls.
What You Can Do
Manage subscribers, tags, lists, and dynamic segments, including bulk tag reconciliation and synthetic event testing.
Sync segments to Meta custom audiences for Facebook and Instagram retargeting.
Manage products and attach digital delivery files for purchase automations.
Upload hosted email images with alt text and reusable responsive crop settings.
Draft, update, schedule, and inspect campaigns, including resolved audience previews, persisted conversion goals, and From, Reply-To, CC, and BCC identities.
Render campaigns, sequence steps, and templates to their exact email-safe HTML without sending.
Add one-click Poll and NPS survey blocks to emails and inspect campaign response summaries.
Create and edit email sequences, including multi-list/tag triggers, entry-audience and property-filtered stop conditions, sending identity overrides, existing graph restructuring, and direct step test sends to internal reviewers.
Cancel, pause, resume, duplicate, or delete campaigns and enroll contacts into sequences.
Manage transactional email templates and send transactional emails to shared To, Cc, and Bcc recipient lists.
Supply localized template variants or queue AI translation for enabled locales.
Create, preview, edit, publish, unpublish, and delete landing pages.
Create list-scoped saved signup forms with responsive stack, row, grid, and single-image overlay block groups (including foreground gap controls), then return client-safe static-site embeds.
Create, target, publish, duplicate, and deploy saved signup popups with the same recursive block layouts.
Connect and verify custom domains for published landing pages.
Manage team invitations, inbox conversations, and outbound webhook endpoints.
Generate email copy, subject lines, and multi-step sequences.
Inspect analytics, subscriber activity, deliverability health, company-level sending pauses, integrations, published event payload schemas, sending identities, tracking settings, and dashboard URLs.
Inspect whether "Sent with Sequenzy" is visible for a workspace, why the owner subscription does or does not remove it, and open the canonical subscription page for an upgrade or renewal. Entitlement changes apply to future sends from existing live sequences without editing their blocks.
Diagnose why sending is paused and restore eligible hard-bounce pauses after confirming list cleanup.
Inspect exact-recipient bounce, complaint, and email-hygiene suppression, and clean up eligible stale bounces without exposing the shared SES suppression list.
Configure company product info, account-wide sending identity defaults, rename individual sender and reply-to profiles, manage sender domains, and inspect integration examples for common frameworks.
Every published MCP tool includes explicit readOnlyHint, destructiveHint, and openWorldHint annotations so compatible clients can display accurate tool-use affordances. Tools also publish outputSchema definitions and return structuredContent, giving clients and models machine-readable result shapes for follow-up calls.
Related MCP server: Campaign Monitor MCP
Quick Setup
The easiest setup path is the Sequenzy wizard:
npx @sequenzy/setupThe wizard opens the browser login flow, creates a personal API key, detects supported AI clients, and configures them automatically when possible.
Hosted Remote MCP
For clients that support Streamable HTTP MCP, use Sequenzy's hosted endpoint instead of running a local stdio process:
https://api.sequenzy.com/v1/mcpChatGPT and the OpenAI plugin directory use the reviewed hosted surface:
https://api.sequenzy.com/v1/mcp/openaiThat surface shares the same implementation and keeps the standard tool set
except for six operations: connect_integration, create_api_key,
create_webhook, list_webhook_deliveries, replay_webhook_delivery, and
rotate_sequence_inbound_webhook_secret. Feedback stays available with a
reduced schema for generalized, explicitly requested product feedback.
Remote clients should authenticate with the Sequenzy OAuth flow when supported. Local and automation clients can still use the stdio package below with SEQUENZY_API_KEY.
The hosted endpoint and the stdio package support MCP specification
2026-07-28 while remaining compatible with 2025-era clients. Modern HTTP
clients use per-request discovery and method headers; existing clients keep
working through the same endpoint and package command.
Machine-readable discovery files:
MCP server manifest:
server.jsonAgent card:
.well-known/agent-card.jsonAgent capability manifest:
agent-capability.jsonOpenClaw skill metadata:
openclaw/skill.json
Data and privacy
Sequenzy sends an MCP client only the data needed for the tool the user asks it to run, within the selected workspace and the key or OAuth scopes granted to that client. Depending on the requested tool, this can include workspace names and IDs; subscriber contact, consent, audience, attribute, event, engagement, reply, survey, and commerce data; campaign and automation content; delivery analytics; and integration or webhook status. See the Sequenzy Privacy Policy for the full categories, purposes, recipients, retention periods, and user controls.
Do not use open-ended custom attributes, events, notes, forms, webhook samples, email variables, or feedback to submit payment-card data, health or medical data, government identifiers, biometric or genetic data, authentication credentials, sensitive demographic data, or precise geolocation.
The OpenAI-reviewed route states and enforces those restrictions on relevant
open-ended inputs, including nested attribute paths such as profile.ssn,
coordinate pairs such as lat/lng, and labelled prose such as
Religion: ... or GPS coordinates: .... It rejects a credential-bearing URL
in any argument, whether the credential sits in the userinfo, path, query, or
fragment, such as a form or popup redirectUrl with an access token or URL
signature. Restricted attribute selectors inside merge tags are rejected
without blocking ordinary authored copy about the same topic. On this surface,
render_email accepts sample data or a policy-checked inline subscriber, but
not subscriberId, so it cannot resolve uninspected stored custom attributes.
Its results remove restricted fields, raw API errors, debug payloads, internal
request/trace/session identifiers, unnecessary account or credential
identifiers, stored credential-bearing URLs, and inbound-webhook URLs. Standard
remote MCP and the local stdio package retain the complete contract for trusted
clients, including credential-based integration setup, one-time API-key and
webhook secrets, inbound-webhook URLs, and detailed API errors. Prefer the
dashboard or local CLI when secrets should stay outside an AI conversation.
submit_feedback runs only when the user explicitly asks; its OpenAI schema is
limited to a generalized message, category, and optional workflow context, and
the route rejects feedback text that contains an email address or resource ID.
What the reviewed surface guarantees is bounded. It recognizes restricted data
by shape: English field-name words such as passport_id, user.ssn, or
api_secret at any nesting depth, labelled prose such as Diagnosis: ...,
known credential shapes, decimal coordinate pairs, and credential-bearing URLs
inside any string, including HTML. It does not interpret unlabelled prose,
non-English field names, or values a client deliberately obfuscates; those
remain covered by the usage restriction above rather than by the filter.
Manual Setup
All stdio MCP clients use the same command:
Command:
npxArgs:
-y @sequenzy/mcpRequired env:
SEQUENZY_API_KEY=seq_user_your_key_here
Optional environment variables:
SEQUENZY_API_URL- Sequenzy API base URL. Defaults tohttps://api.sequenzy.com.SEQUENZY_APP_URL- Sequenzy dashboard base URL used by app URL helpers. Defaults tohttps://sequenzy.com.
Claude Desktop
Add this to your Claude Desktop config:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"sequenzy": {
"command": "npx",
"args": ["-y", "@sequenzy/mcp"],
"env": {
"SEQUENZY_API_KEY": "seq_user_your_key_here"
}
}
}
}Restart Claude Desktop after editing the config.
Claude Code
claude mcp add --scope user --env=SEQUENZY_API_KEY=seq_user_your_key_here sequenzy -- npx -y @sequenzy/mcpOn native Windows, wrap npx with cmd /c:
claude mcp add --scope user --env=SEQUENZY_API_KEY=seq_user_your_key_here sequenzy -- cmd /c npx -y @sequenzy/mcpFor a shared project config, use .mcp.json:
{
"mcpServers": {
"sequenzy": {
"command": "npx",
"args": ["-y", "@sequenzy/mcp"],
"env": {
"SEQUENZY_API_KEY": "seq_user_your_key_here"
}
}
}
}Codex
codex mcp add sequenzy --env SEQUENZY_API_KEY=seq_user_your_key_here -- npx -y @sequenzy/mcp
codex mcp listManual Codex config in ~/.codex/config.toml:
[mcp_servers.sequenzy]
command = "npx"
args = ["-y", "@sequenzy/mcp"]
[mcp_servers.sequenzy.env]
SEQUENZY_API_KEY = "seq_user_your_key_here"Cursor
Install Sequenzy from the Cursor Marketplace for a hosted connection with Sequenzy OAuth. The plugin connects to:
https://api.sequenzy.com/v1/mcpAfter installing, complete the browser sign-in flow. Cursor's agent can then use Sequenzy tools from chat, including when Grok is the selected model.
For a manual local stdio setup instead, add this to ~/.cursor/mcp.json:
{
"mcpServers": {
"sequenzy": {
"command": "npx",
"args": ["-y", "@sequenzy/mcp"],
"env": {
"SEQUENZY_API_KEY": "seq_user_your_key_here"
}
}
}
}Windsurf
Use the same JSON shape as Cursor.
macOS:
~/Library/Application Support/Windsurf/mcp.jsonWindows:
%APPDATA%\Windsurf\mcp.json
VS Code Copilot
VS Code uses a servers object:
{
"servers": {
"sequenzy": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@sequenzy/mcp"],
"env": {
"SEQUENZY_API_KEY": "seq_user_your_key_here"
}
}
}
}Other MCP Clients
For OpenClaw, Hermes, and other MCP-compatible clients, point the client at npx -y @sequenzy/mcp and set SEQUENZY_API_KEY.
Getting an API Key
Open the Sequenzy dashboard.
Use the MCP setup flow to create a personal key, or open Settings -> API Keys to create a company key.
Choose a permission preset or the exact custom scopes the integration needs.
Add the key to your MCP client config.
Personal keys start with seq_user_. You can revoke them any time in the dashboard.
Company keys can also be cleaned up without exposing secrets. Call
list_api_keys to compare the key ID, name, non-secret prefix, permissions,
last-use timestamp, and isCurrent marker, then pass the exact ID to
revoke_api_key. delete_api_key is a compatibility alias for the same
permanent operation. List and revoke responses never contain the plain key or
stored key hash.
Recover from missing API key permissions
If a tool reports a missing scope such as campaigns:read or
templates:write, call get_account. Its apiKeyPermissions field lists the
current key identity and type, scopes, common missing marketing read scopes, and
a direct manageUrl. The OpenAI-reviewed route returns the same permissions
without the user's account ID or the active key's identity. Personal keys open
Account API Keys; company keys open the selected workspace's API Keys settings.
If the key does not include
account:read, open the
Sequenzy dashboard directly and choose the
matching API Keys page.
Permissions are editable in place, so open manageUrl. For a company key, use
list_api_keys and its isCurrent flag to identify the active key before
editing it, then retry the failed tool without replacing the credential or
restarting the client. An agent using a company key with api_keys:manage can
instead call update_api_key; personal keys must be edited on the account-level
page because that tool only manages company keys. Its scopes and preset
inputs replace the whole permission selection rather than merging, so preserve
every existing scope that is still needed. Hosted OAuth connections can
alternatively disconnect and reauthorize with broader permissions.
When the active key itself lacks api_keys:manage, call
request_api_key_handoff instead of retrying update_api_key. It requires
account:read and returns an owner-review URL with the requested key name,
permissions, and optional predecessor prefilled. It never creates or returns a
key; the workspace owner reviews the form, creates the replacement in the
browser, and copies it into the client. Pass replaceApiKeyId: "current" to
offer revocation of the active key after the replacement is created. If the
active key also lacks account:read, use the dashboard directly.
The default Safer agent access preset includes lists:write and
tags:write, so agents can create and update list and tag definitions, and it
includes subscribers:tag for applying tags to existing contacts. It also
includes ab_tests:read, ab_tests:write, and sequences:write, so agents can
audit and edit sequence A/B variant copy, including cart and browse abandonment
messages. It does not include subscribers:write, so it cannot add contacts to
lists or remove them from lists. Deleting a list or tag still requires the
matching lists:delete or tags:delete permission.
The AI drafting preset includes subscribers:write, so drafting agents can
build a list as well as create it. Imports that apply listIds also need
lists:write; sequence enrollment or double-opt-in delivery additionally needs
automations:trigger.
Tools
The standard surface currently exposes 243 MCP tools. The OpenAI-reviewed surface exposes 237; only the six operations listed above are omitted.
Tools reject arguments they do not declare instead of silently ignoring them. Errors name the unsupported fields, list the supported arguments, and provide focused guidance for common mistakes such as invented subscriber filters or sort options.
Account, Companies, Setup
Tool | Description |
| Get account info, available companies, current key permissions, and the API Keys management URL. |
| Set the active company for future tool calls. |
| Build dashboard URLs for campaigns, landing pages, sequences, emails, settings, subscription management, domains, and sent email details. |
| Create a new company or brand. |
| Read company details, product info, brand context, localization, reply-tracking settings, current From/Reply-To defaults, and the effective read-only |
| Edit product info, brand context, email theme, reply tracking, and account-wide From/Reply-To profile defaults or names. |
| Read the company's event-to-tag rules and whether it uses the inherited platform preset. |
| Replace all sync rules; pass |
| Read browse-abandonment, cart-abandonment, and price-drop settings for the connected Shopify store. |
| Partially update Shopify automation settings or reset an individual section to its platform defaults. |
| Create a company API key and return its one-time secret on standard MCP; omitted from the OpenAI-reviewed route. |
| Prepare an owner-reviewed create/rotation URL when the active key cannot manage API keys itself. |
| List company API keys as non-secret metadata for safe identification and cleanup. |
| Rename a company API key or replace its permission preset or scopes without changing the key value. |
| Permanently revoke an exact company API key by ID after checking it with |
| Compatibility alias for |
| List sending domains with stored aggregate, SPF, DKIM, and MAIL FROM status. |
| Add a sending domain and return its cohort-specific DNS setup records. |
| Compatibility alias for |
| Read a sending domain's stored SPF, DKIM, MAIL FROM, and aggregate verification details. |
| Run a fresh sending-domain DNS/provider verification and return current status and diagnostics. |
| List connected integrations with connection and sync health, without returning credentials. |
| Diagnose active, paused, or suspended sending, including enforcement denominators, review gates, and remediation steps. |
| Restore an eligible hard-bounce pause after explicitly confirming the list has been sanitized. |
| Read account-wide and Transactional API open/click defaults, unsubscribe, attribution, UTM, click-domain, reply-tracking, and double-opt-in settings. |
| Update account-wide and Transactional API tracking defaults, attribution, UTM, and account-wide double opt-in. |
| Get framework-specific integration examples. |
| Inspect one connected integration, its event wiring, list targeting, recent activity, and recommendations. |
| Compare provider capabilities whether or not they are connected. |
| Connect supported API-key or webhook-secret providers on standard MCP, including managed Lemon Squeezy webhooks, outbound-only Attio, and optional PostHog/Segment history import; omitted from the OpenAI-reviewed route. |
| Inspect published event payload examples, property paths, types, and merge tags by provider. |
| Read the retained integration-specific webhook and sync activity log. |
| Enable or disable bulk imports and backfills while leaving live webhooks connected. |
| Choose which lists contacts created by a supported integration join on future provider writes. |
| Queue payment revenue, Supabase users, or a PostHog/Segment event-history import using the saved integration configuration. |
| Read Shopify's live pixel/configuration state and distinguish confirmed dark events from an unknown read. |
| Install or repoint Shopify's storefront pixel; idempotent when it is already current. |
| List publishable website-tracking keys, origin restrictions, usage state, and install snippets. |
| Get one website-tracking key with its exact install snippet and ingest endpoint. |
| Create a publishable tracking key for a non-Shopify storefront or website. |
| Rename, restrict, revoke, or re-enable a website-tracking key. |
| Permanently delete a website-tracking key after its snippet has been removed. |
| List sender and reply-to profiles, defaults, and sending-domain readiness. |
| Rename one sender or reply-to profile without changing the account defaults. |
| Permanently delete an unused sender profile, with guards for live sending surfaces and the last remaining sender. |
| Read the current user's per-company account notification settings and supported modes, including the Monday weekly report. |
| Update the current user's account notification delivery modes, including weekly-report opt-out, without affecting teammates. |
| Render final email-safe HTML and diagnose unresolved merge tags, including typos hidden by defaults. The OpenAI-reviewed route accepts sample data or a policy-checked inline subscriber, not a stored subscriber ID. |
get_sending_status keeps the Postgres-backed pause state, review gates, and
remediation available when sender-health analytics are temporarily unavailable;
in that degraded case senderHealth is null.
render_email returns unresolvedMergeTags so callers can distinguish an
unknown name from a recognized tag that is merely blank for the previewed
contact. Unknown names are reported even when a default filter supplied text:
for example, {{ subscriber.frstName | default: "there" }} renders a plausible
greeting for every contact while bypassing stored first names. A recognized
name that is blank for one contact is not reported when its default is used.
The OpenAI-reviewed route rejects restricted custom-attribute selectors inside
merge tags. It also omits the subscriberId argument; use a policy-checked
inline subscriber, or omit subscriber data for a sample preview.
To render a sequence step whose nodeType is action_ab_test, pass the
step's sequenceId and nodeId together with a variantId from
get_sequence.sequence.emails[].abTest.variants. These steps have no email of
their own, so the variant is required; reading and rendering their competing
copy also requires the ab_tests:read scope.
For Supabase, sync_integration reuses the project, schema, table, list
selection, and consent mappings saved in the dashboard. It cannot target an
arbitrary table. Run it after installing the live database trigger to import
users who existed before the trigger was installed, then poll get_integration
and list_integration_activity for progress and row-level outcomes.
set_integration_sync_enabled controls bulk imports and backfills only; it
does not stop a provider's live webhook from creating contacts. Use
set_integration_list_targeting to choose their future list memberships:
null follows workspace defaults, [] joins no list, and a populated array
targets those lists. The change is not retroactive and never removes existing
memberships. It also does not stop default any_contact sequences, which
enroll list-less contacts; explicit any_list and specific-list sequences
require a matching membership. Pair list targeting with
pause_sequence_enrollments when those default enrollments must stop too.
Supabase, Stripe, Shopify, Wix, and Webflow support this control.
For PostHog, sync_integration restarts the event-history import from the
beginning with the stored personal API key. Imported events are deduplicated, so
retrying a failed import does not create duplicates.
For Segment, connect_integration on standard MCP can optionally import recent
event history from Unify after the live webhook is connected. The import walks
existing contacts through the Profile API, covers the API's most recent 14 days,
skips contacts without a matching profile, and safely deduplicates retries and
live webhook overlap. New connections skip automatic page/screen calls unless
those names are explicitly allowlisted. Segment webhook secrets must be 16-153
UTF-8 bytes. On the OpenAI-reviewed route, which omits connect_integration,
connect Segment in the dashboard or local CLI instead. Use sync_integration
to retry with the saved credentials.
For Lemon Squeezy, pass provider: "lemon_squeezy", an API key, and the
numeric store ID as providerAccountId. Omit webhookSecret for the default
managed setup; the response reports webhookProvisioning and testMode.
Provide a 16-40 character signing secret only for manual webhook setup, using
the returned webhookUrl. Credentials are never returned.
For Attio, connect_integration on standard MCP accepts a workspace access
token without a webhook secret, with optional settings.listMap as a map of
Sequenzy list IDs to Attio people-list UUIDs or API slugs, plus
syncCompanyFromDomain to control company matching from non-free-mail domains.
On the OpenAI-reviewed route, connect Attio in the dashboard or local CLI, then
use update_attio_settings for the same settings. The integration is
outbound-only:
new joins to mapped Sequenzy lists upsert the person and add them to the Attio
list; list removals do not remove records from Attio.
Call get_event_schema before writing an {{event.*}} merge tag or an event
property filter. Omit eventName to list documented built-in events; provide
an event name to receive provider-specific example payloads and property paths,
and optionally filter by provider. Custom event names remain valid even when
the result reports documented: false; that only means no reference sample is
published. Use integration activity or sequence enrollments for actual delivery
data because this tool returns static reference data.
For a new sending domain, call add_sending_domain, publish the DNS records in
the returned website.dnsRecords, wait for DNS propagation, and then call
verify_sending_domain. Publish every returned record instead of assuming a
fixed provider or record count: unified domains include required DMARC, while
legacy domains can return Amazon SES MAIL FROM and inbound-reply records. If
verification is attempted before creation, the error points back to
add_sending_domain with the requested domain.
For Shopify, call get_integration_pixel before relying on product views,
cart activity, or browse-abandonment triggers. The result is read live from
Shopify because merchants can remove the pixel independently. If
pixel.healthy is false, dependentEvents names the triggers that cannot
arrive; call activate_integration_pixel to install or repoint the pixel.
Activation is idempotent, and events begin on the next storefront visit rather
than being backfilled.
For custom, headless, ticketing, or SaaS websites, use
list_web_tracking_keys before relying on product-view or cart triggers. Create
a key with an explicit origin allowlist, install the returned installSnippet,
then have the customer's authenticated backend mint a short-lived proof through
POST /api/v1/web-tracking-identities and call
sequenzy.identify(email, identityToken) at sign-in or checkout. A publishable
key alone only records anonymous activity and cannot trigger subscriber
automation. The returned snippet installs synchronous method stubs before its
async loader, so identity and event calls made during page bootstrap are queued
until the SDK is ready. Prefer revoking a key with update_web_tracking_key
before permanently deleting it.
New companies start with no sync rules. The inherited preset remains available
for SaaS/ecommerce companies by passing null to update_sync_rules; services
and consulting companies should normally keep [] or define explicit rules.
Use list_sender_profiles to find the profile ID, then call
update_sender_profile to change only its display name. Pass type: "reply"
for a reply-to profile; sender is the default. The address, sending domain, and
account-wide default From/Reply-To selections remain unchanged. Renaming
requires the companies:manage scope.
Use delete_sender_profile to permanently remove an obsolete From identity.
It refuses the last sender and any profile used by a live campaign, active
sequence (including a step override), or transactional email. Eligible drafts
and account defaults move to the returned fallbackSenderProfileId; review it
before sending. Reply-to profiles are not supported by this delete tool.
Shopify cart abandonment is enabled by default. It fires
ecommerce.cart_abandoned after one hour of cart inactivity, with a 24-hour
per-subscriber cooldown. Use update_shopify_automation_settings to change the
cartAbandonment.enabled, delayHours, or cooldownHours fields; pass
cartAbandonment: null to restore those defaults without changing browse
abandonment or price-drop settings. Timing values must be positive;
delayHours is capped at 168 and cooldownHours at 720.
Subscribers
Tool | Description |
| Add one subscriber; status is creation-only, so use |
| Queue up to 5,000 full CRM records with an optional retry-safe |
| Read progress, row outcome counts, and failure summaries for a queued import. |
| Update native profile and phone fields, SMS consent, attributes, tags, or global status. |
| Unsubscribe while preserving suppression history, or permanently delete only with |
| Fetch subscriber details by email or external ID. |
| Search by query, tags, list, status, segment, or one custom attribute, with automatic or resumable pagination. |
| Emit one custom event exactly as an integration would, applying sync rules and matching sequence triggers. |
| Emit several ordered custom events for one subscriber. |
| Import up to 25 source-identified events across contacts; silent history requires every row for a contact to be over an hour old. |
| Add tags to up to 500 existing subscribers; requires |
| Remove tags from up to 500 existing subscribers; requires |
Use create_subscriber_import for CRM onboarding instead of looping over
add_subscriber. One call accepts 5,000 full records and returns an asynchronous
import ID; poll it with get_subscriber_import. A completed import can still
contain row failures, so inspect failedCount and failedReasons. Every
excluded row is accounted for: skippedReasons sums to skippedCount, and
failedReasons sums to failedCount. Report any shortfall with the import ID
instead of guessing which rows were omitted. When email hygiene is enabled,
deliverability checks continue separately after ingestion and results appear
in List health; import status does not wait for or include those verdicts.
Invalid verdicts are suppressed from later sends. Use optInMode: "confirmed"
only when consent was already verified.
For import_subscriber_events, email is required when a row may create a new
contact; externalId can stand alone only for an existing contact. Supply a
stable eventId on every row. Retrying reuses the original receipt and
idempotently re-attempts downstream recovery. Historical classification is per
contact: if any row for a contact is recent, that contact's whole group uses
the live side-effect path.
For compliance suppression, call update_subscriber with
status: "unsubscribed" (or use remove_subscriber without hardDelete). Do
not retry add_subscriber with a different status: status on that tool applies
only when the contact is first created, and a mismatched skipped result is
reported as an error.
When add_subscriber omits listIds, a contact created by the call follows
the workspace default lists while an existing contact keeps its current list
memberships. Pass list IDs explicitly when an existing contact should join
specific lists; pass [] to target no lists.
update_subscriber.phone writes the native phone field shown on the contact,
not a custom attribute. Pass smsConsent: true only after verifying express
written consent, or false to opt the contact out. Changing the phone without
smsConsent resets SMS consent because consent belongs to the old number.
add_subscriber, update_subscriber, and create_subscriber_import accept an
IANA timezone such as America/New_York. The value is stored on the native
contact profile and enables recipient-local campaign delivery. Pass an empty
timezone to update_subscriber to clear it; invalid import-row values are
ignored without rejecting the rest of the import.
Products & Digital Delivery
Tool | Description |
| List synced products from Stripe, Shopify, WooCommerce, manual, or Commerce API data. |
| Create or update up to 100 Commerce API products keyed by your product ID. |
| Delete a product previously pushed through the Commerce API. |
| Attach a hosted or locally uploaded delivery file to a product. |
| Remove an attached product delivery file. |
| Queue a Stripe product catalog sync, optionally selecting an integration by ID. |
After a product delivery file is attached, matching purchase events include download.url and download.name, so purchase-triggered emails can use merge tags like {{event.download.url}}.
For Stripe products, list_products returns every active price as a variant, with the Stripe price ID in variantId. Use that ID to target an exact price in a purchase sequence even when it is not the product's default price.
Image Assets
Tool | Description |
| Upload an email image and return its hosted media record plus a ready-to-insert image block. |
The tool accepts PNG, JPEG, GIF, and WebP images up to 5MB. Local stdio clients
can pass filePath. Hosted/remote clients that can access attachment bytes can
pass imageBase64 with filename. Provide altText for accessibility, then
use displayWidthPercent, cropHeight, objectFit (cover or contain), and
align to standardize screenshot presentation. The returned imageBlock can
be copied directly into the block array accepted by campaign, sequence,
template, and transactional-email tools.
Authenticated image bytes are always uploaded to the origin configured by
SEQUENZY_API_URL, even if a reverse proxy returns an equivalent upload URL
under another host. API credentials are never forwarded to that alternate
origin.
{
"filePath": "/Users/me/Desktop/product-results.png",
"altText": "Product results dashboard",
"displayWidthPercent": 100,
"cropHeight": 320,
"objectFit": "cover",
"align": "center"
}Lists, Tags, Segments
Tool | Description |
| List all tags. |
| Create a tag definition with an optional color. |
| Update a tag color. |
| Delete a tag and remove it from subscribers. |
| List subscriber lists. |
| Create a subscriber list. |
| Rename or describe a subscriber list. |
| Delete a subscriber list. |
| Add up to 500 subscribers to a list from an email array. |
| Remove up to 500 subscribers from a list. |
| List saved segments and counts. |
| Create nested or same-element array-filtered segments. |
| Update segment name, filters, root group, or join operator. |
| Delete a segment (requires |
| Preview the active subscriber count for a segment. |
For subscriber exports, search_subscribers accepts listId, exact listName,
or list (ID first, then exact name). It also accepts attribute plus
attributeValue, with attributeOperator for contains, numeric comparisons,
or is_not_empty; the combined "attributeName:value" form remains supported.
Filters combine with AND; use a saved segment for OR logic, nested groups,
exclusions, engagement, or event conditions. If limit is omitted, the tool
fetches every matching page automatically. For chunked reads, pass limit and
follow pagination.nextCursor (or pagination.nextOffset) while hasMore is
true. offset and page are supported below 1,000,000 skipped matches; use the
cursor for deeper audiences.
For bulk list population, use add_subscribers_to_list; the backing API endpoint is POST /api/v1/lists/{listId}/subscribers with no /bulk suffix:
{
"emails": ["ada@example.com", "grace@example.com"],
"duplicateStrategy": "skip",
"enrollInSequences": false,
"optInMode": "default"
}Send at most 500 emails per request. Standard API rate limits still apply: 100 requests per minute per API key and 20 requests per second burst. For CSV-driven CLI imports, accepted email headers include email, e-mail, email address, and mail; if no recognized header exists, the CLI reads the first column.
Segment filters support attributes, events, saved segment membership, engagement events, Stripe product purchase rules, and commerce product purchase rules. Use filterJoinOperator: "or" for match-any segments, or pass a v2 root group for nested logic.
For array-of-object attributes, use wildcard paths such as
history_events[].eventvenue_id:2103. When an AND group also filters
history_events[].showing_date, both conditions must match one shared
history_events[] element; values from unrelated history entries are not
combined. Deleting a segment requires segments:delete; segments:write is
not sufficient.
Each segment filter field validates its own operators:
status,segment:is,is_nottag:contains,not_contains,is_empty,is_not_emptyemail:contains,not_containsemailProvider,list:is,is_not,is_empty,is_not_emptyfirstName,lastName:contains,not_contains,is_empty,is_not_emptyadded:less_than,more_thanattribute:is,is_not,is_empty,is_not_empty,gte,lte,gt,lt,contains,not_containsevent, email engagement fields:is,is_not,at_least,less_than_countemailBounced: also supportsis_temporary_bounce,is_permanent_bouncestripeProduct:is,is_not,at_least,less_than_countstripeCurrentProduct,stripeTrialProduct:is,is_not,gte,lte,gt,ltcommerceProduct:is,is_not,at_least,less_than_count
Stripe product filter examples:
{ "field": "stripeProduct", "operator": "is", "value": "prod_pro" }
{ "field": "stripeProduct", "operator": "is_not", "value": "prod_pro" }
{ "field": "stripeProduct", "operator": "at_least", "value": "prod_pro:3" }
{ "field": "stripeProduct", "operator": "less_than_count", "value": "prod_pro:3" }Commerce product filters match products purchased through commerce orders. Values can be provider:productId for provider-scoped IDs (shopify, woocommerce, or api), a bare product ID to match any provider, or provider:productId:count for threshold operators:
{ "field": "commerceProduct", "operator": "is", "value": "api:starter-kit" }
{ "field": "commerceProduct", "operator": "at_least", "value": "shopify:42:2" }Engagement fields such as emailSent, emailDelivered, emailOpened, emailClicked, emailBounced, and emailComplained accept rolling windows like 7d, 30d, 90d, 180d, or all. Presence operators can scope by delivery policy with marketing:<timeRange> (marketing-policy campaign, automation, and Send API traffic) or transactional:<timeRange> (transactional-policy sends); policy scopes require a send-time policy snapshot, so ambiguous older automation and Send API events remain available only through unscoped filters. emailBounced also supports scoped values with is_temporary_bounce and is_permanent_bounce. With at_least and less_than_count, use count:timeRange, such as 10:30d or 10:all. Presence operators can instead use a campaign scope like campaign:cmp_123; campaign and email-type scopes cannot be combined with count operators.
Audience Syncs (Meta Ads)
Tool | Description |
| List segment-to-audience syncs with schedule and last sync status. |
| List the Meta ad accounts available for syncing. |
| Push a segment to a Meta custom audience on a schedule. |
| Change sync frequency ( |
| Remove a sync mapping; the Meta audience itself is kept. |
| Trigger an immediate upload outside the regular schedule. |
Requires the Meta Ads integration to be connected in the Sequenzy dashboard (Settings -> Integrations). create_audience_sync accepts an existing segment (segmentId) or a ready-made template (predefinedSegmentId, for example zero-ltv, no-purchase-1y, recent-buyers, high-spenders-ecom, non-buyers, engaged) - the template segment is created automatically on first use, and the first upload runs immediately.
Audiences are add-only: subscribers who later leave the segment stay in the Meta audience. Meta requires 100+ matched people before an audience can be used for ad delivery.
Templates
Tool | Description |
| List templates with localization status, label and |
| Read template details, content, and localized variants. |
| Create templates from a prompt, HTML, or Sequenzy blocks; use |
| Update template metadata, inbox preview text, labels, HTML, or blocks; mark or unmark a master with |
| Create or replace a caller-supplied localized variant. |
| Queue AI translation for selected or all enabled non-primary locales. |
| Delete a template. |
list_templates returns 50 email bodies newest first by default and accepts a
limit up to 100. Advance offset by pagination.count while
pagination.hasMore is true; pagination.total reports the full matching
count, including campaign and transactional-email bodies.
Set isTemplate: true on list_templates to return only saved master designs,
or false to return ordinary email bodies. Marked masters are offered as
starting points for dashboard sequence steps and campaigns; starting from one creates
an independent copy so edits leave the master intact.
Standalone/sequence source-design copying and AI rewriting within a selected layout are currently
dashboard-only. This release intentionally keeps those workflows in interactive
authoring, where users can review the source, translations, and any fallback copy
before saving a sequence step. REST, CLI, and MCP expose no equivalent standalone/sequence source-design
operation. create_template with prompt generates new content without preserving
an existing layout; supplied HTML or blocks create a new body without automatically
copying localized variants. See the interface availability documentation.
Campaign copies already work through REST POST /api/v1/campaigns and MCP
create_campaign with templateId; it cannot be combined with prompt for an AI rewrite.
For net-new content requested in natural language, pass prompt so Sequenzy
generates branded native blocks server-side. Use blocks only for finished
caller-supplied Sequenzy content, and use html only when preserving supplied
or explicitly requested markup. prompt, blocks, and html are mutually
exclusive; style and tone are valid only with prompt.
Use set_template_localization when translated copy comes from your own
localization workflow. It requires an enabled non-primary locale, a localized
subject, and exactly one of html or blocks. Use
sync_template_localizations to ask Sequenzy to translate selected locales;
omit locales to sync every enabled non-primary locale. Explicit sync works
even when automatic on-save localization is disabled.
Reusable Email Components
Tool | Description |
| List saved sections and footers, optionally limited to pinned defaults. |
| Read one component's blocks, metadata, version, and default-slot state. |
| Read the component currently pinned to a default slot such as |
| Create or replace the company default footer used by newly built block emails. |
| Save a reusable section or footer from a block list. |
| Update component metadata or replace its blocks and increment its version. |
| Delete a component without changing emails that already copied its blocks. |
Components are copied into emails when those emails are built, so later edits affect newly built emails rather than rewriting existing content. The default footer keeps its unsubscribe link enabled, while transactional rendering hides that link. Raw HTML emails keep their own markup and do not receive block components; their send-time unsubscribe handling remains unchanged.
A/B Tests
Tool | Description |
| List A/B tests and variants, optionally scoped by sequence. |
| Get effective settings, variants, localization status, and sequence-step copy. |
| Get aggregate and per-variant stats. |
| Restart a stopped or completed A/B test. |
| Select a campaign test winner and queue remaining delivery. |
| Update campaign or sequence winner-selection settings. |
| Update campaign draft or sequence variant copy. |
| Create a campaign test or convert a sequence email step. |
| Add a variant to an existing A/B test. |
| Delete a draft A/B test variant. |
| Delete an A/B test. |
Use get_sequence.sequence.emails[].abTest.variants to discover sequence variant IDs, subjects, preview text, and block counts; call get_ab_test to audit every variant's full blocks, effective settings, localization status, or stats. Campaign settings use testPercentage, testDurationMinutes, and winnerCriteria; sequence settings use testType, winnerThreshold, and winnerCriteria. The legacy sequence values testPercentage: 100 and testDurationMinutes: 0 are compatibility sentinels, not runtime settings. select_ab_test_winner applies only to a campaign test that is currently testing and immediately queues the winning variant for the remaining audience. update_ab_test changes the appropriate settings model and requires confirmLiveChange: true when sequence settings affect an active or already-used test. Variant updates accept either html or blocks, not both.
create_ab_test accepts exactly one of campaignId or automationNodeId; the latter requires one to four extra variants and converts a sequence email node into action_ab_test. The conversion moves the step's subject, preview text, and blocks onto independent variant emails. Get the test and variant IDs from get_sequence, read every variant's copy with get_ab_test, and edit each one with update_ab_test_variant; update_sequence_node and update_template cannot edit variant copy, and a change intended for the whole step must be repeated for every variant. If update_ab_test_variant is not in the MCP tool list, enable it on the Sequenzy connector rather than writing through another email tool. The full workflow requires ab_tests:read, ab_tests:write, and sequences:write, all included in Safer agent access. With only sequences:read, get_sequence keeps the A/B step and control copy visible but redacts test-record fields and returns an empty variant list. An explicit sequence winnerCriteria overrides the testType default, so content variants can still be judged by opens. Pass confirmLiveChange: true when converting a node in an active sequence. Together with control A, an A/B test supports at most five variants. Sequence variants receive independent email templates and can be edited after creation; once the sequence is active or the test has activity, update_ab_test_variant requires confirmLiveChange: true. Variants can only be added or removed while the test is a draft, and live-sequence changes also require confirmation because they immediately change the rotation.
Campaigns
Tool | Description |
| List paginated campaigns by status or label, including reviewer feedback and delivery-pacing fields for account-wide STO audits. |
| Get details, stats, reviewer feedback, and recorded delivery pacing for a campaign. |
| Resolve saved targeting, missing references, a plain-language summary, and live recipient count. |
| List the conversion goals persisted for one email campaign (SMS is unsupported). |
| Add an event, subscriber-attribute, or tag-applied email-campaign conversion goal. |
| Update a persisted email-campaign conversion goal. |
| Delete a persisted email-campaign conversion goal. |
| Search recent delivery history with resource IDs and URLs, optionally scoped to one sequence step. Successful live-test sends are omitted. |
| Inspect a queued, test, sent, suppressed, or failed delivery by durable email-send ID. |
| List associated suppressed recipients, including protected global invalid addresses and complaints. |
| Check local bounce, complaint, email-hygiene, and regional SES suppression for one exact recipient. |
| Remove a workspace soft-bounce escalation while preserving global, hard-bounce, and complaint protections. |
| Create a campaign with content, data, and optional From/Reply-To identity overrides. |
| Update a draft campaign, including content, data, identities, audience, and persisted STO configuration. |
| Schedule or reschedule a campaign, optionally overriding STO and its 1-24 hour delivery window. |
| Send a test email to one address. |
| Render exact email-safe HTML and report unresolved tags, including typos hidden by defaults. |
| Cancel a scheduled or sending campaign. |
| Pause a sending campaign. |
| Resume a paused campaign, optionally spreading delivery over time. |
| Delete a campaign. |
| Duplicate a campaign into a new draft. |
| Create a draft resend for the original audience members who did not open a sent campaign. |
Prompt-created campaigns are generated and persisted in one API request and
remain drafts. Use templateId, blocks, or html only when copying or
preserving existing content rather than asking the agent to author it. Omit all
content fields to create an empty draft for later editing.
Campaign goals credit recipients who were actually sent that campaign within
the configured attribution window; an open or click remains the stronger
last-touch signal when one exists. Event goals require triggerEventName,
subscriber-attribute goals require attributePath, and tag-applied goals
require triggerTagName. The campaign attribution window defaults to 168
hours when omitted.
To deliver at the same wall-clock time in every recipient's own timezone, call
schedule_campaign with sendInRecipientTimezone: true and an IANA
scheduledTimezone that identifies the wall clock represented by
scheduledAt. Contacts without a stored timezone receive the campaign at the
scheduledAt instant. This mode cannot be combined with recurring or spread
delivery.
Send Time Optimization is configured per campaign, not at the company or
sequence level. Audit it across campaigns with list_campaigns, or inspect one
campaign with get_campaign. Set sendTimeOptimization and
sendTimeWindowHours (1-24, default 12) on a draft with update_campaign, or
override them while scheduling with schedule_campaign. spreadOverHours
takes precedence and disables STO, as does recipient-timezone delivery.
Sequences instead use sendingWindow, a shared allowed-hours/days gate rather
than per-recipient predicted send times.
For campaign- and sequence-level identities, fromEmail plus fromName
selects the sender identity with that display name on the mailbox, creating it
when needed without renaming other same-address identities. A Reply-To address
instead has one company-wide saved name: when replyToName differs from that
name, the saved name is kept and the successful response includes recovery
guidance in warnings.
send_email and send_test_email return a durable emailSendId. Use
list_email_sends to discover recent IDs by subject/title, recipient, delivery
status, type, bounce type, or source; pass an ID to get_email_send to inspect
status, errorMessage, the stored body, and delivery events. Delivery-list
rows are retained for 14 days. Successful live-test and other test sends are
omitted so they do not bury real deliveries. Replies to those test sends show
in list_conversations only when inbound reply capture is enabled. Queue jobs
are internal execution details and
are not exposed through the MCP contract. Every returned delivery has a direct
dashboard url. Use list_recipient_suppressions to distinguish protected
global invalid-recipient, protected company hard-bounce, and complaint rows from removable company soft-bounce
escalations, and use get_recipient_suppression for the exact regional status.
remove_recipient_suppression removes only the company escalation; global and
Amazon SES account-level suppressions, complaints, unsubscribes, and email-hygiene
protections remain intact. A local hygiene result uses the bounced reason with
email_hygiene as its source without changing the subscriber's consent status.
Agents should pass a caller-owned idempotencyKey to send_email before the
first attempt and reuse it for every retry of that same logical email. Sequenzy
returns the original emailSendId for 14 days instead of creating another
delivery. Reusing the key with different send arguments is rejected, so do not
generate a fresh key inside a retry loop.
Email blocks may use conditional display rules or conditional-group branches.
Conditions support render-time variables and subscriber attributes plus live
subscriber data such as segment/list membership, tags, events, engagement,
subscription/SMS status, and Stripe or commerce purchases. Live-data
conditions use the same field values and operators as segment filters;
recipients without a stored subscriber match use the OTHERWISE branch.
Core block shapes are { "type": "heading", "content": "Title", "level": 1 }, { "type": "text", "content": "<p>Copy</p>" }, { "type": "button", "text": "Book a call", "url": "https://example.com", "variant": "primary" } , and { "type": "image", "src": "https://...", "alt": "Description", "width": 100, "widthType": "percent" }. Buttons also accept content as an
alias for text and default to the primary variant. Image widthType accepts
percent or px.
YouTube video blocks accept an optional custom cover: { "type": "video", "videoUrl": "https://www.youtube.com/watch?v=...", "thumbnailUrl": "https://cdn.example.com/cover.jpg", "alt": "Watch the product tour" }.
Replacing blocks without thumbnailUrl restores YouTube's own still while
keeping videoUrl as the click destination.
Raw html is stored as one opaque block. It preserves supplied markup but does
not add a company logo, native branded sections, or theme-driven block design.
Use prompt for a new branded draft or blocks for editor-native design; MCP
authoring results include a warning when raw HTML is used.
Use update_company with fromEmail and/or replyTo to set account-wide
defaults. fromEmail must use a configured, verified sending domain; replyTo
may be any valid mailbox. create_campaign, update_campaign,
create_sequence, and update_sequence accept the same direct-address fields
for resource-specific overrides and create the backing profile when needed.
Send fromName or replyToName alone to rename the existing default profile
without changing its address. When an address has multiple display names, use
senderProfileId or replyProfileId from list_sender_profiles to select the
exact profile to make default and rename.
update_company also manages the company's default email theme through
emailTheme (presetId, colors, typography, layout). Theme updates are
partial - omitted fields keep their current value (or the preset default) and
numeric values are clamped to supported ranges. Pass emailTheme: null to
reset the company to the platform default theme. Layout settings can control
the shared baseRadius and a separate buttonRadius. Within colors,
background paints the outer canvas, content paints the inner content card,
and surface paints nested cards or tinted tiles. Omitting content preserves
its current value; when no content color is stored, the card follows
background.
Reply tracking is available on the same company tools. Use
replyTrackingEnabled, replyTrackingDomainMode (sequenzy or custom), and
forwardReplies with update_company. Company reads also return the current
read-only replyRetentionDays value.
Polls and NPS surveys are native email blocks, so they work anywhere an email
tool accepts blocks, including campaigns, templates, A/B variants,
transactional templates, and sequence email steps. Transactional poll sends
must resolve to exactly one effective recipient after suppression filtering and
recipient deduplication, and that recipient must already exist as a subscriber;
otherwise Sequenzy rejects the send because the answer link cannot be safely
attributed. Use an answer-button poll:
{
"type": "poll",
"variant": "options",
"question": "What did you think of this email?",
"options": [
{ "label": "Loved it", "value": "loved" },
{ "label": "Not for me", "value": "not_for_me" }
],
"attributeKey": "email_feedback"
}For NPS, use "variant": "nps", an empty options array, and an attribute
such as nps_score. The scale is always 0-10; optional npsLowLabel and
npsHighLabel customize its captions. Each answer updates the subscriber
attribute and fires poll.answered for automations and outbound webhooks.
Set "allowMultiple": true on a text-only options poll to open a hosted page
where recipients can check several answers and save the whole selection at
once. The subscriber attribute stores the selected-value list, so attribute
segments should use contains. Multi-select polls cannot use option images or
configurations whose encoded signed links exceed the delivery-safe size limit.
Campaign poll summaries set allowMultiple: true, use respondent count for
totalResponses, and can report answer percentages that add up past 100%.
Poll blocks also support brand-specific styling. accentColor recolors every
appearance, including "brutal"; optionRadius sets answer-button corners in
pixels (0 is square), independently of the container's
styles.borderRadius; and questionColor recolors only the question.
fontFamily applies to the poll. Use the optionFontSize,
optionFontWeight, optionLetterSpacing, and optionTextTransform fields for
answers, or the matching question* fields for the question. Sizes and
spacing are pixels, weights range from 100 to 900, and text transforms are
"none" or "uppercase".
Saved Forms
Tool | Description |
| List saved forms with their server-managed audience settings, content blocks, and public action URLs. |
| Create and publish a saved form with standard email/name fields, audience settings, theme, and success behavior. |
| Update a saved form, including its complete ordered block array and typed custom fields. |
| Return the public action URL, hosted JavaScript, minimal native form, and fetch example for a saved form. |
For Astro, Hugo, Jekyll, Cloudflare Pages, Netlify, GitHub Pages, or any other
static site, call list_forms, use create_form if a suitable form does not
exist, then call get_form_embed. The returned opaque formId is the public
capability: lists, tags, duplicate behavior, and success handling remain
server-side, so the deployed browser code never contains a Sequenzy API key.
Generated native and standalone markup includes "Powered by Sequenzy" for free
workspaces; paid workspaces receive unbranded markup. The API resolves that
entitlement server-side, so callers should use the returned snippet unchanged.
When updating a form, omitted fields remain unchanged and theme fields merge
into the current theme. Pass an empty tagIds array to clear tags or an empty
redirectUrl to restore confirmation-message behavior. The blocks field is
a complete replacement, so read the current content with list_forms first
and retain exactly one required email field and one submit button. Add custom
inputs as form-field blocks with a supported fieldType; select, radio, and
checkbox fields require options, while hidden defaults are enforced server-side.
Saved Popups
Tool | Description |
| List saved popups with status and engagement stats, optionally including full content. |
| Get one popup's blocks, trigger, targeting, schedule, frequency, theme, and published embed code. |
| Create a popup from a starting template, published by default, and return its deployment script. |
| Partially update popup copy, audience, behavior, theme, blocks, or publication status. |
| Return secret-free HTML, React/Next.js, WordPress, and Shopify embed snippets. |
| Copy a popup into a draft with independent engagement counters. |
| Permanently delete a popup and its engagement counters. |
Popup deployment uses one public script tag; API keys, audience settings,
triggering, targeting, scheduling, and frequency rules remain server-side.
Popups capture into every list by default unless listIds is provided. When
updating blocks, read the popup first and send the complete replacement array,
retaining exactly one required email field and one submit button. Setting
status to draft stops a popup without invalidating its existing embed code.
Landing Pages
Tool | Description |
| List landing pages with status, metrics, content, and URLs. |
| Get landing page details, builder content, metrics, and published URLs. |
| Return a signed 24-hour visitor preview without publishing, counting views, or collecting signups. |
| Create a draft landing page from default template content or JSON. |
| Edit a landing page name, slug, or full editor-compatible content. |
| Publish a landing page, optionally saving edits first. |
| Return a landing page to draft status, optionally saving edits first. |
| Duplicate a landing page into a new draft with a unique slug. |
| Delete an unpublished landing page. |
| Connect a custom landing page domain and return DNS setup details. |
| Replace or verify landing page custom domain settings. |
Landing page content uses Sequenzy's editor-compatible JSON schema with
version, template, seo, theme, and blocks. SEO settings include
faviconUrl and hideFromSearchEngines; hidden pages publish a noindex
directive. Use render_landing_page to review the current visitor-facing page
before publishing. Its signed previewUrl expires after 24 hours, is unlisted,
is not indexed, and does not increment page views; forms remain visible but do
not collect contacts. Blocks render in slot order:
top, hero, form, body, then
footer; use top for a full-width announcement or banner above the hero.
Button and pricing CTA URLs accept external HTTPS destinations or in-page
anchors such as #form, #section-<sectionId>, #block-<blockId>, and
#top. Set theme.sectionAnimation to none, fade, slide-up, or
zoom-in, with theme.sectionAnimationSpeed set to slow, normal, or
fast, to control published scroll reveals. Custom landing page subdomains
require a CNAME record pointing to pages.sequenzydns.com; root domains use an
A record pointing to 76.76.21.21, and their www host redirects to the root
when its CNAME points to pages.sequenzydns.com. Call
update_landing_page_domain_settings with verify: true after DNS changes
propagate.
Sequences
Tool | Description |
| List sequences with dashboard status, search, label, limit, and offset filters. |
| Get sequence details, A/B variant IDs and block counts with |
| List contact enrollments with pagination and accurate list/tag/event/time-based entry attribution. Live sequence tests do not create enrollments. |
| Send one saved action_email step to 1-10 reviewers; A/B steps are inspected per variant. |
| Create a blank dashboard draft or an AI-generated/explicit-step sequence. |
| Update identity, settings, enrollment, existing steps, branch logic, or insert linear steps. |
| Type-aware patch of one existing sequence node. |
| Atomically patch multiple existing sequence nodes. |
| Insert any typed dashboard step, including AI generation, outbound webhooks, waits, and wired branches. |
| Move, reconnect, delete, or duplicate graph nodes; reports recipients moved or completed. |
| Dry-run current matches, activation readiness, and an optional contact's branch path without enrolling or sending. |
| Activate a sequence. |
| Freeze a sequence, blocking new enrollments and holding current recipients. |
| Create an independent draft copy of the graph, emails, and sequence A/B tests. |
| Move a sequence into the dashboard archive and stop new enrollments. |
| Restore an archived sequence as a disabled draft. |
| List the event, subscriber-attribute, and tag-applied conversion goals persisted for a sequence. |
| Add an event, subscriber-attribute, or tag-applied conversion goal. |
| Update a persisted sequence conversion goal. |
| Delete a persisted sequence conversion goal. |
| Read the inbound URL, setup state, sample, and mapping on standard MCP; the OpenAI route removes the credential-bearing URL. |
| Configure the endpoint, field mapping, and sample; the OpenAI route removes the credential-bearing URL from its result. |
| Rotate an inbound sequence endpoint's secret and return its replacement URL on standard MCP; omitted from the OpenAI-reviewed route. |
| Stop new enrollments for an active sequence while current recipients continue. |
| Reopen new enrollments for an active sequence without changing current recipients. |
| Enroll up to 500 subscribers by email, subscriber ID, or both, with retry-safe idempotency. |
| Stop active or waiting enrollments by subscriber or entry-event field values. |
| Preview or queue moving live waits earlier to their sending-window opening. |
| Poll an applied realignment job and read its completed result or continuation cursor. |
| Delete a sequence. |
Sequence creation supports:
Name-only creation for a blank, disabled trigger-to-completion draft matching the dashboard.
Dashboard metadata and delivery settings:
description,labels,userCancellable, sequence BCC, and From/Reply-To identity.trigger: "contact_added"withlistId, severallistIds, orlistScope:any_contact(the default) enrolls every added contact, including contacts that join no list, whileany_listwaits for an actual list membership.trigger: "tag_added"withtagNameor severaltagNames; any configured tag enrolls the contact.trigger: "segment_entered"plussegmentIdfor saved-segment entry automations.trigger: "event_received"plus{{event.*}}merge tags in subjects or body content.trigger: "inbound_webhook"plus integration metadata for dashboard-compatible webhook entry nodes.trigger: "inactivity"pluseventName,inactiveDays, and optionalinactivityBaseline(sequence_created_atorsubscriber_created_at).goalfor AI-generated email content.emailStyle: "visual"or"plain"to choose the presentation of goal-based AI-generated emails; when omitted, the company's saved preference is used.Explicit
stepswith Sequenzyblocks.Explicit
stepswith HTML, which Sequenzy converts into editable blocks.Explicit Update Subscriber steps that copy trigger-event properties into profile fields or typed custom attributes.
Fixed waits via
delay/delayMs, dynamic date-field waits viawaitUntil, or calendar gates viawaitUntilWeekday. A weekday gate such as{ "day": "sunday", "startTime": "09:00", "endTime": "12:00", "timezone": "America/Los_Angeles" }holds the flow until the next matching window. Place it immediately before an email to keep that send inside the window; any intervening step can shift delivery outside it. Queue recovery rechecks the window before releasing a delayed contact.Dynamic Stripe or Shopify discount action steps. A
create_discountstep creates a fresh provider code when each subscriber reaches it; later emails can use merge tags like{{discount.code}},{{discount.percentOff}}, and{{discount.expiresAt}}.enrollmentMode: "matching_field"and a scalarenrollmentFieldPathfor product-, variant-, order-, or subscription-specific event automations. Array traversal with[]belongs inpropertyFilters, not the enrollment key.
For a custom event trigger, the successful create_sequence result includes
eventTrackingCode and a structured eventTracking object. The object contains
the event endpoint, identity and payload contract, any property path required by
matching_field enrollment, normalized trigger propertyFilters, an example
payload, examplePayloadMatchesFilters, the direct event API docs URL, and
ready-to-use arguments for get_integration_guide. If the match status is
false, adapt the example using examplePayloadNote and the payload contract.
Add this event feed and verify its required properties before enabling the draft
sequence.
list_sequence_enrollments returns enteredVia for each row. List and segment
sources keep their stable ID in value and resolve a display name; tag and
event sources retain their names in value. Time-based triggers report
inactivity or frequency rather than being misidentified as ordinary
received-event enrollments. Live sequence tests do not create enrollments;
they send isolated test emails and record activity on the sequence test run
instead.
For a confirmed manual enrollment batch, generate idempotencyKey once and
reuse that exact key only with identical ordered targets and targetNodeId.
Receipts last 14 days. A retry returns the original enrolled, skipped,
notFound, targetNodeId, and scheduledFor values with
idempotentReplay: true; it does not create tokens or queue the batch again.
Example dynamic Shopify discount step:
{
"type": "create_discount",
"discount": {
"provider": "shopify",
"discountType": "percent",
"percentOff": 20,
"duration": "once",
"appliesToAllPlans": true,
"maxRedemptions": 1,
"codePrefix": "WINBACK"
}
}Example Update Subscriber step:
{
"type": "update_subscriber",
"nodeType": "action_update_attributes",
"config": {
"firstName": "{{event.firstName}}",
"customAttributeUpdates": [
{ "name": "plan", "value": "{{event.plan}}", "valueType": "text" },
{ "name": "mrr", "value": "{{event.amount}}", "valueType": "number" },
{ "name": "active", "value": "{{event.active}}", "valueType": "boolean" }
]
}
}Number and boolean values must be literals or one standalone merge tag. Use
update_sequence.subscriberUpdateSteps with an action_update_attributes
node ID from get_sequence to replace an existing step's config.
Sequence updates support insertSteps for adding new linear steps after a nodeId returned by get_sequence. Omit afterNodeId only when appending to a sequence with exactly one linear tail. insertSteps supports addable steps that do not require companion records, such as email, delay, tag/list actions, attribute updates, discounts, conditions, wait-for-event steps, outbound webhooks, and AI steps. An action_ai step requires a merge-tag prompt, unique resultKey, and one or more outputFields; later steps read generated or fallback text with {{ai.KEY.field}}. Combined output-field limits must fit the step's 2000-token response budget. Use includeTags, includeEventProperties, or includeAttributes to opt specific contact context into generation, and onError (continue, exit, or fail) to choose failure behavior. Use branch for multi-path if/else branches; provide either branch or insertSteps, not both. Branch conditions support tag presence and absence checks with has_tag and does_not_have_tag, plus lists, saved segments, events, clicked links, and field comparisons. Each branch path may provide new steps, an existing targetNodeId, or both; the fallback uses elseSteps and/or elseTargetNodeId. A target can be the completion node returned by get_sequence, so one atomic request can route replies to completion and Else to an existing follow-up. The emails and steps arrays edit ordinary action_email steps by nodeId, emailId, or array order. get_sequence.sequence.emails also includes action_ab_test entries; with ab_tests:read, each abTest.variants[] entry contains the variant ID, subject, preview text, and block count. Call get_ab_test for full variant bodies before auditing or rewriting copy. A positional update landing on one is rejected, and its copy must be changed per variant with update_ab_test_variant; do not retry through update_template or update_sequence_node. Use insertSteps to create new steps and include a step-level delay, delayMs, waitUntil, or waitUntilWeekday when the inserted email needs a timer. waitUntil accepts a date field from the trigger event plus optional offset, direction (before or after), and missingAction (continue or exit). waitUntilWeekday accepts day or days, startTime, optional endTime (default 24:00), and an IANA timezone; contacts already inside the window continue immediately. For active sequences, pass confirmStructuralChange: true with insertSteps or branch only after confirming the live-flow impact.
insert_sequence_step exposes every companion-record-free dashboard step directly: email, SMS, delay, discount, subscriber update, tag/list action, outbound webhook, AI generation, condition, wait, and branch. Set type: "ai" with prompt, resultKey, and outputFields to generate per-contact text for later {{ai.KEY.field}} merge tags. Outbound webhooks accept url, method (POST or GET), and string-valued headers. Email steps support transactional mode, per-step identity, and CC/BCC delivery settings. For a wait gate, set
type: "logic_wait_for_event" with eventName, optional timeoutDays (1-365),
and timeoutAction (continue or exit). For a branch, set
type: "logic_branch", provide typed branches, and wire their targets:
{
"sequenceId": "seq_123",
"type": "logic_branch",
"afterNodeId": "node_email_1",
"branches": [
{
"id": "replied",
"conditionType": "event_received",
"eventName": "email.replied",
"activityScope": "this_sequence",
"targetNodeId": "node_complete"
}
],
"elseTargetNodeId": "node_email_2"
}Each linked email returned by get_sequence includes its effective
emailPreset (branded or minimal), matching Style > Format in the
dashboard. Set emailPreset on an emails/steps item, or in an
action_email node's changes, to change only that linked email without
changing the company theme. This applies the same format transformation as the
dashboard to native Sequenzy blocks, including emails that contain supported
custom HTML blocks. Emails stored entirely as one standalone raw HTML block
return null for emailPreset and do not support format changes.
emailPreset cannot be combined with html or htmlContent because those
fields replace the entire email with standalone raw HTML.
For sequence position, prefer structuralStepNumber on linked emails and the
top level of email nodes. It is derived from the current graph and matches the
step badge shown in the dashboard. Parallel branch emails intentionally share
the same structural depth, and an unequal branch merge continues from the
longer incoming path. The older stepNumber field in linked emails and node
configs remains a stored ordinal for backward compatibility and may be stale
after graph edits.
Each linked email also returns its stored emailTheme override, or null when
it follows the company theme. Set emailTheme on an emails/steps item or in
an action_email node's changes to restyle only that step. Theme updates are
partial patches, so changes: { "emailTheme": { "colors": { "background": "#f3f4f6", "content": "#ffffff" } } } gives that email a gray
outer canvas and white content card while retaining its other colors,
typography, and layout. Omitting either color preserves its current value. Pass
emailTheme: null to drop the override and follow the company theme again. Use
update_company only when the account-wide default should change.
Use update_sequence_node for a focused in-place edit, or
update_sequence_nodes when several node patches must commit atomically. Call
get_sequence first: every item in sequence.nodes includes the node id,
nodeType, current config, updatedAt, and updateHints with editable and
managed fields plus the exact concurrency token to return. Pass that token as
expectedUpdatedAt to reject stale writes. The tools support every stored node
type, including delays, email/SMS content, actions, conditions, webhooks,
branch configuration without topology changes, and triggers. To change a
5-minute delay to 7 days, send changes: { "delay": { "days": 7 } } for its
logic_delay node. To make several founder-style notes Minimal, patch their
action_email nodes with changes: { "emailPreset": "minimal" }. Node-type
conversion and edge/path changes belong in edit_sequence_graph. Active
sequences require confirmLiveChange: true after the user confirms the impact;
recipients already waiting retain their existing scheduled timestamp.
Existing and newly inserted email steps can set their own From identity with
senderProfileId or fromEmail plus optional fromName, and their Reply-To
identity with replyProfileId or replyTo plus optional replyToName. A
fromName on its own changes only that step's visible sender name. A step-level
replyToName similarly overrides the visible Reply-To name for that step
without renaming the company-wide reply profile. New email steps without
explicit identity fields inherit the effective identity of the nearest
sequence email. After a branch merge, only identity fields shared by every
incoming path are inherited; conflicting fields use the sequence or company
defaults.
Use edit_sequence_graph with the latest graphRevision from get_sequence to restructure an existing sequence atomically. It can move a node before or after another node, reuse the normalized sequence.edges array for explicit reconnection or multi-node reordering, delete a node, or deep-copy a node. A/B test duplication creates independent test, variant, email, and localization records with reset statistics. Moving a node before the shared node below a branch reconnects every converging branch path through that node. Deleting a node immediately moves parked recipients to its unique surviving successor, or completes them when no successor remains; inspect sequence.migratedRecipientCount and sequence.completedRecipientCount in the result. Deletion is refused when parked recipients would have multiple surviving continuations. Stale revisions, invalid branch lanes, cycles, and unreachable nodes are also rejected. Active sequences require confirmStructuralChange: true.
Run cancel_sequence_enrollments with dryRun: true before applying bulk cancellation.
Run realign_sequence_enrollments after changing a live sequence's sending
window when existing email-bound waits should move earlier to the new opening.
It defaults to dryRun: true. Passing dryRun: false queues a background job
and returns jobId; poll it with get_sequence_enrollment_realignment. When a
completed result has hasMore: true, queue the next bounded apply with its
nextCursor. Applied realignment changes live delivery times and should only be
used after the user confirms the preview.
Email Blocks
Tool | Description |
| List every email block type or inspect one type's required fields, enum values, item shapes, and example. |
Call get_email_block_schema before hand-authoring a block type you have not
used before. Omit blockType to list every type, pass a type such as list or
steps for its complete reference, or pass creatableOnly: true to hide types
managed by the editor. Persisted group blocks are structural editor content:
they recursively wrap child blocks in Stack, Row, Grid, or single-image Overlay
layouts, but AI generation and creatableOnly intentionally omit them. Request
blockType: "group" to inspect their fields when reading or updating existing
grouped content. Lists are their own block type rather than a text
variant: list items use content, while steps items use title and an
optional description.
Tools that accept blocks persist per-block visual styling under a block's styles object:
{
"type": "card",
"title": "Your update",
"content": "Everything is ready.",
"variant": "default",
"styles": {
"backgroundColor": "#f8fafc",
"backgroundOpacity": 85,
"borderColor": "#cbd5e1",
"borderWidth": 1,
"borderRadius": 12
}
}For compatibility with older agent prompts, top-level style keys such as backgroundColor, backgroundOpacity, borderColor, borderWidth, and borderRadius are also accepted and saved under styles.
Transactional Email
Tool | Description |
| Search/filter templates and sort by delivery metrics; returns subjects and dashboard URLs. |
| Read a transactional email by ID or slug. |
| Create a transactional template from a prompt, HTML, or blocks. |
| Update transactional metadata or body content. |
| Send one email by template or HTML to shared To, Cc, and Bcc recipients. |
Prompt-created transactional templates are generated server-side and default
to disabled for review. Explicit HTML or block templates retain the
compatibility default of enabled; pass enabled explicitly to override either
default.
For a direct send, pass to, subject, and html; the MCP server maps html
to the transactional API's body field. For a saved transactional email, pass
its API slug through the compatibility-named templateId field instead.
For transactional sends, to, cc, and bcc each accept one address or an
array of up to 50. The API sends one email with a shared recipient list and
removes cross-field duplicates in to, then cc, then bcc priority order.
Marketing sends still require exactly one accepted to address and do not
support additional recipients.
send_email variables support nested arrays for repeat blocks, such as
{ "event": { "items": [...] } }. When the recipient matches a stored
subscriber by external ID or email, saved first and last names fill omitted name
variables automatically. Explicit values, including blanks, take precedence.
The optional attachments array accepts up to 10 files / 7MB total. Each item
needs filename and exactly one of Base64 content or a public HTTP(S) path.
Set contentId to embed a CID image referenced from the HTML and optionally set
contentType to override MIME detection.
When trackingSettings is omitted, the company's Transactional API tracking
defaults apply. Use trackingSettings.clickTracking: false or
trackingSettings.openTracking: false to disable link rewriting or the open
pixel for one send. These per-send options only opt out; they cannot enable
tracking disabled by an account-wide or Transactional API default. Use
get_tracking_settings and update_tracking_settings to inspect or change
those defaults.
For agent and workflow retries, include a stable idempotencyKey (up to 255
characters) in send_email. Use one key per logical email and send the same
arguments when retrying; the key remains valid for 14 days.
Analytics
Tool | Description |
| Get overview stats for |
| Get all-time or time-scoped metrics for one saved transactional email by ID or slug. |
| Get campaign performance, reply metrics, attached conversion goals, and Poll/NPS summaries. |
| List each respondent's latest Poll/NPS answer per block, with identity and response time. |
| Get aggregate and per-step sequence performance plus live active/waiting enrollment counts by current node. |
| Compare campaign and sequence-step funnels, replies, conversions, and revenue, including cross-sequence steps. |
| List paginated raw email events for a campaign. |
| List paginated raw events for a sequence, optionally scoped to one email step. |
| Get subscriber email stats, activity, and enrollments. |
Campaign and sequence event filters accept transport_failure alongside
delivery, bounce, complaint, engagement, unsubscribe, and delay events.
Transport failures describe MTA infrastructure or egress-path exhaustion; they
do not classify a valid recipient address as bounced.
Analytics tools exclude detected bot, scanner, link-preview, and tracked asset opens/clicks by default. Pass includeMachineEngagement: true to get_stats, get_campaign_stats, get_sequence_stats, get_ab_test_stats, get_subscriber, or get_subscriber_activity when you need raw engagement diagnostics; included open/click activity rows expose machine, engagementQuality, and classificationReasons fields where the API returns event-level activity.
get_sequence_stats.enrollmentCounts is a live point-in-time snapshot of
active and waiting enrollment runs grouped by current node. It counts
enrollment tokens rather than necessarily distinct subscribers, and it is not
limited by historical period, start, or end filters.
Use list_email_metrics for comparisons across campaigns or sequence steps.
Pass step with optional sequenceId values to total the same step across
sequences; use the returned automationNodeId with list_sequence_events or
list_email_sends to inspect recipients. campaignId cannot be combined with
sequenceId or step. Explicit campaign and sequence scopes retain configured
emails with zero activity so weak performers are not silently omitted.
Pass emailType: "transactional" to get_stats for Send API and
transactional SMTP delivery, open, click, and reply rates. This includes direct
and saved-template sends. Use the emailSendId returned by send_email with
get_email_send when you need one delivery's status and event timeline.
Use get_transactional_stats when you need aggregate rates for one saved
transactional email. Its response includes top clicked links, complaints,
replies, latest permanent/transient bounce classifications, and separate human
and machine open/click counts. Direct-content sends do not have a stable
template ID and remain available through account transactional stats plus
delivery search.
When a campaign collects Poll or NPS answers, get_campaign_stats includes a
top-level polls array. Each subscriber counts once per poll block using their
latest answer. NPS summaries include the score, average, and
promoter/passive/detractor counts. These are lifetime response summaries even
when engagement metrics use a time filter.
Use list_poll_responses to read who answered what and when. It returns each
subscriber's latest answer per poll block, newest first, including the email,
stored value, attribute key, and response time. Pass blockId to scope one
poll; for a sequence email step, pass its automation node ID as campaignId.
Do not reconstruct this history by scanning subscriber attributes: an
attribute has no response timestamp and may have been overwritten by a later
email that reused the same key.
To list the exact historical respondents behind a count, call create_segment
with field pollResponse, operator is, and a JSON value scoped to the
campaign and the summary's blockId:
{
"v": 1,
"campaignId": "camp_123",
"blockId": "poll_1",
"match": { "kind": "answer", "value": "loved" }
}For NPS, use a match such as
{"kind":"npsBucket","bucket":"detractors"}; valid buckets are
promoters, passives, and detractors. The summary's attributeKey stores
the subscriber's current/latest response and may be overwritten by a later poll
that reuses the key, so it is not an exact historical drill-down.
Team, Inbox, Webhooks
Tool | Description |
| List team members and pending invitations. |
| Invite a teammate as admin or viewer, with optional billing access. |
| Cancel a pending team invitation. |
| List subscriber reply conversations with status and unread filters. |
| Read a conversation and its message history. |
| Queue an outbound reply or add an internal note. |
| Open or close a conversation. |
| Mark all messages in a conversation as read. |
| List outbound webhook endpoints. |
| Create an endpoint and return its one-time signing secret on standard MCP; omitted from the OpenAI-reviewed route. |
| Update webhook name, URL, events, or status. |
| Permanently delete a webhook endpoint and delivery history. |
| Send a test event to a webhook endpoint. |
| List recent delivery attempts for a webhook. |
| Replay a webhook delivery. |
Per-list consent changes are available as opt-in outbound events:
subscriber.list_subscribed and subscriber.list_unsubscribed. Their payloads
identify the subscriber and list, report action as added or removed, and
include the change source (for example preferences_page, dashboard,
api, or automation).
Use the email.failed event for terminal delivery failures such as exhausted
MTA transport paths. Recipient bounces continue to use email.bounced.
Use the explicit-only campaign.sent event when a workflow needs one terminal
notification after an email or SMS campaign settles, including a valid
zero-recipient send. It is not added when create_webhook omits events on
standard MCP; on the OpenAI-reviewed route, add it in the dashboard when
creating or editing the webhook.
AI Generation
Tool | Description |
| Generate branded email blocks from a prompt. |
| Deprecated alias that persists a goal-based sequence draft. |
| Generate A/B subject line variants. |
Generated email content includes the company's logo and footer by default.
generate_email accepts applyBranding: false for raw content blocks and
emailType: "transactional" for a footer without an unsubscribe link.
Prompt-based campaigns inherit the company's configured email font. Generated
content is returned as draft content for review. Use create_sequence to
generate and persist a disabled sequence draft that appears in
list_sequences; the deprecated generate_sequence alias does the same.
SMS
Tool | Description |
| Generate SMS copy from a prompt. |
| Read SMS add-on readiness, credits, defaults, and provisioned numbers. |
| Compare sends, delivery outcomes, charged credits, last activity, and test sends by number. |
| Update a number's label or per-number brand-prefix override. |
| Permanently return a number to the carrier and free its workspace slot. |
| Send a test message, optionally choosing a provisioned sender with |
release_sms_number is irreversible. Campaign or sequence steps pinned to a
released number will skip their SMS sends until they are repointed to an active
number. get_sms_usage reports production totals separately from testSends.
When send_test_sms omits fromNumberId, it uses the same oldest-active-number
default as production sends. Test sends are real, credit-charged messages that
bypass quiet hours and are limited to 100 per company in a rolling 24-hour
window.
Product Feedback
Use submit_feedback only when the user explicitly asks the assistant to send
feedback to the Sequenzy team. Standard MCP can include the structured
reproduction fields userIntent, toolCalls, expected, actual, and
resourceIds when needed for that report. The OpenAI-reviewed route accepts
only the message, category, and optional generalized workflow context. Do not
include unrelated subscriber data, email content, raw API payloads, debug data,
or secrets.
Resources
The server also exposes read-only MCP resources.
Resource | Description |
| Live overview stats for the last 7 days. |
| Current company and localization settings. |
| Last 10 campaigns with status and basic stats. |
| Most recently added subscribers. |
| Most active or engaged subscribers. |
| All sequences with status. |
| Templates with localization status. |
| Saved segments with subscriber counts. |
| Tags with usage counts. |
| Deliverability metrics and health status. |
| Field reference for every email block type. |
| Dashboard route templates and settings tabs. |
Example Prompts
Add john@example.com with tags "vip" and "developer", then put them on the beta list.Create a 4-email churn prevention sequence for users whose subscription expires soon. Leave it in draft mode.Create a segment for subscribers who bought Stripe product prod_pro at least 3 times.Draft a campaign about our new analytics dashboard, target the Pro users segment, and send a test to me.How did the last campaign perform compared with the one before it?Security
Use personal API keys, not shared team secrets.
Keys only access companies your Sequenzy user can access.
Revoke keys from Settings -> API Keys when access is no longer needed.
Keep client approval prompts enabled for sends, scheduling, deletes, and bulk changes.
Prefer draft workflows for campaigns and sequences, then review in Sequenzy before launch.
Troubleshooting
SEQUENZY_API_KEY environment variable is required
Set SEQUENZY_API_KEY in the MCP client config, or run:
npx @sequenzy/setupInvalid API Key
Create a new personal key in Settings -> API Keys, update your MCP config, and restart the client.
Missing API Key Scope
Call get_account and inspect apiKeyPermissions. Local connections should
open apiKeyPermissions.manageUrl, add the missing scope to the loaded key, and
retry without restarting. update_api_key can perform this only for company
keys that already hold api_keys:manage; edit personal keys on the account-level
API Keys page. Hosted OAuth connections can alternatively disconnect and
reauthorize with broader permissions. The tool error includes the exact scope or
scopes required.
Duplicate Resources
If a tool call would create a duplicate segment name or sending domain, the server returns a stable code, an agent-friendly description, a concrete resolution, and a docsUrl. For segments, call list_segments and reuse the existing segment ID or choose a different name. For websites, call list_websites; if the domain is not listed for the selected company, it belongs to another company or account and must be removed, reassigned, or replaced with a different sending domain.
Tools Do Not Appear
Confirm
npxis available in the environment the client uses.Restart the MCP client after editing config.
Check that the config is in the correct client-specific location.
Network or API URL Issues
The server uses https://api.sequenzy.com by default. If you override it, verify SEQUENZY_API_URL points at a reachable Sequenzy API base URL.
Development
bun install
bun test
bun run type-check
bun run buildMCP tool schemas must remain compatible with strict clients:
Tool
inputSchemaroots must be plaintype: "object"schemas.Do not publish
anyOfanywhere in tool schemas.Do not put
oneOf,allOf,enum, ornotat the root of a tool schema.Enforce conditional requirements in handlers and cover them with tests.
This standalone repository mirrors the MCP package maintained in the main Sequenzy monorepo. See AGENTS.md for sync rules.
License
MIT
Agent-native discovery
Sequenzy publishes machine-readable manifests for agent networks and A2A-style discovery:
Remote MCP endpoint:
https://api.sequenzy.com/v1/mcpAgent capability manifest:
agent-capability.jsonA2A-style agent card:
.well-known/agent-card.jsonOpenClaw/Moltbot skill metadata:
openclaw/skill.jsonOpenClaw/Moltbot operating guide:
openclaw/SKILL.md
These files describe Sequenzy as an authorized email automation capability for agents. They explicitly exclude scraping, spam, and unsolicited cold outreach use cases.
Workspace roles
Account-key access combines key scopes with your current workspace role. get_account reports blocked scopes in apiKeyPermissions.roleRestrictedScopes; canSendLive means at least one permitted delivery workflow is available, not that every send tool is allowed.
You can invite a marketer to manage subscribers, marketing campaigns and sequences without granting access to transactional mail, workspace settings, team or billing. Marketers choose existing sender/reply profiles. Transactional-backed campaign, A/B and sequence sources remain protected through previews, sharing, analytics and send history. Marketers and restricted members cannot receive billing access.
Available Tools
113 toolsadd_ab_test_variantAInspect
Add a variant to a draft campaign A/B test. Variants cannot be added after the test has started.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| abTestId | Yes | A/B test ID | |
| subject | Yes | Variant subject line. | |
| previewText | No | Variant preview text. | |
| blocks | No | Replacement Sequenzy email blocks. Use `styles` for per-block background, background opacity, text color, padding, border radius, border width, and border color. Top-level style aliases such as `backgroundColor`, `backgroundOpacity`, `borderColor`, `borderWidth`, and `borderRadius` are also accepted and saved under `styles`. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| abTest | No | The A/B test record returned by Sequenzy. |
| variant | No | The A/B test variant record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation with no destructive or open-world hints. The description adds the behavioral constraint about the test being in draft, which is beyond what annotations provide. It does not detail side effects or authentication, but the added context is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the main purpose and a critical constraint. Every word earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, 2 required, output schema exists), the description is adequate. It covers the main constraint but could mention validation rules or success confirmation. The presence of an output schema reduces the need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so each parameter is already clearly documented. The description does not add new meaning to the parameters beyond what the schema provides. A score of 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a variant'), the resource ('draft campaign A/B test'), and a key constraint ('variants cannot be added after the test has started'). It distinguishes itself from sibling tools like 'create_ab_test' and 'delete_ab_test_variant'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (while the test is in draft) and implies when not to use it (after the test has started). It does not provide explicit alternatives, but the constraint is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
add_subscriberCInspect
Add a new subscriber to your list
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID to add subscriber to. If not provided, uses the currently selected company. | |
| No | Subscriber email address | ||
| externalId | No | Customer-owned subscriber ID. Provide this with email when creating, or instead of email for an existing subscriber. | |
| attributes | No | Custom attributes (name, plan, etc.) | |
| tags | No | Tags to apply to the subscriber | |
| listIds | No | List IDs to add subscriber to | |
| status | No | Initial subscriber status: active, unsubscribed, or bounced. Defaults to active. | |
| optInMode | No | Consent mode: confirmed creates active immediately when consent is verified, double_opt_in sends a confirmation email before activation, and default obeys company double opt-in settings. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| subscriber | No | The subscriber record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so it's a write operation but not destructive. The description adds no behavioral context beyond 'Add.' It does not mention whether it handles duplicates, permissions, or side effects like triggering automation. For a creation tool, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence. It is concise and directly states the purpose. However, it could include more useful information without becoming verbose, so it earns a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, nested objects, output schema), the description is too minimal. It fails to mention that subscribers are added to lists, that custom attributes and tags are supported, or what the output schema contains. This leaves the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description ('Add a new subscriber to your list') does not add meaning beyond what the schema already provides for each parameter, such as how to use 'externalId' or 'optInMode'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a new subscriber to your list,' which specifies the verb (add) and resource (subscriber). However, 'your list' is ambiguous; the input schema includes 'listIds' indicating it can add to specific lists. It distinguishes from siblings like 'add_subscribers_to_list' which adds existing subscribers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'add_subscribers_to_list' or 'update_subscriber'. There is no mention of prerequisites, such as requiring a company ID, or when to use other subscription management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
add_subscribers_to_listAInspect
Bulk add existing or new subscribers to a subscriber list from an email array. Existing subscribers are added to the list without requiring a per-subscriber update call.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| listId | Yes | Subscriber list ID to add subscribers to. | |
| emails | Yes | Email addresses to add to the list. Maximum 500 per call. | |
| duplicateStrategy | No | Duplicate strategy for existing subscribers: skip, merge, or overwrite. Defaults to skip. | |
| enrollInSequences | No | Whether newly created subscribers should enroll in matching sequences. Defaults to false. | |
| optInMode | No | Consent mode for newly created subscribers: default, confirmed, or double_opt_in. Defaults to default. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| list | No | The list record returned by Sequenzy. |
| added | No | Number of subscribers added to the list. |
| skipped | No | Number of subscribers skipped. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-destructive write (readOnlyHint=false, destructiveHint=false). The description adds beyond annotations by clarifying the bulk add behavior and the handling of existing subscribers without separate calls. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose and add key behavioral detail. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters and an output schema. The description covers the core operation adequately, though it could mention handling of duplicates or opt-in mode, which are covered in schema. Reasonably complete given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description adds a note about existing subscribers but does not significantly enhance understanding beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'add', the resource 'subscribers to a subscriber list', and the scope 'bulk from an email array'. It distinguishes from sibling tools like add_subscriber (single) and remove_subscribers_from_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies batch efficiency by noting existing subscribers are added without per-subscriber update calls. However, it does not explicitly state when to use this over alternatives like add_subscriber, though the context of sibling tools makes the distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
add_websiteAInspect
Add a new sender website. Takes ~30 seconds to process.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| domain | Yes | The domain to add (e.g., example.com) |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| website | No | The sender website record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false and destructiveHint=false, indicating a non-read, non-destructive operation. The description adds a behavioral trait ('Takes ~30 seconds to process'), warning of latency. However, it does not disclose other important behaviors like potential failure reasons (e.g., domain already exists) or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences that convey the core purpose and a critical timing detail. No fluff or redundancy is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks context about prerequisites (e.g., domain ownership verification), possible outcomes (e.g., success/failure conditions), and the nature of the 'process' after submission. While an output schema exists and may document return values, the description should cover the overall workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its two parameters (companyId and domain). The tool description adds no additional semantic meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and resource ('a new sender website'), making the tool's purpose immediately obvious. Among siblings like 'check_website' and 'list_websites', it is unambiguously distinct as a creation operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides timing information ('Takes ~30 seconds') but offers no guidance on when to use this tool versus alternatives like 'check_website' or when not to use it. The usage context is purely implied by the verb 'Add'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
attach_product_fileAInspect
Attach a distributable file to a product, either by public URL or by uploading a local file (filePath, local MCP server only). After a purchase of the product, sequence emails can link to it with {{event.download.url}} and {{event.download.name}}.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| productId | Yes | Product ID from list_products, or your own productId for products pushed via upsert_products. | |
| url | No | Public http(s) URL of the file to deliver. Provide url or filePath, not both. | |
| filePath | No | Local path of a file to upload and attach (PDF, ePub, ZIP, image, audio, video, or text, up to 100MB). Only available when the MCP server runs locally on this machine. | |
| fileName | No | Display name for the file (e.g. guide.pdf). Used as {{event.download.name}}. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| product | No | The product record returned by Sequenzy. |
| delivery | No | The digital delivery file record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). Description adds that file becomes available in sequence emails after purchase. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. First sentence states action, second provides practical usage context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Handles core functionality well. Mentions file size/type constraints in schema, but description doesn't repeat them. Output schema exists but is not needed for completeness here. Missing maybe prerequisites (product existence) but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters. Description adds value by summarizing the two file source options and explaining fileName's role in email templates. Provides context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (attach file to product) and the two methods (URL or local upload). Distinguishes from sibling 'remove_product_file' by being the attach counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use (for attaching distributable files to products) and hints at alternatives (remove for removal). Notes local file limitation (local server only). No explicit when-not-to, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cancel_campaignADestructiveInspect
Cancel a campaign. Stops scheduled and sending campaigns (also works for paused and approval-pending ones). Remaining emails will not be sent and the campaign cannot be restarted - this cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| campaignId | Yes | Campaign ID to cancel. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| campaign | No | The campaign record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true, and the description adds specific irreversible behaviors: remaining emails will not be sent, campaign cannot be restarted. This provides useful extra context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with the purpose upfront, followed by details and irreversibility warning. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers all necessary information: what it does, which campaign states it affects, and that it's irreversible. Sibling tool context is available for comparison.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so no additional parameter details are necessary. The description does not elaborate on parameters, but the schema already documents them adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Cancel' with the resource 'campaign' and specifies the states it works on (scheduled, sending, paused, approval-pending). This distinguishes it from sibling tools like 'delete_campaign' and 'pause_campaign'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use the tool (for campaigns in multiple states) and mentions that the action cannot be undone, implying it should be used when permanent stop is intended. Does not explicitly contrast with 'pause_campaign' but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cancel_sequence_enrollmentsADestructiveInspect
Cancel active/waiting enrollments in one sequence. Provide sequenceId and exactly one target: subscriberId for one subscriber, or fieldValues to match stored entry event properties. For fieldValues, fieldPath is optional when the sequence has enrollmentFieldPath configured; otherwise provide a dot path such as order.id.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| sequenceId | Yes | Sequence ID whose enrollments should be cancelled. | |
| subscriberId | No | Subscriber ID to cancel in this sequence. Provide subscriberId or fieldValues, not both. | |
| fieldPath | No | Dot-path inside the token's stored entry event properties, such as order.id or event.id. Optional when the sequence has enrollmentFieldPath configured. | |
| fieldValues | No | Entry field values to match. Cancels all active/waiting enrollments in the sequence whose entry field value is in this list. Provide fieldValues or subscriberId, not both. | |
| dryRun | No | When true, returns matching enrollments without cancelling them. Field-value cancellation defaults to dryRun on the API unless explicitly false. | |
| reason | No | Optional cancellation reason stored on matched enrollment tokens. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| sequence | No | The sequence record returned by Sequenzy. |
| cancelled | No | Number of enrollments cancelled. |
| skipped | No | Number of enrollments skipped. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: dryRun behavior, fieldPath optionality, and that field-value cancellation defaults to dryRun. No contradictions with annotations (destructiveHint=true consistent with cancellation). Could mention that only active/waiting enrollments are affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all essential. No unnecessary words. Front-loaded with main action and targeting rules.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters (1 required), 100% schema coverage, and existing output schema, description covers targeting logic, optional fieldPath, dryRun, and reason parameter. No gaps for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema: explains relationship between subscriberId and fieldValues (exactly one target), and clarifies fieldPath optionality. Schema already covers 100% of parameters with descriptions, so incremental value is moderate but present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Cancel' and resource 'active/waiting enrollments in one sequence'. Distinguishes between two targeting methods (subscriberId vs fieldValues), differentiating from sibling tools like disable_sequence or enroll_subscribers_in_sequence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use subscriberId vs fieldValues, and that fieldPath is optional when sequence has enrollmentFieldPath configured. Mentions dryRun default behavior. Lacks explicit when-not-to-use or comparison with alternative tools like disable_sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cancel_team_invitationADestructiveInspect
Cancel a pending team invitation. Invitations that have already been accepted cannot be cancelled.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| invitationId | Yes | Invitation ID to cancel. Use list_team_members to find pending invitations. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| invitationId | No | Cancelled invitation ID. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive (destructiveHint=true), and the description adds that accepted invitations cannot be cancelled, clarifying the scope. This adds meaningful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two sentences that convey essential information without any unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, high schema coverage, and presence of an output schema (not shown), the description is largely complete. It could potentially mention the consequence (e.g., the invitation is removed), but the current version is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented in the schema. The description mentions using list_team_members to find invitation IDs, which aids usage but does not add new parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cancels a pending team invitation, using a specific verb and resource. It distinguishes from siblings like invite_team_member and list_team_members by focusing on cancellation of pending invitations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that only pending invitations can be cancelled and references list_team_members to find pending invitations. However, it does not explicitly state when to avoid using the tool (e.g., if the invitation is already accepted) beyond the note, which is implied but clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_websiteARead-onlyInspect
Check if a website has been processed and is ready to use
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| domain | Yes | The domain to check |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| website | No | The sender website record returned by Sequenzy. |
| ready | No | Whether the sender website is ready. |
| status | No | Current processing or verification status. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's statement about checking readiness is consistent and adds some context about processing status. However, no side effects or behavioral details beyond what annotations provide are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with minimal waste. The verb 'Check' is front-loaded, and the entire purpose is communicated efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema and annotations, the description is adequate but minimal. It does not explain return values or error conditions, but completeness is acceptable for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the input schema with 100% coverage. The description does not add any meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Check') and resource ('a website'), with a specific outcome ('has been processed and is ready to use'). It distinguishes this tool from siblings like 'add_website' and 'list_websites'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as after adding a website or before using it. The description lacks explicit contextual cues for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
connect_landing_page_domainAInspect
Connect a custom domain for published landing pages. Returns the DNS target and verification records.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| domain | Yes | Custom domain, for example pages.example.com. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| landingPage | No | The landing page record returned by Sequenzy. |
| domain | No | Connected landing page domain. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-destructive mutation. The description adds that DNS target and verification records are returned, which is helpful context. However, it does not disclose side effects like existing domain conflicts or verification steps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second specifies output. No unnecessary words, and information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are documented. The description mentions the prerequisite that landing pages must be published. It lacks coverage of failure conditions or domain pre-validation, but overall is sufficient for the agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (connect) and resource (custom domain for landing pages). Includes output details (DNS target, verification records), distinguishing it from sibling tools like update_landing_page_domain_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. While it implies the domain should be for published landing pages, it does not mention alternatives or prerequisites, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_ab_testAInspect
Create a campaign A/B test. Control variant A is created automatically from the campaign's current email; optionally provide extra variants. The campaign must be in draft or rejected status, and each campaign can only have one A/B test.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| campaignId | Yes | Draft campaign ID to create the A/B test for. | |
| name | No | Optional A/B test name. | |
| testPercentage | No | Percentage of the audience used for the test phase, from 5 to 50. Defaults to 20. | |
| testDurationMinutes | No | Test phase duration in minutes before the winner is selected, from 15 to 1440. Defaults to 240. | |
| winnerCriteria | No | Winner selection criteria. Defaults to open_rate. | |
| variants | No | Optional extra variants to create in addition to control variant A. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| abTest | No | The A/B test record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals key behaviors: automatic creation of control variant A, the status requirement, and the one-test-per-campaign limitation. Annotations provide no safety signals (readOnlyHint=false, destructiveHint=false), so the description carries the burden. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with three sentences, each adding essential information. It is front-loaded with the purpose and quickly covers constraints. No redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers preconditions (campaign status), constraints (one test per campaign), and the auto-creation of variant A. An output schema exists but is not shown; per rules, the description need not detail return values. It provides enough context for the agent to decide when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the role of the 'variants' parameter ('optionally provide extra variants') and the automatic control variant, which clarifies the overall flow. Default values are restated from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create a campaign A/B test.' It explains that control variant A is created automatically and extra variants are optional, which distinguishes it from sibling tools like 'add_ab_test_variant' that add variants to an existing test.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use: the campaign must be in draft or rejected status. It also notes the constraint that each campaign can only have one A/B test, implying not to use if a test already exists. While it doesn't explicitly list alternatives, the sibling context provides 'add_ab_test_variant' for adding variants later.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_api_keyAInspect
Create a new API key for a company. Use this when setting up Sequenzy integration in a project. The returned key should be saved to the project's .env file as SEQUENZY_API_KEY. The key can only be retrieved once at creation time.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | Yes | Company ID to create the key for | |
| name | No | Optional name for the API key (e.g., 'Production', 'Development') |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| apiKey | No | Newly created API key. This secret is returned only once. |
| key | No | Newly created API key if the API response uses the short key field. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses a critical behavioral trait: 'The key can only be retrieved once at creation time,' which is beyond what annotations provide. Annotations indicate mutation (readOnlyHint=false) and non-destructive, so description adds important context about key availability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each adding value: purpose, usage context, storage instruction, and one-time retrieval warning. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given annotations and output schema presence, the description fully covers the creation action, appropriate usage, and a critical constraint (one-time retrieval). It is sufficient for an agent to correctly invoke and handle the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add additional meaning beyond schema. The optional name parameter is noted but no further constraints or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Name and description clearly state the tool creates an API key for a company, a unique resource among siblings. The verb 'create' with specific resource 'API key' leaves no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use (setting up Sequenzy integration in a project) and provides post-creation action (save to .env). Does not mention alternatives, but the context is sufficient for this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_audience_syncAInspect
Push a segment to a Meta custom audience and keep it synced on a schedule. Provide segmentId for an existing segment OR predefinedSegmentId for a ready-made template (for example "zero-ltv", "no-purchase-1y", "recent-buyers", "high-spenders-ecom", "non-buyers", "engaged") - the template segment is created automatically on first use. The first upload runs immediately. Note: audiences are add-only; subscribers who later leave the segment stay in the Meta audience.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| segmentId | No | Existing segment ID to sync. Mutually exclusive with `predefinedSegmentId`. | |
| predefinedSegmentId | No | Predefined segment template ID (for example "zero-ltv", "no-purchase-1y", "recent-buyers"). The segment is created automatically if it does not exist. Mutually exclusive with `segmentId`. | |
| adAccountId | Yes | Meta ad account ID (act_...) from `list_ad_accounts`. | |
| audienceName | Yes | Name for the custom audience in Meta Ads Manager. | |
| frequency | No | How often to re-upload the segment. Default: daily. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| audienceSync | No | The audience sync record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses key behaviors: automatic template creation on first use, immediate first upload, and add-only nature (subscribers leaving the segment stay in the audience). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four concise sentences with no wasted words. It starts with the primary action and then provides necessary details in a logical order: inputs, execution timing, and behavioral limitation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, output schema exists), the description covers core behavior and limitations. It does not explain error handling or rate limits, but sibling tools cover management (update_audience_sync, delete_audience_sync), making it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining mutual exclusivity of segmentId and predefinedSegmentId, providing example predefinedSegmentId values, and noting adAccountId source from list_ad_accounts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Push a segment to a Meta custom audience and keep it synced on a schedule.' It distinguishes from siblings like sync_audience_now (one-time sync) and delete_audience_sync by focusing on ongoing synchronization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: options for existing segment or predefined template, first upload runs immediately, and add-only behavior. It lacks explicit when-not-to-use guidance, but the context is sufficient for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_campaignBInspect
Create a new campaign (as draft)
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID to create the campaign in. If not provided, uses the currently selected company. | |
| name | Yes | Campaign name | |
| subject | No | Email subject line. Optional when `prompt` is provided because the generated subject will be used. | |
| trackingCode | No | Optional campaign tracking code for UTM templates. Use only when explicitly requested. | |
| html | No | Email HTML content. Mutually exclusive with `blocks`. | |
| blocks | No | Sequenzy email blocks. Use `styles` for per-block background, background opacity, text color, padding, border radius, border width, and border color. Top-level style aliases such as `backgroundColor`, `backgroundOpacity`, `borderColor`, `borderWidth`, and `borderRadius` are also accepted and saved under `styles`. Use this for editor-compatible content, including conditional and repeat blocks. Repeat blocks use { type: 'repeat', source: 'items', itemAlias: 'item', children: [...] }. | |
| prompt | No | Generate campaign blocks from a prompt. Mutually exclusive with `html`, `blocks`, and `templateId`. | |
| style | No | Prompt generation style: minimal, branded, promotional. Only used with `prompt`. | |
| tone | No | Prompt generation tone: professional, casual, friendly. Only used with `prompt`. | |
| templateId | No | Use a template instead of html | |
| segmentId | No | Target segment ID | |
| campaignData | No | Optional campaign-scoped JSON data for repeat blocks and personalization. | |
| computedLists | No | Optional computed list definitions derived from campaignData at send time. | |
| labels | No | Optional label names to assign. Missing labels are created automatically. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| campaign | No | The campaign record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-readOnly and non-destructive. The description adds the 'draft' status, which is a behavioral detail beyond annotations. However, it does not disclose other traits such as permissions needed, rate limits, or that the campaign is not immediately sent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the action. However, given the tool's complexity, a slightly longer description could improve completeness without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and detailed parameter descriptions, the tool description is only one line. It does not explain what happens after creation, how to finalize the campaign, or handle errors. For a tool with many parameters and siblings, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all 14 parameters. The tool description adds no additional semantics beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new campaign, with the qualifier '(as draft)' distinguishing it from update, duplicate, and other campaign operations. It is specific about verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like duplicate_campaign or update_campaign. The description does not mention prerequisites, exclusions, or typical workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_companyAInspect
Create a new company/brand. This will parse your website to extract brand information. The tool polls every 20 seconds until the company is fully processed (typically 30-60 seconds).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Company name (optional, will be extracted from domain if not provided) | |
| domain | Yes | The company's website domain (e.g., example.com) |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| company | No | The company record returned by Sequenzy. |
| autoSelected | No | Whether the new company was selected for subsequent MCP calls. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations: website parsing and polling behavior (20 seconds, 30-60 seconds processing). Annotations don't contradict this; they are neutral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences clearly state purpose and key behavioral trait (polling). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema existing, the description doesn't need to explain return values. It covers creation and polling behavior, which is complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for both parameters. The description adds that the name parameter is optional and can be extracted from the domain, which adds meaning beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new company/brand by parsing a website, which distinguishes it from other create tools like create_campaign or create_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions polling every 20 seconds and typical processing time, providing some context, but does not specify when not to use this tool or suggest alternatives like select_company for existing companies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_landing_pageAInspect
Create a draft landing page. Provide content for an exact page, or a template for generated starter content.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID to create the landing page in. If not provided, uses the currently selected company. | |
| name | No | Landing page name. Optional; defaults to a template-specific name. | |
| slug | No | Optional URL slug. It will be normalized and made unique within the company. | |
| template | No | Optional template key for default content, such as from-scratch, waitlist, lead-magnet, launch, demo-request, webinar, newsletter, product-hunt, pricing-offer, agency-lead-gen, or feature-announcement. | |
| content | No | Complete Sequenzy landing page content JSON. Use this when replacing the page structure. The content must be the editor-compatible landing page schema with version, template, seo, theme, and blocks. Landing pages must include exactly one footer block and at most one form block. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| landingPage | No | The landing page record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it's not read-only, and the description adds that it creates a draft. No contradiction; it adequately discloses the creation behavior without needing to detail every side effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given good schema coverage and an output schema, the description covers the main purpose and modes. It could mention the output schema, but that is already provided separately, making it fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description's addition of 'exact page' vs 'starter content' is useful but minimal. Baseline 3 is appropriate as the schema already explains parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a draft landing page' and distinguishes two modes: exact content or template-based. This differentiates it from sibling tools like publish_landing_page or update_landing_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use content vs template but does not explicitly state when not to use this tool or alternatives. No prerequisites or use cases are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_listBInspect
Create a new subscriber list
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID to create the list in. If not provided, uses the currently selected company. | |
| name | Yes | List name | |
| description | No | List description |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| list | No | The list record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (modifies state) and destructiveHint=false (non-destructive). The description adds no behavioral details beyond that, such as whether list names must be unique, what happens to existing lists, or that companyId defaults to current company.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundant words. However, the extreme brevity sacrifices useful context that could be added without losing conciseness, such as default behavior for companyId.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and simple parameter set (3 params, 1 required), the description is mostly adequate. It lacks mention of the optional companyId defaulting behavior, but the schema covers this. Overall, it provides the essential information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description does not add any additional meaning beyond the schema, such as format requirements or examples. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a new subscriber list' using a specific verb (create) and resource (subscriber list). The tool name and description align perfectly, and it is distinct from sibling tools like update_list, delete_list, and other create_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For example, there is also add_subscribers_to_list for adding subscribers to an existing list, but no differentiation is provided. No context on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_segmentAInspect
Create a new segment from explicit filter rules. Use filters plus filterJoinOperator for flat legacy rules, or root for nested AND/OR groups such as { "kind": "group", "joinOperator": "and", "children": [{ "kind": "filter", "field": "attribute", "operator": "gte", "value": "mrr:50" }, { "kind": "group", "joinOperator": "or", "children": [{ "kind": "filter", "field": "tag", "operator": "contains", "value": "vip" }, { "kind": "filter", "field": "event", "operator": "is_not", "value": "saas.purchase:30d" }] }] }. Supports event and segment fields, Stripe product purchase/current/trial/date filters, and campaign-specific engagement filters.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID to create the segment in. If not provided, uses the currently selected company. | |
| name | Yes | Segment name | |
| filterJoinOperator | No | How top-level filters combine. Use `"and"` to require every filter or `"or"` to match any filter. | |
| filters | No | Array of segment filters. Example custom attribute empty check: [{"id":"filter-1","field":"attribute","operator":"is_empty","value":"last_logged_in:"}]. Example Stripe purchase filter: [{"id":"filter-1","field":"stripeProduct","operator":"is","value":"prod_123"}]. Example threshold filter: [{"id":"filter-1","field":"stripeProduct","operator":"at_least","value":"prod_123:3"}]. Example commerce product purchase filter (value is provider:productId since product ids are provider-scoped): [{"id":"filter-1","field":"commerceProduct","operator":"is","value":"api:prod-starter-kit"}]. Example repeat-buyer filter: [{"id":"filter-1","field":"commerceProduct","operator":"at_least","value":"shopify:42:2"}]. Example trial cancellation filter: [{"id":"filter-1","field":"stripeTrialProduct","operator":"is","value":"prod_123:is_canceled"}]. Example trial end filter: [{"id":"filter-1","field":"stripeTrialProduct","operator":"is","value":"prod_123:end_at:2026-05-26"}]. Example campaign-specific engagement combo: [{"id":"filter-1","field":"emailBounced","operator":"is","value":"campaign:cmp_abc"},{"id":"filter-2","field":"emailBounced","operator":"is_not","value":"campaign:cmp_xyz"}]. Combine them with `filterJoinOperator: "or"` to match any filter. | |
| root | No | Nested filter root. Mutually exclusive with `filters` and `filterJoinOperator`. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| segment | No | The segment record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only and non-destructive, which aligns with creation. The description adds examples and filter details but does not disclose side effects or permissions. Behavioral context beyond creation is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and then provides structured examples. It is verbose but every sentence adds information; could be slightly tighter but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, nested objects, multiple filter types), the description thoroughly covers usage, including mutual exclusivity of parameter groups, field-specific operators, and numerous real-world examples. An output schema exists, so return values need not be explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds substantial value by explaining the relationship between filters, filterJoinOperator, and root, providing detailed examples for each field type (event, segment, Stripe, commerce, engagement). This goes well beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new segment using explicit filter rules, distinguishing it from update_segment and delete_segment. It specifies the two approaches (flat vs nested), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use the tool (with filters or root) but does not explicitly state when to choose this over alternatives like update_segment. It provides context but lacks direct usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_sequenceAInspect
Create a new email sequence. Provide either a goal for AI generation or explicit steps. Explicit steps can include email content and create_discount actions; emails after a discount action can use merge tags such as {{discount.code}} and {{discount.percentOff}}. For AI-generated sequences, the tool polls until emails are generated (typically 30-60 seconds).
IMPORTANT GUIDELINES:
NEVER ENABLE SEQUENCES AUTOMATICALLY:
Sequences are created in DRAFT/PAUSED state
NEVER call enable_sequence unless the user EXPLICITLY asks to enable/activate
The user must review the AI-generated content before going live
Sequences send real emails to real people - enabling without review is dangerous
KEEP IT SIMPLE: Only suggest sequences that are straightforward to implement:
Prefer 3-5 emails per sequence (not 10+)
Use simple, achievable triggers that the app already tracks
Avoid complex multi-step sequences that require extensive app changes
MATCH THE BUSINESS MODEL:
If the app has NO trial period, do NOT create trial-related sequences
If the app is FREE (no paid plans), do NOT create upgrade/pricing sequences
If the app is a one-time purchase (not SaaS), do NOT create subscription sequences
Match sequences to events and features that ACTUALLY exist in the app
EVENT TRACKING: When you use a custom event (not a built-in event), you MUST:
The event will be auto-created in Sequenzy
The response includes eventTrackingCode showing exactly what code to add to the app
Tell the user what specific user action should trigger each event
Be specific: "Track 'project.created' when user creates their first project"
MATCHING FIELD ENROLLMENT:
Use enrollmentMode: "matching_field" only with trigger: "event_received".
Use enrollmentFieldPath for custom event payload fields, for example "order.id" or "product.providerVariantId".
This blocks duplicate active runs for the same subscriber + field value, but still allows separate active runs for different products, variants, orders, or other event-scoped objects.
Leave enrollmentFieldPath empty for Shopify back-in-stock and replenishment events so Sequenzy uses its built-in product/variant matching defaults.
SEQUENCE TRIGGER RECIPES - USE THESE EXACT CONFIGURATIONS:
TRIAL CONVERSION:
trigger: tag_added, tagName: "trial"
Auto-stops when: user gets "customer" tag
Goal: Convert trial users to paying customers
PAYMENT RECOVERY / DUNNING:
trigger: tag_added, tagName: "past-due"
Auto-stops when: user no longer has "past-due" tag (they paid)
Goal: Recover failed payments before churn
CANCELLATION RECOVERY / WIN-BACK:
trigger: tag_added, tagName: "cancelled"
Auto-stops when: user gets "customer" tag again
Goal: Win back users who cancelled
CHURN RECOVERY:
trigger: tag_added, tagName: "churned"
Auto-stops when: user gets "customer" tag again
Goal: Re-engage churned users
UPGRADE / UPSELL:
trigger: tag_added, tagName: "customer"
Auto-stops when: user triggers "saas.upgrade" event
Goal: Encourage customers to upgrade to higher plans
ONBOARDING:
trigger: event_received, eventName: "signup.completed"
Auto-stops when: "onboarding.completed" event fires
Goal: Guide new users through product setup
PRODUCT / ORDER-SCOPED EVENT SEQUENCE:
trigger: event_received, eventName: "ecommerce.order_placed"
enrollmentMode: "matching_field", enrollmentFieldPath: "order.id"
Goal: Run one active sequence per specific order without duplicate active runs for the same order
SINGLE-PRODUCT PURCHASE SEQUENCE (e.g. digital product delivery):
trigger: event_received, eventName: "ecommerce.order_placed", propertyFilters: [{ path: "lineItems[].providerProductId", operator: "equals", value: "" }]
For Stripe purchases use eventName: "saas.purchase" with propertyFilters: [{ path: "productIds", operator: "equals", value: "prod_XXX" }]
To match any of several products, use operator "one_of" with an array value: [{ path: "lineItems[].providerProductId", operator: "one_of", value: ["", ""] }]
Goal: Only start the sequence when a specific product was purchased
WELCOME SERIES:
trigger: contact_added (optionally with listId)
No auto-stop (runs to completion)
Goal: Introduce new subscribers to your brand
SEGMENT ENTRY:
trigger: segment_entered, segmentId: "segment-id"
No auto-stop by default
Goal: Start a sequence when contacts newly qualify for a saved segment
RE-ENGAGEMENT:
trigger: inactivity, eventName: "login", inactiveDays: 14
Auto-stops when: user logs in again
Goal: Bring back inactive users
IMPORTANT - PAYMENT PROVIDER INTEGRATION: If the app uses Stripe, Polar, Paddle, Dodo, or Creem - tell the user to connect it in Sequenzy dashboard (Settings → Integrations). Once connected, the native integration automatically handles:
All saas.* events (purchase, cancelled, churn, payment_failed, etc.)
All status tags (customer, trial, cancelled, churned, past-due, etc.)
Subscription attributes (MRR, plan name, billing interval)
Only offer manual tracking if the user explicitly asks for it.
DISCOUNT ACTION STEPS:
Use explicit steps with { "type": "create_discount", "discount": { "discountType": "percent", "percentOff": 20, "duration": "once", "appliesToAllPlans": true, "maxRedemptions": 1, "codePrefix": "SAVE" } }.
Optionally add "lockToSubscriber": true for Stripe discounts only when the subscriber is expected to have a matching Stripe customer.
Discount actions currently require Stripe; connect Stripe before enabling the sequence.
Put the discount action before the email that references it with {{discount.code}}.
CUSTOM EVENTS (these DO require manual tracking):
onboarding.completed - User finished setup wizard
feature.used - User engaged with a key feature
project.created - User created their first project
team.invited - User invited a team member
milestone.reached - User hit a usage milestone For custom events, provide the tracking code snippet from get_integration_guide.
BUILT-IN TAGS (auto-applied by payment integrations):
"customer" = PAYING customer with active subscription (use this for upgrade sequences, customer-only content)
"trial" = Currently on free trial (use for trial conversion sequences)
"lead" = Signed up but never paid (use for nurture sequences)
"cancelled" = Cancelled but still has access until period ends (use for win-back sequences)
"churned" = Subscription ended, no longer paying (use for re-engagement)
"past-due" = Payment failed, at risk of churning (use for dunning/recovery sequences)
"refunded" = Received a refund
"saas.monthly" / "saas.yearly" = Billing interval
BUILT-IN EVENTS (auto-fired by payment integrations):
saas.purchase, saas.purchase.monthly, saas.purchase.yearly - New subscription
saas.cancelled - User cancelled (still has access)
saas.churn - Subscription ended
saas.payment_failed - Card declined/expired
saas.upgrade, saas.downgrade - Plan changes
saas.trial_started, saas.trial_will_end, saas.trial_ended - Trial lifecycle
saas.refund - Refund issued
OTHER BUILT-IN EVENTS:
email.opened, email.clicked, email.replied, email.bounced, email.unsubscribed
contact.subscribed, contact.unsubscribed
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID to create the sequence in. If not provided, uses the currently selected company. | |
| name | Yes | Sequence name (e.g., 'User Onboarding', 'Welcome Series') | |
| trigger | Yes | Trigger type: 'contact_added' (when added to a list), 'tag_added' (when tag is applied), 'segment_entered' (when a contact newly enters a saved segment), 'event_received' (when custom event fires), 'inactivity' (when subscriber hasn't performed an event for X days), 'frequency' (when subscriber performs event X times in Y days) | |
| listId | No | List ID to trigger on (for contact_added trigger). If not provided, triggers on any list. | |
| tagName | No | Tag name to trigger on (required for tag_added trigger) | |
| segmentId | No | Segment ID to trigger on (required for segment_entered trigger). Use list_segments first to choose a saved segment. | |
| eventName | No | Event name to trigger on (required for event_received, inactivity, and frequency triggers) | |
| propertyFilters | No | Optional event property filters for event_received triggers. The sequence only starts when the triggering event's properties match ALL filters. Use a dot-path into the event properties; use [] to match inside arrays. Examples: scope a purchase sequence to one product with { path: 'lineItems[].providerProductId', operator: 'equals', value: 'prod_123' } (ecommerce.order_placed) or { path: 'productIds', operator: 'equals', value: 'prod_123' } (saas.purchase); to match any of several products use { path: 'lineItems[].providerProductId', operator: 'one_of', value: ['prod_123', 'prod_456'] }. Max 10 filters. | |
| inactiveDays | No | Number of days of inactivity (required for inactivity trigger, must be >= 1) | |
| inactivityBaseline | No | When to start counting inactivity for subscribers who never had the event. Defaults to sequence_created_at. | |
| minCount | No | Minimum event count (required for frequency trigger, must be >= 1) | |
| timeWindowDays | No | Time window in days for frequency trigger (required for frequency trigger, must be >= 1) | |
| emailCount | No | Number of emails in the sequence (default: 5, max: 10) | |
| goal | No | What this sequence should accomplish for AI generation. Be specific to the app's actual features and user journey. Avoid generic goals that don't match the app's business model. | |
| enrollmentMode | No | Sequence re-entry mode. Use 'matching_field' only for event_received triggers when duplicate active runs should be blocked per event field value. | |
| enrollmentFieldPath | No | Dot-path event property used by enrollmentMode='matching_field', such as 'order.id' or 'product.providerVariantId'. Leave omitted for Shopify back-in-stock/replenishment product-variant defaults. | |
| stopCondition | No | Optional explicit auto-stop condition. Use { type: 'has_tag', value: 'customer' } to end the sequence when a subscriber gets a tag, { type: 'does_not_have_tag', value: 'trial' } when a tag is removed, { type: 'removed_from_list', value: 'list_123' } when they leave a list, { type: 'event_received', value: 'onboarding.completed' } when an event is tracked, or { type: 'none', value: null } for no auto-stop. | |
| steps | No | Explicit sequence steps. Omit type for email steps, or use type: 'create_discount' for a Stripe discount action. Later email steps can reference the most recent discount with {{discount.code}}, {{discount.percentOff}}, {{discount.amountOff}}, and {{discount.expiresAt}}. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| sequence | No | The sequence record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, indicating a non-destructive write operation. The description adds extensive behavioral context: sequences are created in draft/paused state, discount actions require Stripe, AI generation polls for 30-60 seconds, and sequences send real emails requiring review before going live. It also explains the auto-stop behavior for various triggers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long but well-structured with headings and bullet points. However, it contains some redundancy with the schema (e.g., discount action fields are described both in the description and schema). The critical information is front-loaded, but the length could be slightly reduced without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all aspects: creation, triggers, steps, discounts, business model constraints, event tracking, built-in tags/events, and integration guidelines. It also mentions out-of-scope items like 'Only offer manual tracking if the user explicitly asks for it.' The presence of an output schema further reduces the burden, but the description already provides near-complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema coverage is 100%, but the description adds immense value beyond the schema. It provides complete trigger recipes (e.g., TAG_ADDED with tagName 'trial' and stop condition), detailed discount action configuration with examples, enrollment mode explanations with field paths, and property filter patterns. The description makes every parameter actionable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new email sequence' and explains two distinct modes (AI generation with goal or explicit steps with email and discount actions). It differentiates from sibling tools like generate_sequence and enable_sequence by explicitly stating that sequences start in draft/paused state and should not be enabled automatically unless the user asks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Extremely detailed guidelines are provided: never enable automatically, keep sequences simple, match business model, use specific trigger recipes with exact configurations, and detailed instructions for event tracking and custom events. It explicitly tells when NOT to use certain features (e.g., not to create trial sequences if the app has no trial).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_tagAInspect
Create a new tag definition. The name is normalized to lowercase with hyphens (e.g. 'VIP Customer' becomes 'vip-customer'). Color defaults to gray.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| name | Yes | Tag name. Normalized to lowercase with hyphens. | |
| color | No | Tag color. Defaults to gray. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| tag | No | The tag record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-destructive write operation. The description adds key behavioral details: name normalization and color default. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no filler, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (context signal), the description adequately covers creation semantics. Return format is handled by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds meaningful detail beyond the schema, such as the normalization example and default color behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new tag definition' clearly states the action and resource, distinguishing it from sibling tools like update_tag and delete_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating new tags, but does not explicitly state when to use alternatives. The normalization example provides some context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_templateAInspect
Create a new email template
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| name | Yes | Template name | |
| subject | Yes | Email subject line | |
| html | No | Email HTML content. Mutually exclusive with `blocks`. | |
| blocks | No | Sequenzy email blocks. Use `styles` for per-block background, background opacity, text color, padding, border radius, border width, and border color. Top-level style aliases such as `backgroundColor`, `backgroundOpacity`, `borderColor`, `borderWidth`, and `borderRadius` are also accepted and saved under `styles`. Use this for editor-compatible content, including conditional and repeat blocks. Repeat blocks use { type: 'repeat', source: 'items', itemAlias: 'item', children: [...] }. | |
| labels | No | Optional label names to assign. Missing labels are created automatically. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| template | No | The email template record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description does not add any behavioral details beyond the annotations, such as side effects, permissions, or return behavior. It is adequate but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's purpose. It is front-loaded with the verb and resource, with no extraneous words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 params, 2 required), the presence of full schema descriptions and an output schema, the description is sufficient. It could optionally mention the company context or the html/blocks distinction, but the schema handles that adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides detailed descriptions for all 6 parameters (100% coverage). The description does not add any extra meaning or context about parameters beyond what the schema already states. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create' and the resource 'new email template'. It is specific and distinct from sibling tools like update_template, delete_template, and list_templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., create_transactional_email). It lacks context about prerequisites, when not to use, or what to consider before creating a template.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_transactional_emailAInspect
Create a saved transactional email template with an API slug. Provide prompt to generate the email with AI, or provide either html or Sequenzy blocks for the email body.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| name | Yes | Transactional email name. | |
| slug | No | Optional API slug used when sending by slug, for example `password-reset`. If omitted, Sequenzy generates one from the name. | |
| subject | No | Email subject line. Optional when `prompt` is provided because the generated subject will be used. | |
| previewText | No | Email preview text. | |
| html | No | Email HTML content. Mutually exclusive with `blocks`. | |
| blocks | No | Sequenzy email blocks. Use `styles` for per-block background, background opacity, text color, padding, border radius, border width, and border color. Top-level style aliases such as `backgroundColor`, `backgroundOpacity`, `borderColor`, `borderWidth`, and `borderRadius` are also accepted and saved under `styles`. Use this for editor-compatible content, including conditional and repeat blocks. Repeat blocks use { type: 'repeat', source: 'items', itemAlias: 'item', children: [...] }. Mutually exclusive with `html`. | |
| prompt | No | Generate transactional email blocks from a prompt. Mutually exclusive with `html` and `blocks`. | |
| style | No | Prompt generation style: minimal, branded, promotional. Only used with `prompt`. | |
| tone | No | Prompt generation tone: professional, casual, friendly. Only used with `prompt`. | |
| enabled | No | Whether this transactional email can be sent immediately. Defaults to true. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| transactional | No | The transactional email record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, indicating no special behaviors. The description adds that the tool saves a template and offers AI generation, but does not disclose side effects (e.g., uniqueness of slugs, idempotency) or permissions needed. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the main purpose and immediately adding key usage options. No superfluous words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high schema coverage and presence of an output schema, the description is fairly complete. It clarifies the key content creation methods. Minor omission: it implies slug is required ('with an API slug') while schema marks it optional. Still, it provides enough context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description summarizes mutual exclusivity already present in the schema, adding minimal value. Baseline 3 is appropriate as the schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a saved transactional email template with an API slug, using specific verbs ('Create') and resources. It distinguishes from sibling tools like 'create_template' by specifying 'transactional email' and 'API slug'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the three content methods (prompt, html, blocks) but does not provide explicit guidance on when to use this tool vs alternatives like 'create_template' or 'create_campaign'. Usage context is implied by the tool name and resource type but lacks explicit 'when to use' or 'alternatives' statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_webhookAInspect
Create an outbound webhook endpoint. IMPORTANT: the response includes a signingSecret that is returned only once - show it to the user immediately so they can store it and verify webhook signatures. If events is omitted, a default set of event types is subscribed.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| name | Yes | Webhook endpoint name. | |
| url | Yes | HTTPS URL that will receive webhook events. | |
| events | No | Event types to subscribe to. If omitted, a default set is used. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| webhook | No | The outbound webhook record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses critical behavioral trait: the signingSecret is returned only once, requiring immediate attention. This adds value beyond annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three sentences with no wasted words. First sentence states purpose, second adds critical note, third explains optional parameter behavior. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers creation, secret handling, and default events. Output schema exists, so return values are documented elsewhere. For a simple creation tool with 4 parameters, this is sufficiently complete, though it lacks mention of idempotency or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3. Description adds the behavior of the optional events parameter: if omitted, a default set is subscribed. This is additional useful semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create an outbound webhook endpoint', using a specific verb and resource. It distinguishes itself from sibling tools like list_webhooks, delete_webhook, update_webhook, and test_webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides important usage guidance: the signingSecret is returned only once and should be shown to the user immediately. Also notes that omitting events subscribes default event types. However, it does not explicitly state when to use this tool versus alternatives like update_webhook.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_ab_testADestructiveInspect
Permanently delete a campaign A/B test and all of its variants. This cannot be undone. Running tests (testing or winner_selected) cannot be deleted, and the linked campaign must be in draft or rejected status.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| abTestId | Yes | A/B test ID to delete. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| abTestId | No | Deleted A/B test ID. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosure goes beyond annotations: notes permanence ('cannot be undone'), deletion of variants, and status constraints. Annotations already indicate destructiveHint=true, but description adds critical preconditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. Front-loaded with action and consequence, followed by constraints. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and annotations cover destructiveness, the description fully addresses behavior, constraints, and consequences. No gaps for a deletion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description adds no extra semantic value beyond the schema; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Permanently delete a campaign A/B test and all of its variants' – specific verb, resource, and scope. Clearly distinguishes from sibling tools like delete_ab_test_variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit conditions: 'Running tests (testing or winner_selected) cannot be deleted, and the linked campaign must be in draft or rejected status.' No alternatives mentioned but sufficiently clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_ab_test_variantADestructiveInspect
Permanently delete a variant from a draft campaign A/B test. This cannot be undone. Variant A is the control and cannot be deleted, and the test must keep at least the minimum number of variants. Variants cannot be removed after the test has started.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| abTestId | Yes | A/B test ID | |
| variantId | Yes | A/B test variant ID to delete. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| abTest | No | The A/B test record returned by Sequenzy. |
| variantId | No | Deleted A/B test variant ID. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant behavioral context beyond annotations: irreversibility, control variant restriction, minimum variants requirement, and timing constraint. Annotations already indicate destructiveness, so this is complementary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no redundancy: first sentence states action and irreversibility, subsequent sentences list constraints efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given annotations and output schema (exists), the description covers all essential behavioral aspects and constraints for a deletion tool. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters (100% coverage). Description does not add extra parameter-level details beyond what the schema provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('permanently delete') and resource ('variant from a draft campaign A/B test'). Distinguishes from siblings like 'delete_ab_test' and 'update_ab_test_variant'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit constraints: control variant cannot be deleted, minimum variant count must be maintained, and cannot delete after test started. Lacks explicit mention of alternative tools, but context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_audience_syncADestructiveInspect
Remove an audience sync mapping. The Meta audience itself is kept (running ads are not disrupted) - only future syncs stop.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| syncId | Yes | Audience sync ID to remove. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| audienceSyncId | No | Deleted audience sync ID. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the destructiveHint annotation by stating what is NOT destroyed (the Meta audience and running ads). This clarifies the scope of destruction. Missing details on authorization or immediacy, but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with the action and key clarification. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (not shown but present), return values are covered. The description covers the main effect and key nuance. Minor missing details about side effects or sequencing, but complete enough for a delete tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add new meaning to the parameters beyond what the schema already provides (e.g., syncId as the audience sync ID to remove).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes an audience sync mapping, distinguishing it from related tools like 'sync_audience_now' and 'update_audience_sync'. It specifies that the Meta audience is kept, preventing confusion with a full audience delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to stop future syncs without disrupting running ads) and implicitly when not to use it (if you want to delete the audience). It provides context but does not explicitly list alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_campaignADestructiveInspect
Permanently delete a campaign. This cannot be undone. Sending, scheduled, or paused campaigns must be cancelled with cancel_campaign first.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| campaignId | Yes | Campaign ID to delete. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| campaignId | No | Deleted campaign ID. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, but the description adds critical context: 'This cannot be undone' and the prerequisite to cancel active campaigns first. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that front-load the purpose and include essential precondition. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool, 2 parameters, existing output schema, and annotations, the description fully covers behavior, prerequisites, and irreversibility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage for both parameters (companyId, campaignId). The description adds no extra meaning beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('permanently delete') and the resource ('a campaign'). It distinguishes from sibling delete tools by emphasizing permanence and linking to the related cancel_campaign tool for active campaigns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (to permanently delete) and when not (sending, scheduled, or paused campaigns must be cancelled first). Provides a specific alternative: cancel_campaign.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_landing_pageCDestructiveInspect
Delete a landing page
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| landingPageId | Yes | Landing page ID. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| landingPageId | No | Deleted landing page ID. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds no additional behavioral context such as permanence, irreversibility, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Efficient but could include a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive action, the description should mention permanence or confirmation. It also does not leverage the existing output schema. Incomplete for safe decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, providing parameter details (companyId optional, landingPageId required). The description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'delete a landing page' with a specific verb and resource. It effectively distinguishes from sibling tools like create, update, publish, unpublish, get, list, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., unpublish vs delete), nor prerequisites or caveats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_listADestructiveInspect
Permanently delete a subscriber list and remove all of its memberships. Subscribers themselves are kept. This cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| listId | Yes | Subscriber list ID to delete. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| listId | No | Deleted list ID. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description expands on annotations (destructiveHint=true) by explaining the action is permanent and cannot be undone. It also mentions that subscribers are kept and memberships are removed, providing useful behavioral context beyond what annotations alone give.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, clear and concise. No unnecessary words. Could potentially be more structured (e.g., bullet points), but effective and front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values don't need explanation. The description covers the main behavioral aspects (deletion, permanence, membership removal) for a simple destructive tool. Missing details on permissions or side effects, but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds general context about permanence and membership removal but does not provide additional detail beyond what's in the schema for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool permanently deletes a subscriber list and removes its memberships, distinguishing it from other delete tools like delete_segment or delete_campaign. The verb 'delete' and resource 'subscriber list' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies caution ('cannot be undone') but does not explicitly state when to use this tool over alternatives (e.g., update_list or delete_segment). No guidance on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_productADestructiveInspect
Delete a product previously pushed via upsert_products (Commerce API products only), identified by your productId.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| productId | Yes | Your productId used when upserting the product. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| productId | No | Deleted product ID. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds context that deletion is limited to Commerce API products and uses the productId from upsert. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the verb and resource, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 params, one optional), the description covers the core action and constraints. Output schema exists, so return values need not be described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully documented. The description mentions 'identified by your productId' but adds no new detail beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete'), the resource ('product'), and the specific context ('previously pushed via upsert_products', 'Commerce API products only'). It distinguishes this from sibling tools like sync_products and other delete_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: only for products created via upsert_products and only for Commerce API products. It does not explicitly list alternatives but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_segmentADestructiveInspect
Permanently delete a segment. This cannot be undone. Subscribers are not affected.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| segmentId | Yes | Segment ID to delete. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| segmentId | No | Deleted segment ID. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds valuable behavioral context beyond annotations: confirms permanence and states no subscriber impact. Annotations already mark destructive hint true, but description clarifies the scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no unnecessary words. Critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key behavioral aspects (permanence, no subscriber effect) and output schema exists, so return values are not needed. Missing prerequisites like required permissions, but still effective for a deletion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are well-described in the schema; the description adds no additional parameter-level detail, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (permanently delete) and resource (segment), and distinguishes from other delete tools by specifying that subscribers are not affected.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context (safe for subscribers) but does not explicitly name alternatives or when to use this vs other delete tools among many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_sequenceBDestructiveInspect
Delete a sequence
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| sequenceId | Yes | Sequence ID |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| sequenceId | No | Deleted sequence ID. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. Description adds no extra behavioral context beyond the obvious delete action. No contradiction found, but the description does not enhance transparency beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief (3 words) with the key verb and noun front-loaded. While concise, it may be too minimal for optimal clarity, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that annotations and schema cover basic aspects and an output schema exists, the description is minimally adequate. However, it lacks details on return value, side effects, or how it differs from similar deletion tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already described in the input schema. The description adds no additional parameter information, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('Delete') and resource ('sequence'). Distinguishes from sibling tools like disable_sequence or other delete tools for different resources. However, lacks additional context about the particular sequence behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance provided. Does not differentiate from similar sibling tools (e.g., disable_sequence) or specify when this tool should be used instead of alternatives. No prerequisites or consequences mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_tagADestructiveInspect
Permanently delete a tag and remove it from all subscribers. This cannot be undone. System tags and tags used by sequences cannot be deleted.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| tagId | Yes | Tag ID. Use list_tags to find tag IDs. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| tagId | No | Deleted tag ID. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true), the description adds 'This cannot be undone' and constraints on system/sequence tags, providing a full picture of the tool's behavior and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, with the primary action and key constraints front-loaded. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given destructiveHint=true and the availability of an output schema, the description sufficiently covers the tool's purpose, constraints, and behavioral traits. It is complete for an agent to decide when and how to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both companyId and tagId. The description does not add additional parameter semantics beyond what the schema already provides, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'permanently delete a tag and remove it from all subscribers', specifying the action, resource, and scope. Distinguishes from sibling tools like create_tag or update_tag by focusing on deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes that system tags and tags used by sequences cannot be deleted, providing guidance on when not to use the tool. Does not explicitly state when to use it, but context is clear from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_templateCDestructiveInspect
Delete a template
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| templateId | Yes | Template ID |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| templateId | No | Deleted template ID. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already indicates destructive behavior, but the description adds no additional behavioral context (e.g., permanence, cascading effects, required permissions). The description merely restates the tool's purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence of 4 words, containing no redundant information. It is front-loaded and efficient, though this brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that a deletion action typically requires warnings about irreversibility or conditions for deletion (e.g., template not in use), the description lacks crucial contextual details. The presence of an output schema does not compensate for missing behavioral and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with descriptions for both parameters (companyId, templateId). The description adds no extra meaning beyond what the schema already provides, hence a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (template), making the tool's purpose unambiguous. However, it does not elaborate on what type of template (e.g., email, landing page) or provide any distinguishing details from sibling delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as update_template or deactivate. No context about prerequisites, irreversible nature, or when deletion is appropriate is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_webhookADestructiveInspect
Permanently delete an outbound webhook endpoint along with its delivery history. This cannot be undone. To keep the endpoint but stop deliveries, use update_webhook with status disabled instead.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| webhookId | Yes | Webhook endpoint ID to delete. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| webhookId | No | Deleted outbound webhook ID. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, but the description adds critical behavioral context: 'This cannot be undone' and 'along with its delivery history'. These details inform the agent about irreversibility and scope, going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose and include essential behavioral details and an alternative. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (destructive, two parameters), the description fully covers purpose, usage guidance, behavioral traits, and alternative. The presence of an output schema means return values need not be explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters (companyId, webhookId) are described in the schema. The description does not add additional meaning to the parameters beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a webhook endpoint permanently, including delivery history. It uses specific verb 'Permanently delete' and distinguishes itself from the sibling tool update_webhook which disables instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (permanent deletion) and provides an alternative: use update_webhook with status disabled to stop deliveries without deleting. This guides the agent in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
disable_sequenceCDestructiveInspect
Disable/pause a sequence
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| sequenceId | Yes | Sequence ID |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| sequence | No | The sequence record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, but the description repeats 'disable/pause' without explaining behavioral traits like whether existing enrollments are affected, if it's reversible, or what state the sequence enters. The description adds no context beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two words, but it is a phrase rather than a full sentence. While every word earns its place, it could be more structured (e.g., a complete sentence) without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations and a complete output schema, the description is minimally adequate. However, it lacks context on the tool's impact (e.g., does it stop new enrollments? Is it reversible?) which would be useful for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters have descriptions in the schema. The description adds no additional meaning or guidance on parameter usage beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Disable/pause a sequence' clearly states the action and resource, using a specific verb. It distinguishes from siblings like 'enable_sequence' and 'cancel_sequence_enrollments' by focusing on disabling the sequence itself rather than enrollments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'cancel_sequence_enrollments' or 'pause_campaign'. There are no usage context or exclusionary notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
duplicate_campaignAInspect
Duplicate a campaign as a new draft. mode 'campaign' (default) copies the campaign and its email, 'ab_test' also duplicates the campaign's A/B test with all variants, and 'variant' copies a single variant's content as the new campaign email (requires variantId).
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| campaignId | Yes | Campaign ID to duplicate. | |
| mode | No | Duplication mode. Defaults to campaign. | |
| variantId | No | A/B test variant ID whose content becomes the new campaign email. Required when mode is variant. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| campaign | No | The duplicated campaign record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this tool is not read-only (creates a new draft) and not destructive. The description adds behavioral details: the modes affect what is copied (email, A/B test, or variant), and the result is a draft. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the main action and mode details without unnecessary words. It is front-loaded with the key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the modes and parameter relationships well. It does not mention optionality of companyId or error conditions, but given the presence of an output schema, the agent has enough context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the meaning of the mode enum values and the role of variantId, which goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Duplicate', the resource 'campaign', and the outcome 'as a new draft'. It distinguishes three modes with specific behaviors, which differentiates it from sibling tools like create_campaign (create from scratch) or update_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each mode (default campaign copy, ab_test for A/B test duplication, variant for single variant copy). It also notes the requirement for variantId in variant mode. However, it does not explicitly exclude use cases where create_campaign or update_campaign would be more appropriate, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
enable_sequenceAInspect
Enable/activate a sequence. IMPORTANT: Only call this when the user EXPLICITLY asks to enable or activate a sequence. Never enable sequences automatically after creation - the user must review the content first.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| sequenceId | Yes | Sequence ID |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| sequence | No | The sequence record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it's a mutation (readOnlyHint=false) and not destructive (destructiveHint=false). Description adds the behavioral context that enabling is a state change, and importantly warns against automatic calls. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Critical usage guideline is front-loaded after the purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple activation action with output schema and good annotations, the description is complete. It covers purpose, behavior, and the key usage guardrail. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptive parameter names and descriptions. Description does not add additional semantic value beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Enable/activate a sequence' with a specific verb and resource. Distinguished from siblings like disable_sequence and create_sequence by the explicit guideline that this is only for explicit user requests, not automatic after creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: only when user explicitly asks to enable or activate. Provides clear exclusion: never after creation automatically. This is excellent guidance that prevents misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
enroll_subscribers_in_sequenceAInspect
Manually enroll subscribers in a sequence by email address or subscriber ID. Maximum 500 total targets per call across emails and subscriberIds. Only active subscribers are enrolled: unknown emails are returned in notFound, while inactive, unavailable, and already actively enrolled subscribers are counted in skipped. By default enrollment starts at the first step after the trigger; pass targetNodeId to start at a specific step.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| sequenceId | Yes | Sequence ID to enroll subscribers in. | |
| emails | No | Email addresses of subscribers to enroll. Combined with subscriberIds, maximum 500 total targets per call. | |
| subscriberIds | No | Subscriber IDs to enroll. Combined with emails, maximum 500 total targets per call. | |
| targetNodeId | No | Optional node ID to start enrollment at. Use a non-trigger nodeId from get_sequence. Defaults to the first step after the trigger. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| sequence | No | The sequence record returned by Sequenzy. |
| enrollments | No | List of sequence enrollment records returned by Sequenzy. |
| enrolled | No | Number of subscribers enrolled. |
| skipped | No | Number of subscribers skipped. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint false), the description discloses mutation, max 500 targets, conditional enrollment (only active), and the meaning of notFound/skipped. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences covering main action, constraints, and special cases. No fluff, well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, output schema exists, and sibling complexity, the description fully covers what an agent needs to know: limits, prerequisites, and defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining the combination limit, default start step, and the behavior of notFound/skipped, going beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enrolls subscribers in a sequence manually by email or ID, with a maximum limit. This distinguishes it from siblings like cancel_sequence_enrollments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the enrollment process, active subscriber requirement, and handling of notFound/skipped targets. It does not explicitly state when not to use, but provides sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_emailBRead-onlyInspect
Generate email blocks from a prompt
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| prompt | Yes | Description of the email to generate | |
| style | No | Style: minimal, branded, promotional | |
| tone | No | Tone: professional, casual, friendly |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| No | The generated email record returned by Sequenzy. | |
| html | No | Generated HTML email body. |
| blocks | No | Generated Sequenzy email blocks. |
| subject | No | Generated subject line. |
| previewText | No | Generated inbox preview text. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, indicating no data modification. The description does not clarify whether generated emails are saved or just returned. While not contradictory, it fails to add behavioral context beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence efficiently conveys the tool's action. No extraneous text. However, the lack of structure (e.g., not listing optional parameters) slightly reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and full parameter descriptions, the description is minimally adequate. However, it omits the role of the optional companyId parameter and does not mention the output format or constraints, leaving gaps for a tool with four parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have schema descriptions (100% coverage), so the description contributes no additional detail. Agent can infer purpose from schema, but no extra context like format constraints or value ranges is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Generate email blocks from a prompt' clearly indicates the tool creates email content based on user input. It uses a specific verb and resource, distinguishing it from sibling tools like generate_subject_lines or generate_sequence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or typical use cases, leaving the agent to infer context 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.
generate_sequenceBRead-onlyInspect
[DEPRECATED - Use create_sequence instead] Generate a multi-email sequence from a goal. Note: create_sequence now handles AI generation automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| goal | Yes | Goal of the sequence (e.g., 'onboard new SaaS trial users') | |
| emailCount | No | Number of emails in the sequence (default: 5, max: 10) | |
| durationDays | No | Total duration in days (default: 14) |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| sequence | No | The generated sequence record returned by Sequenzy. |
| steps | No | List of generated sequence step records returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true, implying the tool does not modify state. However, the description says it 'generate[s]' a sequence, which is a write operation. This contradiction confuses the agent. No additional behavioral traits are described beyond the deprecation notice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loads the deprecation warning, which is critical. It efficiently conveys the key message without unnecessary words. However, it could still be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is deprecated, so thorough context is less critical. The output schema exists. However, the description doesn't explain what happens if the tool is actually called (e.g., does it still work?), leaving some ambiguity. It is minimally complete for a deprecated tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters and their meanings. The description adds no new parameter information beyond referencing 'goal'. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is deprecated and that 'create_sequence' should be used instead. It also explains the tool's original purpose: generating a multi-email sequence from a goal. The purpose is unambiguous, though the deprecation overshadows the core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent to use 'create_sequence' instead and notes that it now handles AI generation automatically. This provides clear guidance on when not to use this tool and what the alternative is, which is exactly what this dimension rewards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_subject_linesARead-onlyInspect
Generate A/B test subject line variants
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| topic | Yes | Topic or context for the subject lines | |
| count | No | Number of variants to generate (default: 5) |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| subjectLines | No | Generated subject line variants. |
| variants | No | List of generated subject line variant records returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and destructiveHint=false, which the description does not contradict. The description adds no behavioral detail beyond 'generate', but annotations already cover safety. No annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but adequate given the presence of an output schema and well-documented parameters. It could briefly mention that it generates creative variants for A/B testing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters (companyId, topic, count). The description adds no further meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Generate A/B test subject line variants' uses a specific verb 'generate' and resource 'subject line variants', clearly distinguishing it from sibling tools like 'create_ab_test' and 'add_ab_test_variant'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'create_ab_test' or 'add_ab_test_variant'. It does not state prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ab_testARead-onlyInspect
Get A/B test details, variants, and per-locale localization sync status
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| abTestId | Yes | A/B test ID |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| abTest | No | The A/B test record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only (readOnlyHint=true) and non-destructive. Description adds specifics about returned data (details, variants, localization sync), enhancing transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action and resource, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with an output schema (as indicated by context signals), the description covers the key return aspects and is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. Description adds no extra meaning beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves 'A/B test details, variants, and per-locale localization sync status', distinguishing it from siblings like 'list_ab_tests' and 'get_ab_test_stats'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While no explicit when-to-use or alternatives are given, the name and description make it clear for retrieving a single A/B test, and siblings like 'list_ab_tests' provide contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ab_test_statsARead-onlyInspect
Get A/B test aggregate stats and per-variant stats. Supports period or custom start/end ranges.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| abTestId | Yes | A/B test ID | |
| period | No | Optional period: 1h, 24h, 7d, 30d, or 90d. | |
| start | No | Custom range start as ISO 8601. Requires end. | |
| end | No | Custom range end as ISO 8601. Requires start. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| abTest | No | The A/B test record returned by Sequenzy. |
| stats | No | The A/B test statistics record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description need not reiterate safety. It adds context that the tool returns both aggregate and per-variant stats and supports filtering by period or custom range, which is helpful but does not disclose dependency behavior or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero redundancy. Every word adds value: the first sentence defines the core action and output type, the second clarifies the filtering options. Ideal conciseness for a tool with well-documented schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the five parameters (all documented), output schema exists, and annotations cover safety, the description is mostly complete. However, it omits default behavior when no period or custom range is provided (e.g., returns stats for all time?), which could lead to uncertainty for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter described. The description adds semantic value by explaining the relationship between 'period' and 'start/end' (support for period OR custom ranges), which clarifies how to use them together beyond the schema's independent descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves aggregate and per-variant A/B test stats, which distinguishes it from siblings like 'get_ab_test' (test details) and 'get_campaign_stats' (campaign stats). The mention of period or custom ranges further specifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving stats with optional time filtering, but provides no explicit guidance on when to use this tool versus alternatives like 'get_ab_test' or when not to use it. No exclusion criteria or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_accountARead-onlyInspect
Get current account information including available companies. IMPORTANT: If you have access to multiple companies, you MUST either:
Call select_company first to choose which company to work with, OR
Pass companyId explicitly in each tool call
The response shows 'companies' (all available) and 'selectedCompanyId' (currently active). All subsequent operations will use the selected company unless you pass a companyId override.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| account | No | The account record returned by Sequenzy. |
| companies | No | List of company records returned by Sequenzy. |
| currentCompanyId | No | Company ID selected by the authenticated API key, when available. |
| selectedCompanyId | No | Company ID selected locally for subsequent MCP calls, when available. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral details beyond annotations: it reveals the response structure (companies, selectedCompanyId) and explains how subsequent operations respect the selected company unless overridden. This aligns with readOnlyHint and adds practical usage context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, front-loaded sentences: first states purpose, next two provide critical usage rules. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, readOnlyHint, and existence of an output schema, the description sufficiently covers tool behavior: what it returns and how multi-tenancy works. No additional information is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the description has no param info but is not required. Baseline 4 is appropriate as no additional parameter meaning is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets current account information including available companies, using a specific verb ('Get') and resource. It distinguishes itself from siblings like 'get_company' and 'select_company' by showing its focus on account-level info and multi-company context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidelines by highlighting the prerequisite actions for multi-company access (select_company or pass companyId). However, it does not explicitly state when not to use the tool, missing a full exclusionary context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_app_urlsARead-onlyInspect
Generate Sequenzy dashboard URLs for known resource IDs. Use this when the user asks where to review or edit a generated sequence, campaign, template, or company settings. If companyId is omitted, the selected/current company is used when available.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If omitted, uses the selected/current company when available. | |
| campaignId | No | Campaign ID for the campaign editor URL. | |
| landingPageId | No | Landing page ID for the landing page editor URL. | |
| sequenceId | No | Sequence ID for the sequence editor URL. | |
| templateId | No | Template/email ID for the email editor URL. | |
| emailId | No | Email ID for the email editor URL. | |
| transactionalId | No | Transactional email ID. | |
| emailSendId | No | Email send ID for the sent email detail URL. | |
| domainId | No | Sending domain ID. | |
| status | No | Status for campaign/sequence list URLs. | |
| settingsTab | No | Settings tab slug, e.g. integrations, domain, tracking, api-keys, team. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| dashboard | No | Company dashboard URL. |
| settings | No | Company settings URL. |
| campaign | No | Campaign editor URL. |
| landingPage | No | Landing page editor URL. |
| sequence | No | Sequence editor URL. |
| No | Email editor URL. | |
| transactionalEmail | No | Transactional email URL. |
| emailSend | No | Sent email detail URL. |
| domain | No | Sending domain settings URL. |
| urls | No | All generated URLs keyed by resource type. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by explaining the URL generation purpose and company fallback behavior, but does not detail other traits like auth or rate limits, which is acceptable given the safe annotation profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with the main purpose first, followed by a usage note. Every sentence is informative and there is no superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 11 optional parameters and the presence of an output schema, the description adequately covers the core functionality and default behavior. However, it could briefly note how multiple IDs are handled, but the current version is still effective.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with full descriptions for all 11 parameters. The description adds no new parameter-level semantics beyond what is in the schema (e.g., the companyId default is already stated in both).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates Sequenzy dashboard URLs for known resource IDs, which is a specific verb+resource pair. It distinguishes from sibling tools that are mainly CRUD operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when the user asks where to review or edit...' providing clear context. It also mentions the companyId default behavior but does not explicitly state when not to use or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_campaignBRead-onlyInspect
Get campaign details and stats
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| campaignId | Yes | Campaign ID |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| campaign | No | The campaign record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds 'details and stats' but doesn't disclose any additional behavioral traits such as potential errors, rate limits, or scope. With annotations covering the safety profile, a 3 is appropriate – minimal 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence: 'Get campaign details and stats'. It is front-loaded with no extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and annotations are present, the description is minimally adequate. However, it could be more complete by specifying what 'details' or 'stats' include (e.g., campaign name, status, metrics). For a simple get tool, it suffices but leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; both parameters have clear descriptions in the schema. The tool description does not add any additional meaning beyond what the schema provides, so the baseline score of 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get campaign details and stats' clearly states the verb (get) and resource (campaign details and stats). However, it does not differentiate from the sibling tool 'get_campaign_stats', which might cause confusion. The purpose is clear but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_campaigns' or 'get_campaign_stats'. There is no mention of prerequisites, exclusions, or selection criteria. The agent is left to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_campaign_statsARead-onlyInspect
Get detailed statistics for a campaign, including attributed conversions and revenue (revenueCents)
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| campaignId | Yes | Campaign ID |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| campaign | No | The campaign record returned by Sequenzy. |
| stats | No | The campaign statistics record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the tool returns conversions and revenue, but does not disclose potential limitations, permissions, or side effects beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose. While concise, it could be slightly more structured (e.g., separate return info). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, complete schema (2 params, both described), and presence of output schema, the description provides sufficient context about what the tool does (get detailed stats including conversions and revenue). No missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description does not add meaning beyond what the schema provides (e.g., it does not clarify the format of 'campaignId' or when 'companyId' might be needed).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('campaign statistics'), and specific data returned ('attributed conversions and revenue (revenueCents)'). It distinguishes from sibling tools like 'get_campaign' and 'get_stats' by specifying detailed stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'get_stats' or 'get_ab_test_stats'. The description implies a specific use case (detailed campaign stats) but does not exclude others or provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_companyARead-onlyInspect
Get company details, processing status, and effective email localization settings
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | Yes | The company ID to check |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| company | No | The company record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds that it returns processing status and email localization settings, but does not disclose other behavioral traits like response size or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Information is front-loaded: verb, resource, and key outputs are listed concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are documented elsewhere. The description mentions specific fields (details, processing status, email localization settings), which is sufficient for context. Minor gap: no mention of whether it returns full company or subset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the 'companyId' parameter. The tool description does not add extra meaning beyond 'the company ID to check', so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves company details, processing status, and email localization settings. However, it does not differentiate from sibling tool 'select_company', which may also fetch company data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'select_company' or 'get_account'. Usage is implied by the read-only nature, but no exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_conversationARead-onlyInspect
Get a conversation with its full message history, subscriber details, and context.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| conversationId | Yes | Conversation ID. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| conversation | No | The inbox conversation record returned by Sequenzy. |
| messages | No | List of conversation message records returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds value by detailing the returned data (message history, subscriber details, context), which is beyond what annotations provide and consistent with read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundancy. It is front-loaded and every word is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description adequately covers what the tool returns. It mentions key elements (message history, subscriber details, context) but could be slightly more specific about scope, though not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not add additional meaning to the parameters beyond what is in the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('conversation'), and specifies what is included ('full message history, subscriber details, and context'), distinguishing it from siblings like 'list_conversations'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives (e.g., list_conversations, reply_to_conversation), nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_email_sendARead-onlyInspect
Get a sent email by emailSendId, including the stored HTML body when available and the ClickHouse event timeline. If the short-lived email send row has been cleaned up, returns the retained ClickHouse events and a sparse summary.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| emailSendId | Yes | Email send ID to inspect. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| emailSend | No | The email send record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive behavior. The description adds valuable context about the HTML body availability, event timeline inclusion, and handling of cleaned-up rows, which is beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that efficiently convey purpose, scope, and edge-case behavior without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and high schema coverage, the description effectively covers purpose, edge cases, and return content. A small improvement would be to note when to prefer this over other get tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameter descriptions are already complete. The description adds no new semantic information beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a sent email by ID, including HTML body and event timeline. It is specific and actionable, but does not explicitly differentiate from sibling tools like get_transactional_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The context of inspecting sent emails is implied but not directly compared to other get_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_integration_guideARead-onlyInspect
Get code examples for integrating Sequenzy into your project.
CRITICAL - FOR SAAS/SUBSCRIPTION APPS: If the app uses Stripe, Polar, Paddle, Dodo, or Creem - tell the user to connect it in Sequenzy dashboard (Settings → Integrations). The native integration automatically handles all payment events and customer tags - no code needed!
CRITICAL - FOR E-COMMERCE STORES: If the store runs on Shopify or WooCommerce - tell the user to connect the native integration in the dashboard instead (it syncs products, orders, and customers automatically). For any other e-commerce stack (custom checkouts, CheckoutChamp, Sticky.io, headless storefronts), use the 'ecommerce' use case to integrate via the Commerce API.
Only provide manual event tracking code if the user explicitly asks for it.
Use cases:
'transactional': Sending one-off emails (welcome, password reset, receipts)
'subscribe_form': Adding subscribers from signup forms
'event_tracking': Tracking CUSTOM events only (not payment events - those come from the integration)
'ecommerce': Connecting a custom e-commerce platform via the Commerce API (sync products, push orders/checkouts, power abandoned cart + back-in-stock automations)
Before implementing, use create_api_key to generate an API key and save it to .env as SEQUENZY_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| framework | No | Framework/language (nextjs, express, python, etc.) | |
| use_case | No | Use case: 'transactional' (sending emails), 'subscribe_form' (adding subscribers), 'event_tracking' (tracking CUSTOM events only - payment events should come from Stripe/Polar/etc integration), 'ecommerce' (connecting a custom e-commerce platform via the Commerce API) |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| guide | No | The integration guide record returned by Sequenzy. |
| code | No | Generated integration code or example. |
| steps | No | Setup steps for the requested integration. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but description adds critical behavioral context: decision logic for native vs manual, and that it generates code examples. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is relatively long but well-structured with bold headings for critical sections. Every sentence adds value, though could be slightly more concise. Front-loaded purpose and critical instructions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description covers purpose, usage, prerequisites, and decision logic well. It doesn't specify output format but relies on output schema. Complete enough for a code-example generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. Description reinforces the use case explanations and adds context about when each is appropriate, providing marginal value over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides code examples for integrating Sequenzy, with specific verb 'Get code examples' and resource 'integration' for project. It distinguishes from siblings by focusing on integration guidance, which no other sibling tool addresses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use native integrations (Stripe, Shopify, etc.) vs this tool, and only provides manual code upon explicit request. It also instructs to use create_api_key first. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_landing_pageBRead-onlyInspect
Get landing page details, content, metrics, and URLs
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| landingPageId | Yes | Landing page ID. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| landingPage | No | The landing page record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's 'Get' verb is consistent but adds no new behavioral context beyond what is already structured. No mention of rate limits, authentication, or other traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded and efficient. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, description sufficiently covers the tool's purpose and inputs. Could be enhanced by mentioning the output schema's contents, but overall complete for a read operation with good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters adequately. Description adds no additional meaning beyond what is in the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves landing page details, content, metrics, and URLs. It distinguishes from siblings like list_landing_pages and get_campaign by specifying the resource and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as list_landing_pages or update_landing_page. Context signals and sibling list provide no comparative cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_segment_countARead-onlyInspect
Get the number of subscribers in a segment
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| segmentId | Yes | Segment ID |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| count | No | Number of subscribers matching the segment. |
| segmentId | No | Segment ID that was counted. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to state safety. The description clarifies that the tool returns a count (number of subscribers) which is useful context beyond annotations. Minimal but sufficient given annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words, immediately communicates the tool's core function. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with a defined output schema, the description is complete. It covers the essential purpose and leaves details to the schema, which is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions ('Company ID', 'Segment ID'). The tool description adds no additional semantic value beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('number of subscribers in a segment'), clearly distinguishing it from sibling tools like list_segments (list segments themselves) or get_subscriber (individual subscriber details). Purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. Context implies usage when the count is needed, but alternatives (e.g., using list_segments and counting results) are not discussed. Adequate but lacks proactive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sequenceARead-onlyInspect
Get sequence details plus editable step content. The response includes sequence.emails with each step's nodeId, linked emailId, subject, previewText, and blocks.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| sequenceId | Yes | Sequence ID |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| sequence | No | The sequence record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by detailing the response fields (sequence.emails with nodeId, emailId, etc.), providing context beyond the safety profile. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with the key purpose and immediate detail about what the response includes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, presence of output schema, and annotations, the description is largely complete. It could mention that the full sequence object is returned, but specifying key fields is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add any extra meaning to the parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves sequence details with editable step content, using a specific verb and resource. It distinguishes itself from siblings like get_sequence_stats by emphasizing step content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching full sequence details but does not explicitly provide when to use this tool over alternatives like get_sequence_stats or list_sequences. No direct guidance on exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sequence_statsARead-onlyInspect
Get statistics for a sequence, including attributed conversions and revenue (revenueCents) plus per-step failed subscribers and failure reasons
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| sequenceId | Yes | Sequence ID |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| sequence | No | The sequence record returned by Sequenzy. |
| stats | No | The sequence statistics record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and no destructive effects. Description adds specific behavioral details: includes attributed conversions, revenue, per-step failed subscribers, and failure reasons. This provides useful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information, no redundant words. Efficiently conveys the tool's purpose and outputs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given readOnly and non-destructive annotations and presence of output schema, the description covers input and key output fields. Lacks mention of error conditions or edge cases, but sufficient for a read-only stats tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters (companyId optional with default, sequenceId required). The description does not add extra meaning to the parameters; it mentions 'revenueCents' in the output context, not parameter semantics. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies verb 'Get', resource 'statistics for a sequence', and details including attributed conversions, revenueCents, per-step failed subscribers, and failure reasons. This clearly distinguishes it from siblings like get_sequence (likely only sequence details) and get_stats (general stats).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as get_ab_test_stats or get_stats. The description only states what it does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_statsBRead-onlyInspect
Get overview statistics for a time period
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| period | No | Time period: 7d, 30d, or 90d (default: 7d) |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| stats | No | The account or company statistics record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's safe. The description adds minimal behavioral context beyond stating it's for a time period. No mention of caching, rate limits, or what 'overview' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is front-loaded and immediately conveys the core purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and only two optional parameters, the description is minimally adequate but lacks detail on what the overview statistics include. It does not explain the scope or any restrictions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with clear descriptions for both parameters (companyId and period) and defaults. The tool description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'overview statistics', and mentions the time period. However, it does not distinguish from sibling tools like 'get_campaign_stats' or 'get_ab_test_stats', which also provide statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not specify that this is for overall statistics versus entity-specific stats, nor does it mention any prerequisites or contextual usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subscriberARead-onlyInspect
Get the full subscriber profile, including tags, list memberships, sequence enrollments, email stats, and recent activity
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| No | Subscriber email address. Provide email or externalId to identify the subscriber. | ||
| externalId | No | Customer-owned subscriber ID. Provide email or externalId to identify the subscriber. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| subscriber | No | The subscriber record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. Description adds value by detailing the scope of data returned (tags, lists, etc.), but does not disclose any behavioral traits beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 18 words, front-loaded with action and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and minimal complexity, the description adequately covers the tool's purpose. However, it could mention the need to provide at least one of 'email' or 'externalId'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides 100% description coverage for all three parameters (companyId, email, externalId). Description adds no additional parameter meaning or usage hints; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb ('Get'), resource ('full subscriber profile'), and enumerates included fields (tags, list memberships, sequence enrollments, email stats, recent activity). Distinguishes from sibling 'get_subscriber_activity' by covering broader profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes what the tool does but offers no guidance on when to use it versus alternatives like 'search_subscribers' or 'get_subscriber_activity'. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subscriber_activityARead-onlyInspect
Get recent activity, email stats, and current sequence enrollments for a subscriber
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| No | Subscriber email address. Provide email or externalId to identify the subscriber. | ||
| externalId | No | Customer-owned subscriber ID. Provide email or externalId to identify the subscriber. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| activity | No | List of subscriber activity event records returned by Sequenzy. |
| subscribers | No | List of subscriber records returned by Sequenzy. |
| pagination | No | Pagination metadata. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, which the description aligns with by stating 'Get'. The description adds value by specifying the types of data returned (recent activity, email stats, sequence enrollments), going beyond the annotation's binary 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no filler words, and directly communicates the tool's purpose. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with an output schema, the description adequately lists the categories of returned data. However, it omits the recency window for 'recent activity' and does not explicitly mention that companyId defaults to the current company (though schema covers this).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not add significant meaning beyond what the schema already provides for companyId, email, and externalId. The schema already explains that email or externalId identifies the subscriber.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'subscriber activity, email stats, and current sequence enrollments'. It distinguishes from siblings like get_subscriber or get_sequence_stats by specifying the combination of data returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The description does not mention alternatives such as get_subscriber for basic info or search_subscribers for searching. Usage 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.
get_templateARead-onlyInspect
Get a template's details, content, and all localized variants with sync status
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| templateId | Yes | Template ID |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| template | No | The email template record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating safe read. The description adds value by detailing what is retrieved (content, variants, sync status), providing behavioral context beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence front-loaded with the primary action and resource. No redundant words; every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, annotations, output schema exists), the description adequately covers the scope of what the tool returns. It could mention that templateId is required, but the schema already specifies that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are described. The description does not add additional meaning or usage notes beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'template', and specifies that it retrieves details, content, localized variants, and sync status. This distinguishes it from sibling tools like list_templates, create_template, update_template, and delete_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need full details of a single template, providing clear context. However, it does not explicitly state when not to use it (e.g., for listing or updating), but this is obvious from the verb and resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_transactional_emailARead-onlyInspect
Get a transactional email by ID or slug, including subject, preview text, blocks, variables, and linked dashboard URLs
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| idOrSlug | Yes | Transactional email ID or API slug, for example `welcome-email`. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| transactional | No | The transactional email record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the annotations by specifying the exact fields returned (subject, preview text, blocks, variables, linked dashboard URLs). This helps the agent understand what to expect in the response. Annotations declare readOnlyHint=true and destructiveHint=false, which the description aligns with.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured sentence with front-loaded action. The list of included content is compact yet informative. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (not shown but indicated) and the description lists key output fields, the description is complete. It accurately describes a single-item retrieval operation for a tool with readOnlyHint=true.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds the example 'welcome-email' for idOrSlug, but otherwise repeats schema info (e.g., companyId fallback). No additional constraints or format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'transactional email', and the retrieval method 'by ID or slug'. It also lists the specific information returned (subject, preview text, blocks, variables, linked dashboard URLs), distinguishing it from sibling tools like list_transactional_emails or get_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like list_transactional_emails or other get tools. The description does not mention exclusions, prerequisites, or context such as needing an email ID/slug beforehand.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invite_team_memberAInspect
Invite a team member by email with role admin or viewer. Existing Sequenzy users are added to the team immediately; others receive an email invitation. Billing access (canManageBilling) can only be granted by the company owner.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| Yes | Email address of the person to invite. | ||
| role | Yes | Team role. Admins can manage the workspace; viewers have read-only access. | |
| canManageBilling | No | Whether the member can manage billing. Only the company owner can grant billing access. Defaults to false. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| invitation | No | The team invitation record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond annotations: immediate addition for existing users vs email for others, billing access limitation. Annotations already indicate mutation (readOnlyHint=false) and non-destructive intent, but description enriches understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with main action, no unnecessary words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers invitation process, role roles, billing nuance, companyId defaulting. Given 4 parameters and output schema existence, description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema: explains behavior for email (existing vs new users) and canManageBilling restriction. Schema already covers all parameters with descriptions, so description adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool invites a team member by email with role admin or viewer, distinguishing it from sibling tools like cancel_team_invitation and list_team_members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for when to use: existing users added immediately, others receive email; billing access restricted to owner. Does not explicitly exclude alternatives but offers sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_ab_testsARead-onlyInspect
List A/B tests and their variants
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| sequenceId | No | Optional sequence ID to filter automation A/B tests. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| abTests | No | List of A/B test records returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true; description adds that variants are included but little else beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no wasted words. Gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present and schema covering parameters, description adequately covers the tool's purpose, though it could hint at default company behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions; description adds no additional meaning beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists A/B tests and their variants, distinguishing it from sibling tools like get_ab_test (single) and create_ab_test.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_ab_test or get_ab_test_stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_ad_accountsARead-onlyInspect
List the Meta ad accounts available through the connected Meta Ads integration. Use the returned account id as adAccountId when creating an audience sync.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| adAccounts | No | List of ad account records returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to reiterate safety. It adds value by specifying the integration (Meta Ads) and that the account ID is used downstream, which is behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with the action and resource, followed by a practical usage note. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no nested objects, output schema exists), the description is complete. It covers purpose, usage, and integration context adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has full coverage (100%) and describes the only parameter (companyId) clearly. The description does not add additional parameter details, but no extra is needed. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List'), the resource ('Meta ad accounts'), and the integration context ('connected Meta Ads integration'). It also explains how to use the output (as `adAccountId` for audience sync), distinguishing it from sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete usage scenario (getting account IDs for creating audience syncs). It does not explicitly state when not to use it or compare to alternatives, but the context is sufficient for an AI agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_audience_syncsARead-onlyInspect
List Meta custom audience syncs (segment -> ad audience mappings) with their schedule and last sync status. Requires the Meta Ads integration to be connected in the dashboard.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| audienceSyncs | No | List of audience sync records returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds the integration requirement but does not discuss pagination, limits, or other behavioral details. Still, it aligns with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that efficiently convey purpose and a prerequisite. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, output schema exists), the description is largely complete. It covers the essential function and a key requirement. Leaves minor gaps like whether all syncs are listed, but sufficient for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (companyId) with a clear description. The tool description adds no extra parameter semantics beyond what the schema provides. Since schema coverage is 100%, baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Meta custom audience syncs, defines them as segment->ad audience mappings, and specifies the information included (schedule and last sync status). It is distinct from sibling tools like create_audience_sync or delete_audience_sync.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the prerequisite of having Meta Ads integration connected, which sets usage context. It does not explicitly state when to use this vs other sync tools, but the naming and sibling list make it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_campaignsCRead-onlyInspect
List all campaigns
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID to list campaigns for. If not provided, uses the currently selected company. | |
| status | No | Filter by status (draft, scheduled, sent) | |
| label | No | Optional label name filter. Only campaigns assigned this label are returned. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| campaigns | No | List of campaign records returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Descriptions adds no behavioral context beyond annotations (readOnlyHint=true). No mention of return format, pagination, sorting, or default behavior for optional parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence, but lacks critical information. It is not front-loaded with key details; every sentence could earn its place if expanded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although output schema exists, the description omits context like default company behavior and filtering logic. For a tool with optional parameters, it is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. Description adds no additional semantic meaning beyond the schema, meeting baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all campaigns' clearly indicates a read operation for multiple resources. It distinguishes from 'get_campaign' (single) and CRUD siblings, though 'all' is slightly misleading given optional filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_campaign' for a single campaign. No mention of prerequisites (e.g., company selection) or filter suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_conversationsARead-onlyInspect
List inbox conversations (email replies from subscribers). Filter by status, free-text search, or unread state, with pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| status | No | Filter by conversation status. Defaults to all. | |
| search | No | Free-text search across conversation subjects and participants. | |
| unread | No | Set true to only return conversations with unread messages. | |
| page | No | Page number. Defaults to 1. | |
| limit | No | Results per page, from 1 to 100. Defaults to 20. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| conversations | No | List of inbox conversation records returned by Sequenzy. |
| pagination | No | Pagination metadata. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds behavioral context by specifying the resource is 'inbox conversations (email replies)', clarifying the scope. It also mentions pagination, which is not in annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that begins with the verb and resource, immediately stating what the tool does. It includes all key capabilities (filtering and pagination) with no filler. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but noted as true), the description appropriately omits return details. It covers the primary functionality (listing filterable conversations with pagination). However, it doesn't mention that all parameters are optional or default behaviors (like page=1, limit=20), which the schema provides but could be reiterated for clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 6 parameters. The description summarizes filters (status, search, unread) and pagination, adding context that these apply to inbox conversations. This adds value but is not extensive, fitting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('inbox conversations'), and specifies filtering options ('by status, free-text search, or unread state') and pagination. It distinguishes this tool from siblings like 'get_conversation' (single conversation) and 'reply_to_conversation' (action) by framing it as a list operation for email replies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing email replies from subscribers, but it does not explicitly state when to use this tool versus alternatives such as 'get_conversation' for a single conversation or 'search_subscribers' for subscriber data. No guidance on when not to use it or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_landing_pagesCRead-onlyInspect
List all landing pages for a company
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID to list landing pages for. If not provided, uses the currently selected company. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| landingPages | No | List of landing page records returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds little. It does not disclose pagination, ordering, or implications of missing companyId. With no additional behavioral context, the description fails to add value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, but it sacrifices informative detail. While concise, it could be more helpful with minimal additions. Not overly verbose, but not ideally structured for agent comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional parameter, output schema exists), the description is too sparse. It omits common details like result set limits, pagination, or permission implications. The output schema likely covers return values, but the description lacks completeness for a full agent decision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for companyId. The description merely repeats 'for a company', adding no new meaning. Baseline 3 is appropriate as the schema handles parameter semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'landing pages' with scope 'for a company'. It distinguishes from sibling tools like get_landing_page (single) and create_landing_page (create). However, it doesn't mention the optionality of companyId or that it uses the currently selected company by default.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like get_landing_page for specific pages or create_landing_page for new ones. No context on prerequisites or related tools is provided, leaving the agent to infer from sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_listsARead-onlyInspect
List all subscriber lists
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID to list lists for. If not provided, uses the currently selected company. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| lists | No | List of list records returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and destructiveHint=false, so the description's 'List all subscriber lists' is consistent. However, the description adds no extra behavioral context beyond the annotations, such as pagination behavior or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, extremely concise and front-loaded. It conveys the purpose without waste, though it could marginally benefit from a structure like a one-line summary with additional detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and comprehensive annotations, the description is largely sufficient for a simple list operation. It is complete in conveying the core action but could mention any default behavior (e.g., scope of lists returned).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for the single parameter 'companyId'. The tool description does not add any additional parameter semantics beyond what is already in the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all subscriber lists' uses a clear verb (list) and specific resource (subscriber lists). It is unambiguous and distinguishes itself from sibling tools like list_campaigns or list_landing_pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor when not to use it. Lacks context on prerequisites, limitations, or comparisons to similar list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_productsARead-onlyInspect
List synced products (Stripe, Shopify, WooCommerce) including any attached digital delivery file. Useful before attaching a file or building a purchase sequence for a specific product.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID to list products for. If not provided, uses the currently selected company. | |
| provider | No | Filter by provider: stripe, shopify, woocommerce, or manual. | |
| search | No | Filter products by title. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| products | No | List of product records returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that it includes attached digital delivery files, which is a minor behavioral detail. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose and scope, second provides usage guidance. No unnecessary words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having output schema, the description is complete enough for this simple list tool. Annotations cover safety, schema covers parameters, and usage guidance is provided. No major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all three parameters (companyId, provider, search) described adequately. The description adds no additional parameter-specific meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'list' and resource 'synced products' with specific providers (Stripe, Shopify, WooCommerce) and includes attached digital delivery file. It distinguishes from sibling tools like sync_products, upsert_products, and delete_product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it is 'useful before attaching a file or building a purchase sequence for a specific product,' providing clear context for when to use this tool. Does not explicitly mention when not to use or alternatives, but the use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_segmentsCRead-onlyInspect
List all segments
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID to list segments for. If not provided, uses the currently selected company. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| segments | No | List of segment records returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds no further behavioral context (e.g., pagination, returned fields), but it does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (4 words), which is concise but under-specified. It lacks front-loaded context; every sentence earns its place, but more information would be helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, annotations, and a single optional parameter, the description is minimally adequate. However, it does not explain the role of companyId or any default behavior, which is important for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter companyId. The description does not add any additional meaning beyond what is already in the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all segments' clearly states the action (list) and resource (segments), but it does not differentiate from sibling list tools or clarify scope. The parameter companyId implies filtering by company, but the description says 'all' without qualification, which is slightly ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_segment_count or other list tools. There is no mention of prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_sequencesBRead-onlyInspect
List all email sequences (automations)
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID to list sequences for. If not provided, uses the currently selected company. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| sequences | No | List of sequence records returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's statement 'List all email sequences' adds minimal behavioral context. It does not disclose edge cases like whether disabled sequences are included or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no redundant words. It is concise and front-loaded, though it could be slightly expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, output schema present), the description is mostly adequate but misses mentioning the company context and any limitations. It covers the core action but lacks detail for optimal agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'companyId', which is already documented meaningfully in the schema. The description does not add further semantics beyond the schema, earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'email sequences' with the parenthetical '(automations)' for disambiguation. It distinguishes from sibling tools like 'get_sequence' (single) and 'create_sequence', though it does not explicitly mention the optional company scoping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_campaigns' or 'get_sequence'. No explicit context or exclusions are given, leaving the AI agent to infer usage 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.
list_tagsARead-onlyInspect
List all tags in the account
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID to list tags for. If not provided, uses the currently selected company. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| tags | No | List of tag records returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. Description adds no additional behavioral context beyond the basic listing action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no superfluous information, effectively conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema, and the description is sufficient for a listing operation without further details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the optional companyId parameter. Description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'list', resource 'tags', and scope 'in the account', distinguishing it from sibling tools like create_tag, delete_tag, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or avoid this tool, though it is implied for listing all tags. Alternative tools for tag management exist but are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_team_membersARead-onlyInspect
List team members for the company, including the owner, members with their roles, and pending or expired invitations.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| members | No | List of team member records returned by Sequenzy. |
| invitations | No | List of team invitation records returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context by specifying the content includes owner, roles, and pending/expired invitations, which aligns without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, front-loaded with action and scope. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description sufficiently covers the tool's output (list of team members with details). It is complete for a read-only list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single optional parameter 'companyId'. The description does not add new parameter info beyond implying it's for the current/selected company, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action 'list team members' and details the scope: 'including the owner, members with their roles, and pending or expired invitations.' This distinguishes it from sibling tools like invite_team_member or cancel_team_invitation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests use for viewing team composition but provides no explicit guidance on when to use vs alternatives (e.g., get_company for basic info). No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_templatesARead-onlyInspect
List all email templates, including per-locale localization sync status
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| templates | No | List of email template records returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, ensuring the agent knows this is safe. The description adds value by revealing that the output includes 'per-locale localization sync status', which is additional behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that contains no filler. Every word adds value, and the key information (list all, email templates, extra detail) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no nested objects, output schema exists), the description covers the essential behavior: listing all templates and specifying the extra field. No gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter (companyId) is well-described in the schema. The description does not elaborate on parameters, but the schema already provides full semantics, so this meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all email templates' with the specific verb 'list' and resource 'email templates', and adds a distinguishing feature 'including per-locale localization sync status'. This differentiates it from siblings like 'get_template' (single) and 'list_transactional_emails' (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like 'get_template' or 'list_transactional_emails'. The purpose is implied by the name, but no exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_transactional_emailsARead-onlyInspect
List transactional email templates, including their API slugs and linked email IDs
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| transactional | No | List of transactional email records returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description adds minimal behavioral context beyond listing the returned fields. No additional traits like rate limits or pagination are disclosed, but annotations cover the safety profile adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that effectively communicates the core function. No extraneous words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter), annotations, and presence of an output schema, the description adequately covers what the tool does and what it returns. However, it does not mention pagination or ordering, which might be relevant for a list endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a description for the companyId parameter, and the tool description does not add further meaning. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists transactional email templates and specifies the additional details included (API slugs and linked email IDs). This distinguishes it from siblings like 'list_templates' (generic templates) and 'list_campaigns'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Siblings like 'list_templates' or 'get_transactional_email' exist, but no differentiation is offered. No when-not-to-use or context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_webhook_deliveriesARead-onlyInspect
List recent delivery attempts for an outbound webhook endpoint, including status and response codes.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| webhookId | Yes | Webhook endpoint ID. | |
| limit | No | Maximum number of deliveries to return, from 1 to 100. Defaults to 20. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| deliveries | No | List of webhook delivery records returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the read-only behavior is covered. The description adds 'recent' and 'including status and response codes' but does not disclose other behavioral traits like pagination, ordering, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with 10 words, front-loaded, no redundant information. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with three parameters and an output schema, the description provides the essential purpose but lacks details on ordering (e.g., most recent first) or scoping ('recent'). It is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter has a clear description. The tool description does not add extra meaning beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (List), resource (recent delivery attempts for an outbound webhook endpoint), and what is included (status and response codes). It distinguishes from sibling tools like 'list_webhooks' and 'replay_webhook_delivery'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'test_webhook' or 'replay_webhook_delivery'. No prerequisites or context given; usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_webhooksARead-onlyInspect
List outbound webhook endpoints and their subscribed event types.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| webhooks | No | List of outbound webhook records returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds minimal extra behavioral context. It mentions listing endpoints and event types but does not disclose other traits like pagination, authorization requirements, or scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 9 words with no filler. Every word serves the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema available, the description is sufficient for a simple list operation. It could clarify scope (e.g., 'for the authenticated account' or 'for a given company'), but the optional companyId parameter implies this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents the single optional parameter (companyId). The description does not elaborate on the parameter's meaning beyond the schema, which is adequate for a simple optional filter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('outbound webhook endpoints'), and specifies the return includes 'subscribed event types'. This distinguishes it from sibling tools like list_webhook_deliveries, which list delivery events instead of endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing configured webhooks but does not explicitly state when to use this tool versus alternatives (e.g., list_webhook_deliveries, create_webhook). No exclusions or context hints are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_websitesARead-onlyInspect
List all configured sender websites/domains
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| label | No | Optional label name filter. Only templates assigned this label are returned. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| websites | No | List of sender website records returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds 'configured' implying only existing, active items are returned, but it doesn't elaborate on pagination, response structure, or performance implications. With annotations present, the description provides minimal additional 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of six words, no filler or redundancy. It is front-loaded and efficient, conveying the essential purpose without excess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema and full parameter descriptions, the description is adequate but not complete. It fails to mention optional filtering parameters (companyId, label) or any ordering/pagination details. The presence of a sibling 'check_website' suggests additional context could be useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description in the schema. The description does not add any further meaning or explanation about how companyId or label affect the results. Baseline 3 is appropriate as the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'all configured sender websites/domains'. This distinguishes it from siblings like 'check_website' (which presumably checks a single website) and 'add_website' (which creates).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't mention that 'check_website' might be used for verifying a specific website's configuration, nor does it explain prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mark_conversation_readAInspect
Mark all unread inbound messages in a conversation as read.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| conversationId | Yes | Conversation ID. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| conversation | No | The inbox conversation record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a write operation (readOnlyHint=false). The description adds that it marks 'all unread inbound messages' as read, specifying scope. This is useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no fluff. Every word carries meaning, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with an output schema, the description is sufficient. It covers the primary action and scope. Could mention that it only affects inbound messages, but that is already stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for both parameters. The description does not add further meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('mark as read') and the target ('all unread inbound messages in a conversation'). It distinguishes from sibling tools like 'reply_to_conversation' or 'get_conversation' effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when or when-not to use is provided. The description implies usage for marking messages read, but lacks guidance on alternatives or prerequisites. Context from sibling tools helps, but direct guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pause_campaignAInspect
Pause a campaign that is currently sending. Only campaigns in sending status can be paused. Use resume_campaign to continue delivery later.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| campaignId | Yes | Campaign ID to pause. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| campaign | No | The campaign record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-readOnly (mutation) and non-destructive. Description adds the critical prerequisite that only sending-status campaigns can be paused. Does not elaborate on immediacy of pause or error handling, but sufficient for a reversible action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and condition. Second sentence provides alternative tool. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description doesn't need return details. Includes precondition and alternative. Minor gap: lacks details on timing of pause effect or error behavior when status invalid, but overall complete for a simple toggle tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions for companyId and campaignId. Description adds no extra parameter insights beyond schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool pauses a campaign that is currently sending, using specific verb 'pause' and resource 'campaign'. Distinguishes from sibling 'resume_campaign' by mentioning it for continuing later, and implies difference from 'cancel_campaign'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: pause only campaigns in sending status. Provides alternative tool 'resume_campaign' for continuation. No misuse scenarios needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
publish_landing_pageAInspect
Publish a landing page. Optional name, slug, or content updates are saved before publishing.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| landingPageId | Yes | Landing page ID. | |
| name | No | Optional landing page name update. | |
| slug | No | Optional slug update before publishing. | |
| content | No | Complete Sequenzy landing page content JSON. Use this when replacing the page structure. The content must be the editor-compatible landing page schema with version, template, seo, theme, and blocks. Landing pages must include exactly one footer block and at most one form block. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| landingPage | No | The landing page record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it's a write operation (readOnlyHint=false) and not destructive. The description adds that optional updates are saved before publishing, but does not disclose side effects like overwriting previous versions or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy, front-loaded with the core action. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema and annotations, the description is nearly complete. It lacks explicit mention that the landing page must already exist, but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions. The tool description adds that optional name, slug, or content updates are saved before publishing, which provides minor clarification beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'publish' and resource 'landing page', and distinguishes from sibling tools like create_landing_page and update_landing_page by implying this makes the page live.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to make a landing page live, but does not explicitly state when to use it versus other landing page tools, nor does it mention that the page must already exist via create_landing_page.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remove_product_fileBDestructiveInspect
Remove the attached distributable file from a product.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| productId | Yes | Product ID from list_products, or your own productId for products pushed via upsert_products. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| product | No | The product record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms the destructive nature already indicated by annotations. It adds no extra context about side effects, permanence, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is efficient, though additional details might be beneficial for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and existing schema/annotations, the description is moderately complete but lacks information on prerequisites, error states, or return value context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add any extra meaning beyond what is already described in the schema for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the resource ('the attached distributable file from a product'). It effectively distinguishes from sibling tools like 'attach_product_file' and 'delete_product'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remove_subscriberBDestructiveInspect
Unsubscribe or delete a subscriber
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| No | Subscriber email address. Provide email or externalId to identify the subscriber. | ||
| externalId | No | Customer-owned subscriber ID. Provide email or externalId to identify the subscriber. | |
| hardDelete | No | If true, permanently deletes. If false, just unsubscribes. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| subscriber | No | The subscriber record returned by Sequenzy. |
| hardDeleted | No | Whether the subscriber was permanently deleted. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by revealing two behavioral modes (unsubscribe vs delete). However, it does not explain what the tool does to associated data or whether the action is reversible, which is critical given the destructive hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (5 words), which is concise but lacks proper structure. It does not provide complete sentences or organize information effectively, though it avoids verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two behaviors, multiple identification options, and a hardDelete flag, the description is too minimal. It does not mention how the subscriber is identified or the significance of the hardDelete parameter, leaving important context uncovered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are fully described in the schema (100% coverage), so the description adds no extra semantic value. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs two related but distinct actions (unsubscribe or delete) on a subscriber resource. It distinguishes from siblings like 'add_subscriber' and 'update_subscriber' by specifying the removal behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'remove_subscribers_from_list' or even the related 'cancel_campaign'. The description does not clarify the different use cases for unsubscribing vs deleting, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remove_subscribers_from_listADestructiveInspect
Remove subscribers from a list by email address. Maximum 500 emails per call. Subscribers stay in the account; only the list membership is removed. Returns the removed count plus a notFound array of emails that did not match a subscriber.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| listId | Yes | Subscriber list ID to remove subscribers from. | |
| emails | Yes | Email addresses to remove from the list. Maximum 500 per call. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| list | No | The list record returned by Sequenzy. |
| removed | No | Number of subscribers removed from the list. |
| skipped | No | Number of subscribers skipped. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds valuable behavioral context: maximum batch size, non-destructive effect on subscriber accounts, and return format. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no fluff. Each sentence adds essential information: action, limit, side effect, and return values. Front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main aspects: what, limit, side effects, and return. Lacks mention of idempotency or whether removing a non-member is an error, but sufficient for typical usage. Output schema not provided but return described in text.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning beyond schema by specifying the 500 email limit and clarifying that 'notFound' includes unmatched emails. This helps the agent understand constraints and expected output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove subscribers from a list by email address'), identifies the resource (subscribers and list), and specifies scope (only list membership removed, not the subscriber from the account). This distinguishes it from sibling tools like 'remove_subscriber' (entire account removal) and 'add_subscribers_to_list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit limits (maximum 500 emails per call) and behavior details (subscribers stay in account, return values described). However, it does not explicitly contrast with alternatives like 'remove_subscriber' for single removals, but the context is clear enough for agent selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
replay_webhook_deliveryAInspect
Replay a previous webhook delivery, re-sending the same event payload to the endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| webhookId | Yes | Webhook endpoint ID. | |
| deliveryId | Yes | Delivery ID to replay. Use list_webhook_deliveries to find delivery IDs. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| delivery | No | The webhook delivery record returned by Sequenzy. |
| job | No | The webhook replay job record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, non-destructive, and open-world hint. The description adds that it re-sends the same payload, but does not detail potential side effects (e.g., duplicate webhooks, idempotency). With annotations present, the description is adequate but could be richer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that clearly conveys the action and outcome. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a replay action with three parameters (all described in schema) and an output schema present, the description is sufficiently complete. It provides the essential behavior without requiring additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all three parameters with descriptions. The tool description adds no additional meaning beyond what the schema provides. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (replay), resource (previous webhook delivery), and effect (re-send same event payload). It fully defines the tool's purpose and distinguishes it from related tools like list_webhook_deliveries and test_webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It implies a prerequisite (listing deliveries) via the input schema, but lacks explicit guidance on when not to use or preferred alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reply_to_conversationAInspect
Send a reply in a conversation, or add an internal note. type 'outbound' (default) emails the subscriber and requires bodyText or bodyHtml; type 'note' adds a private team-only note. Replying to a closed conversation reopens it.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| conversationId | Yes | Conversation ID to reply in. | |
| type | No | Message type: outbound emails the subscriber, note is internal-only. Defaults to outbound. | |
| subject | No | Optional subject override. Defaults to the conversation subject. | |
| bodyText | No | Plain-text message body. | |
| bodyHtml | No | HTML message body. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | The conversation message record returned by Sequenzy. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| conversation | No | The inbox conversation record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), the description adds that replying reopens a closed conversation, which is a behavioral side effect. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the main purpose and key details (types, reopening). Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters (1 required), 100% schema coverage, and an output schema (not shown), the description covers the main purpose, parameter distinctions, and the important side effect of reopening conversations, making it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with all parameters described. The description adds context about type behavior (outbound requires bodyText or bodyHtml) but does not significantly extend beyond the schema, earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool sends a reply or adds an internal note, distinguishing between 'outbound' and 'note' types. It also mentions reopening closed conversations, which clearly identifies the tool's resource and scope, differentiating it from sibling tools like mark_conversation_read or update_conversation_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use each type: 'outbound' emails the subscriber, 'note' is private. It also notes that replying reopens a closed conversation. However, it doesn't explicitly state when not to use or mention alternatives, though the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
restart_ab_testADestructiveInspect
Run another sequence A/B test after a winner is selected. By default the winner becomes the new control; pass sourceVariantId to use another variant as the control email.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| abTestId | Yes | A/B test ID to restart | |
| sourceVariantId | No | Optional variant ID to use as the new control email. Defaults to the selected winner. | |
| testType | No | Optional test type: subject or content. | |
| winnerThreshold | No | Optional number of subscribers before selecting a winner. Must be from 10 to 1000. | |
| variantCount | No | Optional total variants including the control. Must be from 2 to 4. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| abTest | No | The A/B test record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint: true, so the description is not required to disclose destructiveness. It adds detail about the winner becoming the new control and the optional sourceVariantId. However, it does not explain other side effects (e.g., resetting stats, sending emails) or what 'restart' entails exactly. The transparency is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, 32 words. It front-loads the core action and immediately explains default behavior and an option. No unnecessary words or repetition. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 100% schema coverage and presence of an output schema, the description need not cover all parameters. It explains the key use case and default. It could mention that the test must already exist and have a winner, but that is implied. The description is complete enough for a focused tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no new information for parameters beyond the schema. It mentions sourceVariantId but restates the schema's description. Other parameters (companyId, testType, etc.) are not touched. The description does not improve parameter understanding over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's function: 'Run another sequence A/B test after a winner is selected.' It includes the resource (sequence A/B test) and the action (run). It distinguishes from create_ab_test by mentioning 'after a winner is selected', though 'another' could be interpreted as a new test. Overall, it is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear precondition: 'after a winner is selected.' It explains the default behavior and an alternative (use sourceVariantId). However, it does not explicitly say when not to use this tool or mention alternatives like create_ab_test. The guidance is adequate for a specific use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resume_campaignAInspect
Resume a paused campaign. Only campaigns in paused status can be resumed. Optionally spread the remaining delivery over a number of hours.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| campaignId | Yes | Campaign ID to resume. | |
| spreadOverHours | No | Spread the remaining delivery over an integer number of hours from 1 to 72. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| campaign | No | The campaign record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by explaining the optional spreadOverHours feature and the precondition. Annotations indicate it is not read-only and not destructive, which aligns with the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that efficiently convey the purpose, precondition, and optional parameter. There is no wasted information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the input schema covers all parameters with descriptions, annotations are present, and an output schema exists, the description adequately covers the key conditions and optional behavior. It is complete for a well-documented tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for all parameters. The description adds minimal additional meaning for spreadOverHours ('spread the remaining delivery'), but does not significantly enhance understanding of companyId or campaignId beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (resume), the resource (campaign), and the precondition (must be paused). It distinguishes itself from sibling tools like pause_campaign and cancel_campaign by specifying the allowed status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the condition for use ('Only campaigns in paused status can be resumed'), but does not mention specific alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
schedule_campaignAInspect
Schedule a draft or already scheduled campaign. Returns dashboard edit and preview URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| campaignId | Yes | Campaign ID | |
| scheduledAt | Yes | Future ISO 8601 timestamp for the send, for example 2026-06-01T14:00:00Z. | |
| targetLists | No | Optional campaign targeting object. Omit to use saved targeting or all active subscribers. Examples: {type:'all'}, {type:'lists', listIds:['list_123']}, {type:'segment', segmentId:'seg_123'}, or {type:'filtered', filters:[...], filterJoinOperator:'and'}. | |
| sendTimeOptimization | No | Whether to use send-time optimization. | |
| spreadOverHours | No | Spread delivery over an integer number of hours from 1 to 72. When set, spread delivery takes precedence over send-time optimization. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| campaign | No | The campaign record returned by Sequenzy. |
| scheduledAt | No | Scheduled send timestamp. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only and non-destructive behavior. The description adds that it returns dashboard edit and preview URLs, providing some behavioral context. However, it does not disclose potential side effects (e.g., triggering sends, clearing previous schedules) or authorization requirements beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys purpose, input type, and output. It is front-loaded and contains no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters (all documented), annotations, and an output schema (though not shown), the description covers the primary functionality and return value. It could mention additional details like campaign state expectations or delivery overrides, but it is largely complete for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already fully described. The description does not add semantic nuance beyond reiterating the tool's purpose. The baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Schedule a draft or already scheduled campaign') and specifies the return value ('Returns dashboard edit and preview URLs'). It distinguishes from sibling tools like create_campaign, update_campaign, and cancel_campaign by focusing on the scheduling action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., campaign must be in draft state), scenarios to avoid, or how it relates to similar tools like pause_campaign or resume_campaign.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_subscribersARead-onlyInspect
Search subscribers by free-text query, tags, list, or segment. If you omit limit, the tool fetches all pages and returns every match.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| query | No | Search query (email or name) | |
| tags | No | Filter by tags | |
| list | No | Filter by subscriber list ID or exact list name. Prefer listId when known. | |
| listId | No | Filter by subscriber list ID. | |
| listName | No | Filter by exact subscriber list name when the list ID is not known. | |
| segmentId | No | Filter by segment ID | |
| status | No | Filter by subscriber status: active, unsubscribed, or bounced. | |
| limit | No | Maximum results to return. If omitted, the tool returns all matches across pages. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| subscribers | No | List of subscriber records returned by Sequenzy. |
| pagination | No | Pagination metadata. |
| returned | No | Number of subscribers returned. |
| truncated | No | Whether the result was truncated by the requested limit. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds transparency about automatic pagination when limit is omitted, which is valuable beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose with key filters, second adds critical pagination behavior. No extraneous content, front-loaded effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers main purpose and pagination behavior. However, it omits the 'status' filter parameter present in schema. With output schema existing, return value details are not needed, but the missing filter mention is a small gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully described in schema. The description summarizes filter options but does not add new parameter-level details. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches subscribers with multiple filtering options (free-text, tags, list, segment). It distinguishes itself from siblings like get_subscriber (single subscriber lookup) and listing tools by emphasizing search and multiple filter criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a key usage guideline about pagination when limit is omitted. However, it does not explicitly contrast with alternatives like get_subscriber or list_subscribers, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
select_companyAInspect
Select which company to operate on (for user-scoped API keys with access to multiple companies). Use get_account to see available companies. After selecting, all subsequent operations will use this company unless you pass a companyId override.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | Yes | The company ID to select (from get_account's companies list) |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| companyId | No | Selected company ID. |
| companyName | No | Selected company name. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint=false, destructiveHint=false). Description adds value by explaining the set-and-forget session behavior, no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first states purpose, second provides prerequisite and behavioral note. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisite, persistent effect, and override option. Output schema exists so return value explanation not needed. Minor omission: no error handling for invalid companyId.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% with a good description. Tool description reinforces that companyId comes from get_account's list, adding context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action 'Select which company to operate on' for user-scoped API keys with multiple companies. Distinguishes from siblings by describing persistent session context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using get_account first to see available companies, and explains the persistent effect on subsequent operations. No explicit when-not, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_emailAInspect
Send a transactional email to a single recipient
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| to | Yes | Recipient email address | |
| subject | No | Email subject (required if not using templateId) | |
| html | No | Email HTML content (required if not using templateId) | |
| templateId | No | Template ID to use (alternative to html) | |
| variables | No | Variables for template personalization. Nested objects and arrays are supported for repeat blocks, for example { items: [...] }. | |
| subscriberExternalId | No | Customer-owned subscriber ID for attaching analytics/localization on single-recipient sends. Maximum length: 255 characters. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| emailSend | No | The transactional email send record returned by Sequenzy. |
| transactional | No | The transactional email record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate write (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the behavioral trait that emails are 'transactional' and limited to 'a single recipient', providing useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no extraneous words, efficiently conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is clear and sufficient given the presence of a detailed input schema and output schema, but it could be more complete by mentioning immediate sending behavior or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description does not add parameter-level details, but it is not required to repeat schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'send', the resource 'transactional email', and the constraint 'to a single recipient', clearly differentiating it from sibling tools like create_transactional_email or send_test_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs. alternatives such as create_transactional_email, send_test_email, or other email-related tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_test_emailAInspect
Send a test email to a single address
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| campaignId | Yes | Campaign ID to test | |
| to | Yes | Email address to send test to |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| emailSend | No | The test email send record returned by Sequenzy. |
| recipient | No | Test email recipient. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it's a write operation (readOnlyHint=false) but not destructive (destructiveHint=false). The description adds no additional behavioral context such as permissions, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with key information, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a simple test tool, but could be improved by stating that it is meant for testing before sending to a full list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents parameters well. The description does not add extra meaning beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Send), the resource (test email), and a key limitation (to a single address). It distinguishes from sibling 'send_email' which sends actual campaign emails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like 'send_email'. The context of 'test' is implied but not stated clearly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sync_audience_nowAInspect
Trigger an immediate upload of the segment's subscribers to its Meta custom audience, outside the regular schedule.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| syncId | Yes | Audience sync ID to run. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| audienceSync | No | The audience sync record returned by Sequenzy. |
| job | No | The audience sync job record returned by Sequenzy. |
| jobId | No | Queued audience sync job ID. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations: specifies immediate upload and one-time nature. Annotations already indicate non-readOnly and non-destructive, so no contradiction. Description enriches behavioral understanding with timing details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence conveys purpose efficiently with no extraneous words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high schema coverage, existence of output schema, and annotations, description is complete for basic usage. Could mention prerequisite that sync configuration exists, but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. Description does not add additional meaning beyond what schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'trigger', resource 'upload of segment's subscribers to Meta custom audience', and scope 'immediate, outside regular schedule'. Distinguishes from siblings like create_audience_sync and update_audience_sync.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use case for ad-hoc immediate uploads outside regular schedule ('outside the regular schedule'). Does not explicitly state when not to use or mention alternatives, but provides clear context for its intended scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sync_productsAInspect
Queue a sync of the Stripe product catalog into the products list. Requires an active Stripe integration.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| job | No | The product sync job record returned by Sequenzy. |
| jobId | No | Queued product sync job ID. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only and not destructive. The description adds that it is a sync operation, but does not disclose whether it replaces the entire product list or merges, nor any async behavior. With annotations present, the description adds some context but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the action and resource, the second adds a prerequisite. No fluff, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema, annotations, and presence of an output schema, the description is adequate. It could mention the async nature of queuing a sync, but overall it provides sufficient context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter (companyId) with a clear description. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Queue a sync' and specifies the resource: 'Stripe product catalog into the products list'. It is specific and distinguishes from siblings like 'upsert_products' (individual updates) and 'list_products' (read-only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite ('Requires an active Stripe integration'), but does not explicitly guide when to use this tool versus alternatives (e.g., 'upsert_products') or when not to use it. Usage is implied but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
test_webhookAInspect
Send a test event to an outbound webhook endpoint to verify it is reachable and signatures can be validated.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| webhookId | Yes | Webhook endpoint ID to test. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| webhook | No | The outbound webhook record returned by Sequenzy. |
| delivery | No | The test webhook delivery record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false and destructiveHint=false. The description adds that the tool sends a test event and verifies reachability/signatures, which is non-destructive but not read-only. However, it does not disclose potential side effects (e.g., if the test event triggers actual processing) or rate limits. The openWorldHint=true is not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and purpose. Every word earns its place; no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (testing a webhook) and the presence of an output schema (not shown but mentioned in context), the description is sufficient. It explains what the tool does and why, though it could briefly mention what the response contains (e.g., success/failure indicators).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (companyId as optional, webhookId as required) with 100% coverage. The description does not add additional meaning 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Send a test event'), the resource ('outbound webhook endpoint'), and the purpose ('verify it is reachable and signatures can be validated'). It distinguishes itself from sibling tools like create_webhook, delete_webhook, and replay_webhook_delivery by focusing on testing an existing webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after setting up a webhook to test connectivity and signature validation, but it does not explicitly state when not to use it or mention alternative tools like replay_webhook_delivery for testing past deliveries. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
unpublish_landing_pageADestructiveInspect
Unpublish a landing page and return it to draft status. Optional name, slug, or content updates are saved first.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| landingPageId | Yes | Landing page ID. | |
| name | No | Optional landing page name update. | |
| slug | No | Optional slug update before unpublishing. | |
| content | No | Complete Sequenzy landing page content JSON. Use this when replacing the page structure. The content must be the editor-compatible landing page schema with version, template, seo, theme, and blocks. Landing pages must include exactly one footer block and at most one form block. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| landingPage | No | The landing page record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, but the description does not elaborate on any destructive consequences. It does add behavioral context that optional updates are saved before unpublishing, which is useful. However, it does not discuss reversibility or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core action. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the main action and optional updates. However, it could mention edge cases (e.g., what if the page is already draft) or prerequisites (e.g., page must be published).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already well-described. The description mentions 'Optional name, slug, or content updates' which aligns with schema, but does not add new meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Unpublish'), the resource ('landing page'), and the outcome ('return it to draft status'). It also adds nuance about optional updates being saved first. This distinguishes it from siblings like 'publish_landing_page' and 'delete_landing_page'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for unpublishing a landing page, but does not explicitly state when to use this tool versus alternatives (e.g., delete_landing_page). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_ab_test_variantAInspect
Update a draft A/B test variant. Provide at least one of subject, previewText, html, or blocks. Use either html or blocks, not both.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| abTestId | Yes | A/B test ID | |
| variantId | Yes | A/B test variant ID | |
| subject | No | Variant subject line | |
| previewText | No | Variant preview text. Pass an empty string to clear it. | |
| html | No | Replacement HTML body. Mutually exclusive with blocks. | |
| blocks | No | Replacement Sequenzy email blocks. Use `styles` for per-block background, background opacity, text color, padding, border radius, border width, and border color. Top-level style aliases such as `backgroundColor`, `backgroundOpacity`, `borderColor`, `borderWidth`, and `borderRadius` are also accepted and saved under `styles`. Mutually exclusive with html. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| abTest | No | The A/B test record returned by Sequenzy. |
| variant | No | The A/B test variant record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-readOnly and non-destructive, which align with the update action. Description adds context (draft-only, mutual exclusivity) but doesn't disclose effects of updating non-draft variants or idempotency. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action, then constraints. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given parameter count, schema coverage, and output schema existence, description covers key points. Lacks explicit mention that variant must be in draft status, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds little beyond schema. It reinforces mutual exclusivity, but the schema already mentions it. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool updates a draft A/B test variant, distinguishing from 'add_ab_test_variant' and other siblings. It also specifies required fields and constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear constraints (at least one field, mutual exclusivity of html and blocks). Could be improved by explicitly noting it only works on draft variants, but overall it offers actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_audience_syncAInspect
Update an audience sync's frequency or pause/resume it (isActive).
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| syncId | Yes | Audience sync ID | |
| frequency | No | New sync frequency. | |
| isActive | No | Set false to pause the sync, true to resume it. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| audienceSync | No | The audience sync record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, and the description correctly reflects a write operation. However, it does not disclose side effects, immediacy of updates, or permission requirements. It adds some context beyond annotations but remains limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, front-loaded with the action and key parameters. No extraneous information; every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, mutation with optional fields) and the presence of a complete input schema and output schema, the description adequately summarizes the functionality. It could mention idempotency or partial updates, but the schema fills most gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The description mentions frequency and isActive but adds no additional meaning beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'audience sync', and specifies the exact actions: updating frequency or pausing/resuming via isActive. It effectively distinguishes from sibling tools like create_audience_sync, delete_audience_sync, and sync_audience_now.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is used to modify an existing audience sync's settings, but it does not explicitly state when to use it versus alternatives (e.g., create_audience_sync for new syncs, sync_audience_now for immediate sync). Context is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_campaignCInspect
Update a draft campaign
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| campaignId | Yes | Campaign ID | |
| name | No | Campaign name | |
| subject | No | Email subject line | |
| trackingCode | No | Optional campaign tracking code for UTM templates. Use only when explicitly requested. Send an empty string to clear it. | |
| html | No | Email HTML content. Mutually exclusive with `blocks`. | |
| blocks | No | Sequenzy email blocks. Use `styles` for per-block background, background opacity, text color, padding, border radius, border width, and border color. Top-level style aliases such as `backgroundColor`, `backgroundOpacity`, `borderColor`, `borderWidth`, and `borderRadius` are also accepted and saved under `styles`. Use this for editor-compatible content, including conditional and repeat blocks. Repeat blocks use { type: 'repeat', source: 'items', itemAlias: 'item', children: [...] }. | |
| replyTo | No | Set reply-to using an existing reply profile email address for this company. | |
| replyProfileId | No | Set reply-to using a reply profile ID for this company. | |
| campaignData | No | Set campaign-scoped JSON data for repeat blocks and personalization. | |
| computedLists | No | Set computed list definitions derived from campaignData at send time. | |
| labels | No | Replacement label names. Send an empty array to clear labels. Missing labels are created automatically. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| campaign | No | The campaign record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutation (readOnlyHint=false) but not destructive (destructiveHint=false). The description adds the constraint 'draft campaign', which is useful behavioral context. However, it does not disclose permissions, side effects, or what happens to unspecified fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (4 words) but lacks critical information such as state requirements. It is under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (12) and nested objects, the description is too minimal. It fails to mention the draft-only constraint explicitly and does not explain global behavior. Output schema exists but description does not leverage it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with parameter descriptions. The tool description adds no additional meaning beyond the schema; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and the resource 'draft campaign', distinguishing it from create/delete/schedule tools. However, it does not explicitly differentiate from other update tools (e.g., update_ab_test_variant) beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention that it is only for draft campaigns, nor does it exclude use for non-draft campaigns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_conversation_statusAInspect
Open or close a conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| conversationId | Yes | Conversation ID. | |
| status | Yes | New conversation status. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| conversation | No | The inbox conversation record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false (mutation) and destructiveHint=false (not destructive). The description adds that the tool changes status between 'open' and 'closed', which is a state change. However, it does not disclose side effects (e.g., whether closing affects replies) or behavior on already-matching status. Since annotations carry the main burden, the description adds modest value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded and efficient. While brief, it earns its place by conveying the core action. A minor deduction for lacking structure (e.g., no bullet points or sections), but it is concise enough.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, clear enum) and existence of an output schema, the description is adequately complete. It covers the primary function. However, it could mention that the action is a state toggle or that conversationId is required. Still, for a straightforward operation, it suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already fully describes the parameters (companyId optional, conversationId required, status enum). The description merely restates the enum values ('open' or 'close'). It adds no additional semantics like format constraints or default behavior for companyId.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Open or close') and explicitly names the resource ('conversation'). It distinguishes from sibling tools like 'mark_conversation_read' (which changes read status, not open/close) and 'reply_to_conversation' (which adds a message).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, conditions (e.g., conversation must be open to close it), or scenarios where this tool is inappropriate. Given siblings like 'mark_conversation_read' or 'get_conversation', some context would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_landing_pageAInspect
Edit a landing page's name, slug, or full content. Provide at least one update field.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| landingPageId | Yes | Landing page ID. | |
| name | No | Landing page name. | |
| slug | No | Landing page URL slug. It will be normalized and made unique within the company. | |
| content | No | Complete Sequenzy landing page content JSON. Use this when replacing the page structure. The content must be the editor-compatible landing page schema with version, template, seo, theme, and blocks. Landing pages must include exactly one footer block and at most one form block. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| landingPage | No | The landing page record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-destructive write operation. The description adds the constraint 'Provide at least one update field' but does not disclose side effects, permissions, or reversibility beyond what annotations provide. Some useful context but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence, 13 words) and front-loaded, delivering essential information without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 params, nested objects, output schema, annotations), the description is fairly complete. It explains the slug normalization and the need for at least one update. However, it could clarify whether content updates require the full JSON or allow partial updates, and confirm that updating one field preserves others.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions (100% coverage). The description adds meaning by stating 'Provide at least one update field' and hinting at slug normalization and uniqueness within the company, which goes beyond the schema's text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool edits a landing page's name, slug, or full content, with a requirement to provide at least one update field. It distinguishes from siblings like update_landing_page_domain_settings by specifying editable fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides usage by requiring at least one update field, but does not explicitly contrast with create, delete, or publish siblings. The context is clear enough for an agent to infer when to update vs. other actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_landing_page_domain_settingsAInspect
Update landing page domain settings. Provide domain to replace the custom domain, verify true to refresh verification, or both.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| domain | No | Replacement custom domain. | |
| verify | No | Refresh domain verification after any domain update. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| landingPage | No | The landing page record returned by Sequenzy. |
| domain | No | Landing page domain. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate open world hints, but the description does not disclose side effects (e.g., DNS changes) or authorization needs. It states actions but not consequences of verification failure or domain replacement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with a clear, front-loaded structure. No redundant information; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main use cases (domain replace, verify, both) and references optional parameters. With an output schema present, the description is sufficiently complete for a simple update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; the description adds marginal value by clarifying 'replace' and 'refresh' but essentially reiterates the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update landing page domain settings' and specifies the two actions: replacing custom domain or refreshing verification. It distinguishes from sibling tools like 'connect_landing_page_domain' which is about initial connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'connect_landing_page_domain'. The description implies usage for updating existing settings but does not provide context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_listAInspect
Update a subscriber list's name, description, or privacy. Only the provided fields are changed.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| listId | Yes | Subscriber list ID to update. | |
| name | No | New list name. | |
| description | No | New list description. Pass null to clear it. | |
| isPrivate | No | Whether the list is private. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| list | No | The list record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by disclosing the partial update behavior ('Only the provided fields are changed'). Annotations already provide readOnlyHint=false and destructiveHint=false, so the description complements them well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence that is front-loaded with the verb and resource. No wasted words; every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters all well-documented, an output schema exists, and annotations cover safety, the description is complete. It covers purpose, behavior, and parameter usage adequately for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, each parameter is already documented. The description adds the semantic that only provided fields change, which ties the parameters together and explains the update behavior. This goes beyond individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Update' and the resource 'subscriber list', and specifies the exact fields (name, description, privacy) that can be updated. Among sibling tools like create_list and delete_list, this description distinguishes itself by specifying the update operation on the list resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes that 'Only the provided fields are changed', which guides the agent on partial updates. However, it does not provide explicit when-to-use or when-not-to-use guidance compared to alternatives like create_list, which would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_segmentAInspect
Update a segment's name and/or filter rules. Use the same filters plus filterJoinOperator or nested root shapes as create_segment; providing filters or root replaces the segment's existing rules.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| segmentId | Yes | Segment ID to update. | |
| name | No | New segment name. | |
| filterJoinOperator | No | How top-level filters combine. Use `"and"` to require every filter or `"or"` to match any filter. | |
| filters | No | Replacement segment filters. Same shape and validation rules as create_segment. Mutually exclusive with `root`. | |
| root | No | Replacement nested filter root. Mutually exclusive with `filters` and `filterJoinOperator`. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| segment | No | The segment record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=false and destructiveHint=false, so description adds context: providing filters/root replaces existing rules, which is important for understanding side effects. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that are front-loaded and contain no unnecessary information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, nested objects, full schema coverage, output schema present), the description covers core behavior and references create_segment for details. It is complete enough for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds cross-reference to create_segment but doesn't significantly extend meaning beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a segment's name and/or filter rules' specifying the verb and resource. It distinguishes from siblings like create_segment by implying it's for existing segments, and from delete_segment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use (to update name/filters) and mentions the similarity to create_segment for filter shapes. It doesn't explicitly state when not to use, but for an update tool this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_sequenceAInspect
Update an existing sequence. To target a specific step, use the emailId or nodeId returned in get_sequence.sequence.emails. You can also update enrollmentMode and enrollmentFieldPath for event-triggered matching-field enrollment. When inserting an if/else branch, include steps for every branch arm and elseSteps so the branch is usable immediately. Branch conditions support tags, lists, saved segments, custom events, clicked links, and subscriber field comparisons.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| sequenceId | Yes | Sequence ID | |
| name | No | Sequence name | |
| enrollmentMode | No | Updated sequence re-entry mode. 'matching_field' is only valid for event-based sequence triggers. | |
| enrollmentFieldPath | No | Dot-path event property used by enrollmentMode='matching_field', such as 'order.id' or 'product.providerVariantId'. Omit to leave unchanged. Use clearEnrollmentFieldPath to clear it. | |
| clearEnrollmentFieldPath | No | Set true to clear enrollmentFieldPath without sending a nullable schema value. | |
| stopCondition | No | Update the sequence auto-stop condition. Example: { type: 'has_tag', value: 'customer' } ends the sequence when the subscriber has that tag. Use { type: 'removed_from_list', value: 'list_123' } to stop when they leave a list, or { type: 'none', value: null } to clear it. | |
| branch | No | Insert an if/else branch into an existing sequence. The branch is inserted after afterNodeId and creates an if path plus an else fallback path. Use get_sequence first to choose afterNodeId. Each branch condition should include steps, and elseSteps is required unless allowEmptyPaths is true. Conditions support tags, lists, saved segments, events, clicked links, and field comparisons. Use activityScope for event_received and link_clicked checks. | |
| emails | No | Updated sequence emails. If you omit emailId/nodeId, items are matched by existing step order. | |
| steps | No | Alias for emails. Supports the same fields and matching rules. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| sequence | No | The sequence record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, destructiveHint=false) indicate mutation is expected. Description confirms update behavior but does not disclose idempotency, partial update semantics, or error conditions. Lacks elaboration on what happens to unprovided fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single focused paragraph, front-loading the purpose. It efficiently covers key usage points without redundancy. Could benefit from bullet points for complex branches, but remains clear and compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers core features but omits mention of several important parameters (e.g., name, stopCondition, emails/steps arrays) that are present in the schema. With output schema existing, return values not needed. However, the description does not fully contextualize the tool's capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so schema documents all parameters. Description adds significant value: explains emailId/nodeId targeting, enrollmentMode constraints, stopCondition example, and branch insertion requirements including elseSteps necessity. This context aids correct parameter use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Update an existing sequence' clearly. It lists key updateable aspects (steps, enrollment mode, branch insertion) but does not cover all possible fields like name or stopCondition, which are in the schema. Distinguishes from create_sequence and get_sequence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides specific usage hints: use emailId/nodeId from get_sequence, and include steps/elseSteps for branch insertion. However, no explicit guidance on when not to use or alternatives (e.g., generate_sequence for creating a new sequence).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_subscriberAInspect
Update an existing subscriber's attributes or tags
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| No | Subscriber email address. Provide email or externalId to identify the subscriber. | ||
| externalId | No | Customer-owned subscriber ID. Provide email or externalId to identify the subscriber. | |
| attributes | No | Attributes to update | |
| addTags | No | Tags to add | |
| removeTags | No | Tags to remove |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| subscriber | No | The subscriber record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, which imply a non-destructive write operation. The description adds no additional behavioral context (e.g., which fields are overwritten, no side effects, no output description).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core functionality without extraneous words. It is well-structured and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and the schema fully documents all parameters, the description is complete for this straightforward update tool. It covers the essential action and objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are described in the schema. The description does not add any meaning beyond what the schema provides, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'existing subscriber', specifying the actions as 'attributes or tags'. It is distinct from sibling tools like 'add_subscriber' (create) and 'remove_subscriber' (delete).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., when to update vs. add or remove subscribers). The description lacks any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_tagAInspect
Update a tag's color. System tags cannot be updated.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| tagId | Yes | Tag ID. Use list_tags to find tag IDs. | |
| color | Yes | New tag color. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| tag | No | The tag record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description adds the useful constraint about system tags. But no further disclosure of potential side effects or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action, and every sentence provides essential information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a complete input schema, output schema, and annotations, the description is sufficiently complete for this simple tool, covering the main constraint. Minor gap: no mention of return value, but output schema covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no additional parameter meaning beyond what is in the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a tag's color', specifying the exact action and resource, and distinguishes from sibling tools like create_tag, delete_tag, and list_tags. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-not-to-use guidance by stating 'System tags cannot be updated'. However, lacks explicit guidance on when to use this tool versus alternatives beyond the restriction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_templateAInspect
Update an existing template. At least one of name, subject, html, blocks, or labels is required, and only those update fields are accepted.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| templateId | Yes | Template ID | |
| name | No | Template name | |
| subject | No | Email subject line | |
| html | No | Email HTML content. Mutually exclusive with `blocks`. | |
| blocks | No | Sequenzy email blocks. Use `styles` for per-block background, background opacity, text color, padding, border radius, border width, and border color. Top-level style aliases such as `backgroundColor`, `backgroundOpacity`, `borderColor`, `borderWidth`, and `borderRadius` are also accepted and saved under `styles`. Use this for editor-compatible content, including conditional and repeat blocks. Repeat blocks use { type: 'repeat', source: 'items', itemAlias: 'item', children: [...] }. | |
| labels | No | Replacement label names. Send an empty array to clear labels. Missing labels are created automatically. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| template | No | The email template record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide minimal clues (readOnlyHint=false), so description carries burden. It explains that only listed fields are accepted and at least one is required, implying mutation. However, it doesn't discuss side effects, permissions, or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with purpose. Every sentence adds necessary information without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema (7 params, 100% coverage, output schema present) and lack of nested objects, the description adequately covers update functionality. It could mention handling of existing values, but is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters (100% coverage), so baseline is 3. The description adds value by stating that only the five listed fields can be updated and at least one is needed, but does not elaborate on format or constraints beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing template' with specific verb and resource. It distinguishes from sibling tools like create_template and delete_template. The mention of required fields further clarifies purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that at least one of the five fields is required, providing a clear condition for use. However, it does not offer explicit guidance on when not to use this tool or compare to alternatives like update_campaign.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_transactional_emailAInspect
Update a transactional email by ID or slug. At least one of name, enabled, subject, previewText, html, or blocks is required. Use html or blocks to replace the linked email body.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| idOrSlug | Yes | Transactional email ID or API slug, for example `welcome-email`. | |
| name | No | Transactional email name. | |
| enabled | No | Whether this transactional email can be sent. | |
| subject | No | Email subject line. | |
| previewText | No | Email preview text. | |
| html | No | Email HTML content. Mutually exclusive with `blocks`. | |
| blocks | No | Replacement Sequenzy email blocks. Use `styles` for per-block background, background opacity, text color, padding, border radius, border width, and border color. Top-level style aliases such as `backgroundColor`, `backgroundOpacity`, `borderColor`, `borderWidth`, and `borderRadius` are also accepted and saved under `styles`. Mutually exclusive with `html`. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| transactional | No | The transactional email record returned by Sequenzy. |
| appUrls | No | Dashboard URLs for relevant Sequenzy resources. |
| url | No | Primary dashboard URL for this result. |
| settingsUrl | No | Company settings URL when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description aligns with annotations (readOnlyHint false, destructiveHint false) by indicating a mutation operation that is not destructive. It adds 'replace the linked email body' for html/blocks, which is useful. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with clear front-loading of purpose. Every sentence adds value: purpose, requirement, and a clarification. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are covered. Description explains the core behavior and key constraints. It does not explicitly state that it's a partial update, but that is typical for update operations. Given the richness of siblings and schema, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). The description adds extra semantics: clarifying that idOrSlug accepts both ID and slug (with example), and explicitly stating the mutual exclusivity of html and blocks, which is not fully captured by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'update' and the resource 'transactional email'. It specifies identification by ID or slug and lists the updatable fields. The purpose is distinct from create, get, delete, and list siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a key constraint: at least one of the optional fields is required. It also clarifies the mutual exclusivity of html and blocks. However, it does not explicitly compare to alternatives (e.g., when to update vs. create) or state prerequisites like the email must exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_webhookAInspect
Update an outbound webhook endpoint's name, URL, subscribed events, or status (enabled/disabled). Providing events replaces the existing event list.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| webhookId | Yes | Webhook endpoint ID. | |
| name | No | New webhook endpoint name. | |
| url | No | New HTTPS URL that will receive webhook events. | |
| events | No | Replacement event type subscriptions. | |
| status | No | Enable or disable deliveries to this endpoint. |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| webhook | No | The outbound webhook record returned by Sequenzy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description reveals that providing events replaces the entire event list, which is a crucial behavioral detail beyond the annotations (readOnlyHint=false, destructiveHint=false). It accurately describes the mutation (update) and non-destructive nature of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence states purpose and scope, the second adds a critical behavioral point. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and 100% parameter coverage, the description provides sufficient context for the update operation. It covers key attributes and the replacement behavior, but could mention error states or prerequisites for a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds the important clarification that 'Providing events replaces the existing event list,' which goes beyond the schema's parameter description of 'Replacement event type subscriptions.' This adds semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'update', the resource 'outbound webhook endpoint', and explicitly lists which attributes can be updated (name, URL, subscribed events, status). Also notes that providing events replaces the existing list, which distinguishes it from similar tools like create_webhook or list_webhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Usage is implied by the context of updating existing webhooks, but there is no contrast with similar operations or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
upsert_productsAInspect
Create or update products in the catalog (Commerce API, keyed by your productId, stored under the api provider). Use this to add products that are not synced from Stripe/Shopify/WooCommerce, then attach a deliverable file with attach_product_file and build a purchase sequence for them.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | No | Company ID. If not provided, uses the currently selected company. | |
| products | Yes | Products to create or update (max 100). |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | No | Whether the Sequenzy operation succeeded. |
| message | No | Human-readable status, confirmation, or next-step message. |
| note | No | Additional context about the result. |
| items | No | Fallback array wrapper used only when a tool returns a bare array. |
| value | No | Fallback object wrapper used only when a tool returns a non-object value. |
| products | No | List of product records returned by Sequenzy. |
| created | No | Number of products created. |
| updated | No | Number of products updated. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it creates or updates, matching the readOnlyHint=false annotation. However, it does not elaborate on behavioral details like whether updates are full replacements or partial merges, or any side effects. Annotations already flag mutation, so the description adds limited 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no extra words. First sentence defines action and context; second sentence provides usage guidance and links to related tools. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (removing need to explain return values) and comprehensive schema descriptions, the description covers purpose, usage context, and workflow. It mentions the key field and distinguishes from synced products, making it complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces that productId is the key for upserts, but this is already in the schema description. No new parameter semantics are added beyond context about syncing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create or update products' and specifies the resource as 'catalog'. It distinguishes from synced products by explicitly mentioning 'not synced from Stripe/Shopify/WooCommerce', differentiating it from sibling tool 'sync_products'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to add products that are not synced' and provides workflow guidance: 'then attach a deliverable file with attach_product_file and build a purchase sequence for them.' Does not explicitly state when not to use, but positive guidance is strong.
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.
113 tool updates
v0.1.0- First observed
add_ab_test_variant - First observed
add_subscriber - First observed
add_subscribers_to_list - First observed
add_website - First observed
attach_product_file - First observed
cancel_campaign - First observed
cancel_sequence_enrollments - First observed
cancel_team_invitation - First observed
check_website - First observed
connect_landing_page_domain - First observed
create_ab_test - First observed
create_api_key - First observed
create_audience_sync - First observed
create_campaign - First observed
create_company - First observed
create_landing_page - First observed
create_list - First observed
create_segment - First observed
create_sequence - First observed
create_tag - First observed
create_template - First observed
create_transactional_email - First observed
create_webhook - First observed
delete_ab_test - First observed
delete_ab_test_variant - First observed
delete_audience_sync - First observed
delete_campaign - First observed
delete_landing_page - First observed
delete_list - First observed
delete_product - First observed
delete_segment - First observed
delete_sequence - First observed
delete_tag - First observed
delete_template - First observed
delete_webhook - First observed
disable_sequence - First observed
duplicate_campaign - First observed
enable_sequence - First observed
enroll_subscribers_in_sequence - First observed
generate_email - First observed
generate_sequence - First observed
generate_subject_lines - First observed
get_ab_test - First observed
get_ab_test_stats - First observed
get_account - First observed
get_app_urls - First observed
get_campaign - First observed
get_campaign_stats - First observed
get_company - First observed
get_conversation - First observed
get_email_send - First observed
get_integration_guide - First observed
get_landing_page - First observed
get_segment_count - First observed
get_sequence - First observed
get_sequence_stats - First observed
get_stats - First observed
get_subscriber - First observed
get_subscriber_activity - First observed
get_template - First observed
get_transactional_email - First observed
invite_team_member - First observed
list_ab_tests - First observed
list_ad_accounts - First observed
list_audience_syncs - First observed
list_campaigns - First observed
list_conversations - First observed
list_landing_pages - First observed
list_lists - First observed
list_products - First observed
list_segments - First observed
list_sequences - First observed
list_tags - First observed
list_team_members - First observed
list_templates - First observed
list_transactional_emails - First observed
list_webhook_deliveries - First observed
list_webhooks - First observed
list_websites - First observed
mark_conversation_read - First observed
pause_campaign - First observed
publish_landing_page - First observed
remove_product_file - First observed
remove_subscriber - First observed
remove_subscribers_from_list - First observed
replay_webhook_delivery - First observed
reply_to_conversation - First observed
restart_ab_test - First observed
resume_campaign - First observed
schedule_campaign - First observed
search_subscribers - First observed
select_company - First observed
send_email - First observed
send_test_email - First observed
sync_audience_now - First observed
sync_products - First observed
test_webhook - First observed
unpublish_landing_page - First observed
update_ab_test_variant - First observed
update_audience_sync - First observed
update_campaign - First observed
update_conversation_status - First observed
update_landing_page - First observed
update_landing_page_domain_settings - First observed
update_list - First observed
update_segment - First observed
update_sequence - First observed
update_subscriber - First observed
update_tag - First observed
update_template - First observed
update_transactional_email - First observed
update_webhook - First observed
upsert_products
TDQS
Scored across 113 tools
Every tool targets a distinct resource and action, even across 113 tools. Despite the large number, there is no ambiguity between tools - e.g., create_campaign vs create_sequence vs create_template are clearly different, and even similar operations like send_test_email vs send_email are well-differentiated. The deprecated generate_sequence is explicitly marked, reducing confusion.
The naming follows a consistent verb_noun pattern with snake_case throughout, using standard verbs like list_, get_, create_, update_, delete_. There are a few minor deviations such as generate_sequence (deprecated), check_website, sync_audience_now, and get_app_urls, but these are understandable and do not break the overall pattern.
With 113 tools, this is an extreme mismatch for a typical MCP server. Even for a comprehensive marketing automation platform, the sheer number is overwhelming and will likely cause agents to misselect or become confused. The tool count far exceeds the 50+ threshold for a low score, and the breadth is not justified by a single cohesive purpose.
The tool surface covers a wide range of marketing automation domains (campaigns, sequences, subscribers, lists, segments, tags, products, landing pages, A/B tests, conversations, webhooks, team, etc.), but there are notable gaps: several entities lack individual get-by-ID tools (e.g., no get_segment, get_product, get_website, get_webhook, get_tag), and some operations like update_tag only allow color changes, not name changes. These gaps may force agents to rely on list endpoints or workarounds.
Maintenance
Related MCP Connectors
- SendinelOAuthai.sendinel
AI-controlled email ops for campaigns, contacts, segments, analytics, and sending.
An AI marketing team for any business: draft campaigns, read results, manage contacts.
Mailchimp engagement intelligence for AI agents: campaign analytics and audience insights.
Manage email campaigns, contacts and deliverability analytics in RuSender from an AI assistant.
Related MCP Servers
- AlicenseAqualityAmaintenanceFull email marketing platform for AI assistants — 32 MCP tools for campaigns, contacts, automations, A/B testing, AI content, multi-channel messaging, deliverability monitoring, and analytics.57185 npm1MIT
- FlicenseBqualityDmaintenanceEnables management of email campaigns, subscribers, lists, segments, journeys, templates, transactional email, and client/account settings through the Campaign Monitor API via natural language.1001-
- FlicenseNot gradedqualityDmaintenanceEnables interaction with the Mailchimp API for managing campaigns, lists, templates, reports, and automations through natural language.3-

Mailjet MCP Serverofficial
AlicenseNot gradedqualityBmaintenanceEnables AI agents to interact with Mailjet's contact, campaign, segmentation, statistics, and workflow APIs for managing email marketing operations through natural language.123 npm11Apache 2.0