Skip to main content
Glama
Sequenzy

Sequenzy MCP Server

Official
by Sequenzy

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/setup

The 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/mcp

ChatGPT and the OpenAI plugin directory use the reviewed hosted surface:

https://api.sequenzy.com/v1/mcp/openai

That 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:

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: npx

  • Args: -y @sequenzy/mcp

  • Required env: SEQUENZY_API_KEY=seq_user_your_key_here

Optional environment variables:

  • SEQUENZY_API_URL - Sequenzy API base URL. Defaults to https://api.sequenzy.com.

  • SEQUENZY_APP_URL - Sequenzy dashboard base URL used by app URL helpers. Defaults to https://sequenzy.com.

Claude Desktop

Add this to your Claude Desktop config:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %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/mcp

On 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/mcp

For 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 list

Manual 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/mcp

After 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.json

  • Windows: %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

  1. Open the Sequenzy dashboard.

  2. Use the MCP setup flow to create a personal key, or open Settings -> API Keys to create a company key.

  3. Choose a permission preset or the exact custom scopes the integration needs.

  4. 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

Get account info, available companies, current key permissions, and the API Keys management URL.

select_company

Set the active company for future tool calls.

get_app_urls

Build dashboard URLs for campaigns, landing pages, sequences, emails, settings, subscription management, domains, and sent email details. settingsTab: "billing" resolves to Account -> Subscription.

create_company

Create a new company or brand.

get_company

Read company details, product info, brand context, localization, reply-tracking settings, current From/Reply-To defaults, and the effective read-only emailBranding entitlement with plan/status reason and subscription URL; STO is explicitly identified as campaign-only.

update_company

Edit product info, brand context, email theme, reply tracking, and account-wide From/Reply-To profile defaults or names.

get_sync_rules

Read the company's event-to-tag rules and whether it uses the inherited platform preset.

update_sync_rules

Replace all sync rules; pass [] to disable them or null to opt into the SaaS/ecommerce platform preset.

get_shopify_automation_settings

Read browse-abandonment, cart-abandonment, and price-drop settings for the connected Shopify store.

update_shopify_automation_settings

Partially update Shopify automation settings or reset an individual section to its platform defaults.

create_api_key

Create a company API key and return its one-time secret on standard MCP; omitted from the OpenAI-reviewed route.

request_api_key_handoff

Prepare an owner-reviewed create/rotation URL when the active key cannot manage API keys itself.

list_api_keys

List company API keys as non-secret metadata for safe identification and cleanup.

update_api_key

Rename a company API key or replace its permission preset or scopes without changing the key value.

revoke_api_key

Permanently revoke an exact company API key by ID after checking it with list_api_keys.

delete_api_key

Compatibility alias for revoke_api_key.

list_websites

List sending domains with stored aggregate, SPF, DKIM, and MAIL FROM status.

add_sending_domain

Add a sending domain and return its cohort-specific DNS setup records.

add_website

Compatibility alias for add_sending_domain.

check_website

Read a sending domain's stored SPF, DKIM, MAIL FROM, and aggregate verification details.

verify_sending_domain

Run a fresh sending-domain DNS/provider verification and return current status and diagnostics.

list_integrations

List connected integrations with connection and sync health, without returning credentials.

get_sending_status

Diagnose active, paused, or suspended sending, including enforcement denominators, review gates, and remediation steps.

resume_sending

Restore an eligible hard-bounce pause after explicitly confirming the list has been sanitized.

get_tracking_settings

Read account-wide and Transactional API open/click defaults, unsubscribe, attribution, UTM, click-domain, reply-tracking, and double-opt-in settings.

update_tracking_settings

Update account-wide and Transactional API tracking defaults, attribution, UTM, and account-wide double opt-in.

get_integration_guide

Get framework-specific integration examples.

get_integration

Inspect one connected integration, its event wiring, list targeting, recent activity, and recommendations.

list_integration_capabilities

Compare provider capabilities whether or not they are connected.

connect_integration

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.

get_event_schema

Inspect published event payload examples, property paths, types, and merge tags by provider.

list_integration_activity

Read the retained integration-specific webhook and sync activity log.

set_integration_sync_enabled

Enable or disable bulk imports and backfills while leaving live webhooks connected.

set_integration_list_targeting

Choose which lists contacts created by a supported integration join on future provider writes.

sync_integration

Queue payment revenue, Supabase users, or a PostHog/Segment event-history import using the saved integration configuration.

get_integration_pixel

Read Shopify's live pixel/configuration state and distinguish confirmed dark events from an unknown read.

activate_integration_pixel

Install or repoint Shopify's storefront pixel; idempotent when it is already current.

list_web_tracking_keys

List publishable website-tracking keys, origin restrictions, usage state, and install snippets.

get_web_tracking_key

Get one website-tracking key with its exact install snippet and ingest endpoint.

create_web_tracking_key

Create a publishable tracking key for a non-Shopify storefront or website.

update_web_tracking_key

Rename, restrict, revoke, or re-enable a website-tracking key.

delete_web_tracking_key

Permanently delete a website-tracking key after its snippet has been removed.

list_sender_profiles

List sender and reply-to profiles, defaults, and sending-domain readiness.

update_sender_profile

Rename one sender or reply-to profile without changing the account defaults.

delete_sender_profile

Permanently delete an unused sender profile, with guards for live sending surfaces and the last remaining sender.

get_notification_preferences

Read the current user's per-company account notification settings and supported modes, including the Monday weekly report.

update_notification_preferences

Update the current user's account notification delivery modes, including weekly-report opt-out, without affecting teammates.

render_email

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_subscriber

Add one subscriber; status is creation-only, so use update_subscriber for an existing contact.

create_subscriber_import

Queue up to 5,000 full CRM records with an optional retry-safe idempotencyKey; enabled email-hygiene checks continue separately after ingestion.

get_subscriber_import

Read progress, row outcome counts, and failure summaries for a queued import.

update_subscriber

Update native profile and phone fields, SMS consent, attributes, tags, or global status.

remove_subscriber

Unsubscribe while preserving suppression history, or permanently delete only with hardDelete: true.

get_subscriber

Fetch subscriber details by email or external ID.

search_subscribers

Search by query, tags, list, status, segment, or one custom attribute, with automatic or resumable pagination.

trigger_subscriber_event

Emit one custom event exactly as an integration would, applying sync rules and matching sequence triggers.

trigger_subscriber_events

Emit several ordered custom events for one subscriber.

import_subscriber_events

Import up to 25 source-identified events across contacts; silent history requires every row for a contact to be over an hour old.

bulk_add_subscriber_tags

Add tags to up to 500 existing subscribers; requires subscribers:tag and may also require tags:write.

bulk_remove_subscriber_tags

Remove tags from up to 500 existing subscribers; requires subscribers:tag or subscribers:write.

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_products

List synced products from Stripe, Shopify, WooCommerce, manual, or Commerce API data.

upsert_products

Create or update up to 100 Commerce API products keyed by your product ID.

delete_product

Delete a product previously pushed through the Commerce API.

attach_product_file

Attach a hosted or locally uploaded delivery file to a product.

remove_product_file

Remove an attached product delivery file.

sync_products

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_image_asset

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_tags

List all tags.

create_tag

Create a tag definition with an optional color.

update_tag

Update a tag color.

delete_tag

Delete a tag and remove it from subscribers.

list_lists

List subscriber lists.

create_list

Create a subscriber list.

update_list

Rename or describe a subscriber list.

delete_list

Delete a subscriber list.

add_subscribers_to_list

Add up to 500 subscribers to a list from an email array.

remove_subscribers_from_list

Remove up to 500 subscribers from a list.

list_segments

List saved segments and counts.

create_segment

Create nested or same-element array-filtered segments.

update_segment

Update segment name, filters, root group, or join operator.

delete_segment

Delete a segment (requires segments:delete).

get_segment_count

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_not

  • tag: contains, not_contains, is_empty, is_not_empty

  • email: contains, not_contains

  • emailProvider, list: is, is_not, is_empty, is_not_empty

  • firstName, lastName: contains, not_contains, is_empty, is_not_empty

  • added: less_than, more_than

  • attribute: is, is_not, is_empty, is_not_empty, gte, lte, gt, lt, contains, not_contains

  • event, email engagement fields: is, is_not, at_least, less_than_count

  • emailBounced: also supports is_temporary_bounce, is_permanent_bounce

  • stripeProduct: is, is_not, at_least, less_than_count

  • stripeCurrentProduct, stripeTrialProduct: is, is_not, gte, lte, gt, lt

  • commerceProduct: 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_audience_syncs

List segment-to-audience syncs with schedule and last sync status.

list_ad_accounts

List the Meta ad accounts available for syncing.

create_audience_sync

Push a segment to a Meta custom audience on a schedule.

update_audience_sync

Change sync frequency (hourly, daily, weekly) or pause/resume.

delete_audience_sync

Remove a sync mapping; the Meta audience itself is kept.

sync_audience_now

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

List templates with localization status, label and isTemplate filtering, and pagination.

get_template

Read template details, content, and localized variants.

create_template

Create templates from a prompt, HTML, or Sequenzy blocks; use isTemplate: true to save a reusable master design.

update_template

Update template metadata, inbox preview text, labels, HTML, or blocks; mark or unmark a master with isTemplate.

set_template_localization

Create or replace a caller-supplied localized variant.

sync_template_localizations

Queue AI translation for selected or all enabled non-primary locales.

delete_template

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_email_components

List saved sections and footers, optionally limited to pinned defaults.

get_email_component

Read one component's blocks, metadata, version, and default-slot state.

get_default_email_component

Read the component currently pinned to a default slot such as footer.

set_default_email_component

Create or replace the company default footer used by newly built block emails.

create_email_component

Save a reusable section or footer from a block list.

update_email_component

Update component metadata or replace its blocks and increment its version.

delete_email_component

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_ab_tests

List A/B tests and variants, optionally scoped by sequence.

get_ab_test

Get effective settings, variants, localization status, and sequence-step copy.

get_ab_test_stats

Get aggregate and per-variant stats.

restart_ab_test

Restart a stopped or completed A/B test.

select_ab_test_winner

Select a campaign test winner and queue remaining delivery.

update_ab_test

Update campaign or sequence winner-selection settings.

update_ab_test_variant

Update campaign draft or sequence variant copy.

create_ab_test

Create a campaign test or convert a sequence email step.

add_ab_test_variant

Add a variant to an existing A/B test.

delete_ab_test_variant

Delete a draft A/B test variant.

delete_ab_test

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_campaigns

List paginated campaigns by status or label, including reviewer feedback and delivery-pacing fields for account-wide STO audits.

get_campaign

Get details, stats, reviewer feedback, and recorded delivery pacing for a campaign.

get_campaign_audience

Resolve saved targeting, missing references, a plain-language summary, and live recipient count.

list_campaign_goals

List the conversion goals persisted for one email campaign (SMS is unsupported).

create_campaign_goal

Add an event, subscriber-attribute, or tag-applied email-campaign conversion goal.

update_campaign_goal

Update a persisted email-campaign conversion goal.

delete_campaign_goal

Delete a persisted email-campaign conversion goal.

list_email_sends

Search recent delivery history with resource IDs and URLs, optionally scoped to one sequence step. Successful live-test sends are omitted.

get_email_send

Inspect a queued, test, sent, suppressed, or failed delivery by durable email-send ID.

list_recipient_suppressions

List associated suppressed recipients, including protected global invalid addresses and complaints.

get_recipient_suppression

Check local bounce, complaint, email-hygiene, and regional SES suppression for one exact recipient.

remove_recipient_suppression

Remove a workspace soft-bounce escalation while preserving global, hard-bounce, and complaint protections.

create_campaign

Create a campaign with content, data, and optional From/Reply-To identity overrides.

update_campaign

Update a draft campaign, including content, data, identities, audience, and persisted STO configuration.

schedule_campaign

Schedule or reschedule a campaign, optionally overriding STO and its 1-24 hour delivery window.

send_test_email

Send a test email to one address.

render_email

Render exact email-safe HTML and report unresolved tags, including typos hidden by defaults.

cancel_campaign

Cancel a scheduled or sending campaign.

pause_campaign

Pause a sending campaign.

resume_campaign

Resume a paused campaign, optionally spreading delivery over time.

delete_campaign

Delete a campaign.

duplicate_campaign

Duplicate a campaign into a new draft.

resend_campaign_to_non_openers

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_forms

List saved forms with their server-managed audience settings, content blocks, and public action URLs.

create_form

Create and publish a saved form with standard email/name fields, audience settings, theme, and success behavior.

update_form

Update a saved form, including its complete ordered block array and typed custom fields.

get_form_embed

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_popups

List saved popups with status and engagement stats, optionally including full content.

get_popup

Get one popup's blocks, trigger, targeting, schedule, frequency, theme, and published embed code.

create_popup

Create a popup from a starting template, published by default, and return its deployment script.

update_popup

Partially update popup copy, audience, behavior, theme, blocks, or publication status.

get_popup_embed

Return secret-free HTML, React/Next.js, WordPress, and Shopify embed snippets.

duplicate_popup

Copy a popup into a draft with independent engagement counters.

delete_popup

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

List landing pages with status, metrics, content, and URLs.

get_landing_page

Get landing page details, builder content, metrics, and published URLs.

render_landing_page

Return a signed 24-hour visitor preview without publishing, counting views, or collecting signups.

create_landing_page

Create a draft landing page from default template content or JSON.

update_landing_page

Edit a landing page name, slug, or full editor-compatible content.

publish_landing_page

Publish a landing page, optionally saving edits first.

unpublish_landing_page

Return a landing page to draft status, optionally saving edits first.

duplicate_landing_page

Duplicate a landing page into a new draft with a unique slug.

delete_landing_page

Delete an unpublished landing page.

connect_landing_page_domain

Connect a custom landing page domain and return DNS setup details.

update_landing_page_domain_settings

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

List sequences with dashboard status, search, label, limit, and offset filters.

get_sequence

Get sequence details, A/B variant IDs and block counts with ab_tests:read, nodes, edges, linked copy, and the sequence sending window.

list_sequence_enrollments

List contact enrollments with pagination and accurate list/tag/event/time-based entry attribution. Live sequence tests do not create enrollments.

send_sequence_test_email

Send one saved action_email step to 1-10 reviewers; A/B steps are inspected per variant.

create_sequence

Create a blank dashboard draft or an AI-generated/explicit-step sequence.

update_sequence

Update identity, settings, enrollment, existing steps, branch logic, or insert linear steps.

update_sequence_node

Type-aware patch of one existing sequence node.

update_sequence_nodes

Atomically patch multiple existing sequence nodes.

insert_sequence_step

Insert any typed dashboard step, including AI generation, outbound webhooks, waits, and wired branches.

edit_sequence_graph

Move, reconnect, delete, or duplicate graph nodes; reports recipients moved or completed.

simulate_sequence

Dry-run current matches, activation readiness, and an optional contact's branch path without enrolling or sending.

enable_sequence

Activate a sequence.

disable_sequence

Freeze a sequence, blocking new enrollments and holding current recipients.

duplicate_sequence

Create an independent draft copy of the graph, emails, and sequence A/B tests.

archive_sequence

Move a sequence into the dashboard archive and stop new enrollments.

unarchive_sequence

Restore an archived sequence as a disabled draft.

list_sequence_goals

List the event, subscriber-attribute, and tag-applied conversion goals persisted for a sequence.

create_sequence_goal

Add an event, subscriber-attribute, or tag-applied conversion goal.

update_sequence_goal

Update a persisted sequence conversion goal.

delete_sequence_goal

Delete a persisted sequence conversion goal.

get_sequence_inbound_webhook

Read the inbound URL, setup state, sample, and mapping on standard MCP; the OpenAI route removes the credential-bearing URL.

configure_sequence_inbound_webhook

Configure the endpoint, field mapping, and sample; the OpenAI route removes the credential-bearing URL from its result.

rotate_sequence_inbound_webhook_secret

Rotate an inbound sequence endpoint's secret and return its replacement URL on standard MCP; omitted from the OpenAI-reviewed route.

pause_sequence_enrollments

Stop new enrollments for an active sequence while current recipients continue.

resume_sequence_enrollments

Reopen new enrollments for an active sequence without changing current recipients.

enroll_subscribers_in_sequence

Enroll up to 500 subscribers by email, subscriber ID, or both, with retry-safe idempotency.

cancel_sequence_enrollments

Stop active or waiting enrollments by subscriber or entry-event field values.

realign_sequence_enrollments

Preview or queue moving live waits earlier to their sending-window opening.

get_sequence_enrollment_realignment

Poll an applied realignment job and read its completed result or continuation cursor.

delete_sequence

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" with listId, several listIds, or listScope: any_contact (the default) enrolls every added contact, including contacts that join no list, while any_list waits for an actual list membership.

  • trigger: "tag_added" with tagName or several tagNames; any configured tag enrolls the contact.

  • trigger: "segment_entered" plus segmentId for 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" plus eventName, inactiveDays, and optional inactivityBaseline (sequence_created_at or subscriber_created_at).

  • goal for 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 steps with Sequenzy blocks.

  • Explicit steps with 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 via waitUntil, or calendar gates via waitUntilWeekday. 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_discount step 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 scalar enrollmentFieldPath for product-, variant-, order-, or subscription-specific event automations. Array traversal with [] belongs in propertyFilters, 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

get_email_block_schema

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

list_transactional_emails

Search/filter templates and sort by delivery metrics; returns subjects and dashboard URLs.

get_transactional_email

Read a transactional email by ID or slug.

create_transactional_email

Create a transactional template from a prompt, HTML, or blocks.

update_transactional_email

Update transactional metadata or body content.

send_email

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_stats

Get overview stats for 7d, 30d, or 90d; filter by structural email type.

get_transactional_stats

Get all-time or time-scoped metrics for one saved transactional email by ID or slug.

get_campaign_stats

Get campaign performance, reply metrics, attached conversion goals, and Poll/NPS summaries.

list_poll_responses

List each respondent's latest Poll/NPS answer per block, with identity and response time.

get_sequence_stats

Get aggregate and per-step sequence performance plus live active/waiting enrollment counts by current node.

list_email_metrics

Compare campaign and sequence-step funnels, replies, conversions, and revenue, including cross-sequence steps.

list_campaign_events

List paginated raw email events for a campaign.

list_sequence_events

List paginated raw events for a sequence, optionally scoped to one email step.

get_subscriber_activity

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

List team members and pending invitations.

invite_team_member

Invite a teammate as admin or viewer, with optional billing access.

cancel_team_invitation

Cancel a pending team invitation.

list_conversations

List subscriber reply conversations with status and unread filters.

get_conversation

Read a conversation and its message history.

reply_to_conversation

Queue an outbound reply or add an internal note.

update_conversation_status

Open or close a conversation.

mark_conversation_read

Mark all messages in a conversation as read.

list_webhooks

List outbound webhook endpoints.

create_webhook

Create an endpoint and return its one-time signing secret on standard MCP; omitted from the OpenAI-reviewed route.

update_webhook

Update webhook name, URL, events, or status.

delete_webhook

Permanently delete a webhook endpoint and delivery history.

test_webhook

Send a test event to a webhook endpoint.

list_webhook_deliveries

List recent delivery attempts for a webhook.

replay_webhook_delivery

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_email

Generate branded email blocks from a prompt.

generate_sequence

Deprecated alias that persists a goal-based sequence draft.

generate_subject_lines

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

Generate SMS copy from a prompt.

get_sms_settings

Read SMS add-on readiness, credits, defaults, and provisioned numbers.

get_sms_usage

Compare sends, delivery outcomes, charged credits, last activity, and test sends by number.

update_sms_number_label

Update a number's label or per-number brand-prefix override.

release_sms_number

Permanently return a number to the carrier and free its workspace slot.

send_test_sms

Send a test message, optionally choosing a provisioned sender with fromNumberId.

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

sequenzy://dashboard

Live overview stats for the last 7 days.

sequenzy://company

Current company and localization settings.

sequenzy://campaigns/recent

Last 10 campaigns with status and basic stats.

sequenzy://subscribers/recent

Most recently added subscribers.

sequenzy://subscribers/engaged

Most active or engaged subscribers.

sequenzy://sequences

All sequences with status.

sequenzy://templates

Templates with localization status.

sequenzy://segments

Saved segments with subscriber counts.

sequenzy://tags

Tags with usage counts.

sequenzy://health

Deliverability metrics and health status.

sequenzy://email-blocks

Field reference for every email block type.

sequenzy://app-routes

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/setup

Invalid 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 npx is 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 build

MCP tool schemas must remain compatible with strict clients:

  • Tool inputSchema roots must be plain type: "object" schemas.

  • Do not publish anyOf anywhere in tool schemas.

  • Do not put oneOf, allOf, enum, or not at 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:

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 tools
add_ab_test_variantAInspect

Add a variant to a draft campaign A/B test. Variants cannot be added after the test has started.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
abTestIdYesA/B test ID
subjectYesVariant subject line.
previewTextNoVariant preview text.
blocksNoReplacement 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

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
abTestNoThe A/B test record returned by Sequenzy.
variantNoThe A/B test variant record returned by Sequenzy.

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID to add subscriber to. If not provided, uses the currently selected company.
emailNoSubscriber email address
externalIdNoCustomer-owned subscriber ID. Provide this with email when creating, or instead of email for an existing subscriber.
attributesNoCustom attributes (name, plan, etc.)
tagsNoTags to apply to the subscriber
listIdsNoList IDs to add subscriber to
statusNoInitial subscriber status: active, unsubscribed, or bounced. Defaults to active.
optInModeNoConsent 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

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
subscriberNoThe subscriber record returned by Sequenzy.

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
listIdYesSubscriber list ID to add subscribers to.
emailsYesEmail addresses to add to the list. Maximum 500 per call.
duplicateStrategyNoDuplicate strategy for existing subscribers: skip, merge, or overwrite. Defaults to skip.
enrollInSequencesNoWhether newly created subscribers should enroll in matching sequences. Defaults to false.
optInModeNoConsent mode for newly created subscribers: default, confirmed, or double_opt_in. Defaults to default.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
listNoThe list record returned by Sequenzy.
addedNoNumber of subscribers added to the list.
skippedNoNumber of subscribers skipped.

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
domainYesThe domain to add (e.g., example.com)

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
websiteNoThe sender website record returned by Sequenzy.

TDQS

A3.7/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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}}.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
productIdYesProduct ID from list_products, or your own productId for products pushed via upsert_products.
urlNoPublic http(s) URL of the file to deliver. Provide url or filePath, not both.
filePathNoLocal 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.
fileNameNoDisplay name for the file (e.g. guide.pdf). Used as {{event.download.name}}.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
productNoThe product record returned by Sequenzy.
deliveryNoThe digital delivery file record returned by Sequenzy.

TDQS

A4.4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_campaignA
Destructive
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
campaignIdYesCampaign ID to cancel.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
campaignNoThe campaign record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A4.3/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_enrollmentsA
Destructive
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
sequenceIdYesSequence ID whose enrollments should be cancelled.
subscriberIdNoSubscriber ID to cancel in this sequence. Provide subscriberId or fieldValues, not both.
fieldPathNoDot-path inside the token's stored entry event properties, such as order.id or event.id. Optional when the sequence has enrollmentFieldPath configured.
fieldValuesNoEntry 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.
dryRunNoWhen true, returns matching enrollments without cancelling them. Field-value cancellation defaults to dryRun on the API unless explicitly false.
reasonNoOptional cancellation reason stored on matched enrollment tokens.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
sequenceNoThe sequence record returned by Sequenzy.
cancelledNoNumber of enrollments cancelled.
skippedNoNumber of enrollments skipped.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A4.5/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_invitationA
Destructive
Inspect

Cancel a pending team invitation. Invitations that have already been accepted cannot be cancelled.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
invitationIdYesInvitation ID to cancel. Use list_team_members to find pending invitations.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
invitationIdNoCancelled invitation ID.

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_websiteA
Read-only
Inspect

Check if a website has been processed and is ready to use

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
domainYesThe domain to check

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
websiteNoThe sender website record returned by Sequenzy.
readyNoWhether the sender website is ready.
statusNoCurrent processing or verification status.

TDQS

A3.5/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
domainYesCustom domain, for example pages.example.com.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
landingPageNoThe landing page record returned by Sequenzy.
domainNoConnected landing page domain.

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
campaignIdYesDraft campaign ID to create the A/B test for.
nameNoOptional A/B test name.
testPercentageNoPercentage of the audience used for the test phase, from 5 to 50. Defaults to 20.
testDurationMinutesNoTest phase duration in minutes before the winner is selected, from 15 to 1440. Defaults to 240.
winnerCriteriaNoWinner selection criteria. Defaults to open_rate.
variantsNoOptional extra variants to create in addition to control variant A.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
abTestNoThe A/B test record returned by Sequenzy.

TDQS

A4.4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description 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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdYesCompany ID to create the key for
nameNoOptional name for the API key (e.g., 'Production', 'Development')

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
apiKeyNoNewly created API key. This secret is returned only once.
keyNoNewly created API key if the API response uses the short key field.

TDQS

A4.3/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
segmentIdNoExisting segment ID to sync. Mutually exclusive with `predefinedSegmentId`.
predefinedSegmentIdNoPredefined 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`.
adAccountIdYesMeta ad account ID (act_...) from `list_ad_accounts`.
audienceNameYesName for the custom audience in Meta Ads Manager.
frequencyNoHow often to re-upload the segment. Default: daily.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
audienceSyncNoThe audience sync record returned by Sequenzy.

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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)

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID to create the campaign in. If not provided, uses the currently selected company.
nameYesCampaign name
subjectNoEmail subject line. Optional when `prompt` is provided because the generated subject will be used.
trackingCodeNoOptional campaign tracking code for UTM templates. Use only when explicitly requested.
htmlNoEmail HTML content. Mutually exclusive with `blocks`.
blocksNoSequenzy 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: [...] }.
promptNoGenerate campaign blocks from a prompt. Mutually exclusive with `html`, `blocks`, and `templateId`.
styleNoPrompt generation style: minimal, branded, promotional. Only used with `prompt`.
toneNoPrompt generation tone: professional, casual, friendly. Only used with `prompt`.
templateIdNoUse a template instead of html
segmentIdNoTarget segment ID
campaignDataNoOptional campaign-scoped JSON data for repeat blocks and personalization.
computedListsNoOptional computed list definitions derived from campaignData at send time.
labelsNoOptional label names to assign. Missing labels are created automatically.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
campaignNoThe campaign record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

B3.3/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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).

ParametersJSON Schema
NameRequiredDescriptionDefault
nameNoCompany name (optional, will be extracted from domain if not provided)
domainYesThe company's website domain (e.g., example.com)

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
companyNoThe company record returned by Sequenzy.
autoSelectedNoWhether the new company was selected for subsequent MCP calls.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID to create the landing page in. If not provided, uses the currently selected company.
nameNoLanding page name. Optional; defaults to a template-specific name.
slugNoOptional URL slug. It will be normalized and made unique within the company.
templateNoOptional 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.
contentNoComplete 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

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
landingPageNoThe landing page record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID to create the list in. If not provided, uses the currently selected company.
nameYesList name
descriptionNoList description

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
listNoThe list record returned by Sequenzy.

TDQS

B3.3/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID to create the segment in. If not provided, uses the currently selected company.
nameYesSegment name
filterJoinOperatorNoHow top-level filters combine. Use `"and"` to require every filter or `"or"` to match any filter.
filtersNoArray 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.
rootNoNested filter root. Mutually exclusive with `filters` and `filterJoinOperator`.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
segmentNoThe segment record returned by Sequenzy.

TDQS

A3.9/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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:

  1. 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

  2. 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

  3. 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

  4. 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"

  5. 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.

  6. 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

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID to create the sequence in. If not provided, uses the currently selected company.
nameYesSequence name (e.g., 'User Onboarding', 'Welcome Series')
triggerYesTrigger 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)
listIdNoList ID to trigger on (for contact_added trigger). If not provided, triggers on any list.
tagNameNoTag name to trigger on (required for tag_added trigger)
segmentIdNoSegment ID to trigger on (required for segment_entered trigger). Use list_segments first to choose a saved segment.
eventNameNoEvent name to trigger on (required for event_received, inactivity, and frequency triggers)
propertyFiltersNoOptional 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.
inactiveDaysNoNumber of days of inactivity (required for inactivity trigger, must be >= 1)
inactivityBaselineNoWhen to start counting inactivity for subscribers who never had the event. Defaults to sequence_created_at.
minCountNoMinimum event count (required for frequency trigger, must be >= 1)
timeWindowDaysNoTime window in days for frequency trigger (required for frequency trigger, must be >= 1)
emailCountNoNumber of emails in the sequence (default: 5, max: 10)
goalNoWhat 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.
enrollmentModeNoSequence re-entry mode. Use 'matching_field' only for event_received triggers when duplicate active runs should be blocked per event field value.
enrollmentFieldPathNoDot-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.
stopConditionNoOptional 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.
stepsNoExplicit 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

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
sequenceNoThe sequence record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A4.9/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
nameYesTag name. Normalized to lowercase with hyphens.
colorNoTag color. Defaults to gray.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
tagNoThe tag record returned by Sequenzy.

TDQS

A4.5/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
nameYesTemplate name
subjectYesEmail subject line
htmlNoEmail HTML content. Mutually exclusive with `blocks`.
blocksNoSequenzy 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: [...] }.
labelsNoOptional label names to assign. Missing labels are created automatically.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
templateNoThe email template record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives (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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
nameYesTransactional email name.
slugNoOptional API slug used when sending by slug, for example `password-reset`. If omitted, Sequenzy generates one from the name.
subjectNoEmail subject line. Optional when `prompt` is provided because the generated subject will be used.
previewTextNoEmail preview text.
htmlNoEmail HTML content. Mutually exclusive with `blocks`.
blocksNoSequenzy 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`.
promptNoGenerate transactional email blocks from a prompt. Mutually exclusive with `html` and `blocks`.
styleNoPrompt generation style: minimal, branded, promotional. Only used with `prompt`.
toneNoPrompt generation tone: professional, casual, friendly. Only used with `prompt`.
enabledNoWhether this transactional email can be sent immediately. Defaults to true.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
transactionalNoThe transactional email record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A3.8/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
nameYesWebhook endpoint name.
urlYesHTTPS URL that will receive webhook events.
eventsNoEvent types to subscribe to. If omitted, a default set is used.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
webhookNoThe outbound webhook record returned by Sequenzy.

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_testA
Destructive
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
abTestIdYesA/B test ID to delete.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
abTestIdNoDeleted A/B test ID.

TDQS

A4.5/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_variantA
Destructive
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
abTestIdYesA/B test ID
variantIdYesA/B test variant ID to delete.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
abTestNoThe A/B test record returned by Sequenzy.
variantIdNoDeleted A/B test variant ID.

TDQS

A4.5/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_syncA
Destructive
Inspect

Remove an audience sync mapping. The Meta audience itself is kept (running ads are not disrupted) - only future syncs stop.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
syncIdYesAudience sync ID to remove.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
audienceSyncIdNoDeleted audience sync ID.

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_campaignA
Destructive
Inspect

Permanently delete a campaign. This cannot be undone. Sending, scheduled, or paused campaigns must be cancelled with cancel_campaign first.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
campaignIdYesCampaign ID to delete.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
campaignIdNoDeleted campaign ID.

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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_pageC
Destructive
Inspect

Delete a landing page

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
landingPageIdYesLanding page ID.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
landingPageIdNoDeleted landing page ID.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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

No guidance on when to use this tool 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_listA
Destructive
Inspect

Permanently delete a subscriber list and remove all of its memberships. Subscribers themselves are kept. This cannot be undone.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
listIdYesSubscriber list ID to delete.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
listIdNoDeleted list ID.

TDQS

A4.1/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_productA
Destructive
Inspect

Delete a product previously pushed via upsert_products (Commerce API products only), identified by your productId.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
productIdYesYour productId used when upserting the product.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
productIdNoDeleted product ID.

TDQS

A4.3/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_segmentA
Destructive
Inspect

Permanently delete a segment. This cannot be undone. Subscribers are not affected.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
segmentIdYesSegment ID to delete.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
segmentIdNoDeleted segment ID.

TDQS

A4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_sequenceB
Destructive
Inspect

Delete a sequence

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
sequenceIdYesSequence ID

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
sequenceIdNoDeleted sequence ID.

TDQS

B3.2/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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_tagA
Destructive
Inspect

Permanently delete a tag and remove it from all subscribers. This cannot be undone. System tags and tags used by sequences cannot be deleted.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
tagIdYesTag ID. Use list_tags to find tag IDs.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
tagIdNoDeleted tag ID.

TDQS

A4.5/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_templateC
Destructive
Inspect

Delete a template

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
templateIdYesTemplate ID

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
templateIdNoDeleted template ID.

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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_webhookA
Destructive
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
webhookIdYesWebhook endpoint ID to delete.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
webhookIdNoDeleted outbound webhook ID.

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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_sequenceC
Destructive
Inspect

Disable/pause a sequence

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
sequenceIdYesSequence ID

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
sequenceNoThe sequence record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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).

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
campaignIdYesCampaign ID to duplicate.
modeNoDuplication mode. Defaults to campaign.
variantIdNoA/B test variant ID whose content becomes the new campaign email. Required when mode is variant.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
campaignNoThe duplicated campaign record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A4.4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
sequenceIdYesSequence ID

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
sequenceNoThe sequence record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A4.5/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
sequenceIdYesSequence ID to enroll subscribers in.
emailsNoEmail addresses of subscribers to enroll. Combined with subscriberIds, maximum 500 total targets per call.
subscriberIdsNoSubscriber IDs to enroll. Combined with emails, maximum 500 total targets per call.
targetNodeIdNoOptional node ID to start enrollment at. Use a non-trigger nodeId from get_sequence. Defaults to the first step after the trigger.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
sequenceNoThe sequence record returned by Sequenzy.
enrollmentsNoList of sequence enrollment records returned by Sequenzy.
enrolledNoNumber of subscribers enrolled.
skippedNoNumber of subscribers skipped.

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_emailB
Read-only
Inspect

Generate email blocks from a prompt

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
promptYesDescription of the email to generate
styleNoStyle: minimal, branded, promotional
toneNoTone: professional, casual, friendly

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
emailNoThe generated email record returned by Sequenzy.
htmlNoGenerated HTML email body.
blocksNoGenerated Sequenzy email blocks.
subjectNoGenerated subject line.
previewTextNoGenerated inbox preview text.

TDQS

B3.2/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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_sequenceB
Read-only
Inspect

[DEPRECATED - Use create_sequence instead] Generate a multi-email sequence from a goal. Note: create_sequence now handles AI generation automatically.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
goalYesGoal of the sequence (e.g., 'onboard new SaaS trial users')
emailCountNoNumber of emails in the sequence (default: 5, max: 10)
durationDaysNoTotal duration in days (default: 14)

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
sequenceNoThe generated sequence record returned by Sequenzy.
stepsNoList of generated sequence step records returned by Sequenzy.

TDQS

B3.4/5.0
Behavior1/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines5/5

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_linesA
Read-only
Inspect

Generate A/B test subject line variants

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
topicYesTopic or context for the subject lines
countNoNumber of variants to generate (default: 5)

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
subjectLinesNoGenerated subject line variants.
variantsNoList of generated subject line variant records returned by Sequenzy.

TDQS

A3.5/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as '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_testA
Read-only
Inspect

Get A/B test details, variants, and per-locale localization sync status

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
abTestIdYesA/B test ID

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
abTestNoThe A/B test record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A4.3/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_statsA
Read-only
Inspect

Get A/B test aggregate stats and per-variant stats. Supports period or custom start/end ranges.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
abTestIdYesA/B test ID
periodNoOptional period: 1h, 24h, 7d, 30d, or 90d.
startNoCustom range start as ISO 8601. Requires end.
endNoCustom range end as ISO 8601. Requires start.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
abTestNoThe A/B test record returned by Sequenzy.
statsNoThe A/B test statistics record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A3.9/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_accountA
Read-only
Inspect

Get current account information including available companies. IMPORTANT: If you have access to multiple companies, you MUST either:

  1. Call select_company first to choose which company to work with, OR

  2. 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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
accountNoThe account record returned by Sequenzy.
companiesNoList of company records returned by Sequenzy.
currentCompanyIdNoCompany ID selected by the authenticated API key, when available.
selectedCompanyIdNoCompany ID selected locally for subsequent MCP calls, when available.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_urlsA
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If omitted, uses the selected/current company when available.
campaignIdNoCampaign ID for the campaign editor URL.
landingPageIdNoLanding page ID for the landing page editor URL.
sequenceIdNoSequence ID for the sequence editor URL.
templateIdNoTemplate/email ID for the email editor URL.
emailIdNoEmail ID for the email editor URL.
transactionalIdNoTransactional email ID.
emailSendIdNoEmail send ID for the sent email detail URL.
domainIdNoSending domain ID.
statusNoStatus for campaign/sequence list URLs.
settingsTabNoSettings tab slug, e.g. integrations, domain, tracking, api-keys, team.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
dashboardNoCompany dashboard URL.
settingsNoCompany settings URL.
campaignNoCampaign editor URL.
landingPageNoLanding page editor URL.
sequenceNoSequence editor URL.
emailNoEmail editor URL.
transactionalEmailNoTransactional email URL.
emailSendNoSent email detail URL.
domainNoSending domain settings URL.
urlsNoAll generated URLs keyed by resource type.

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_campaignB
Read-only
Inspect

Get campaign details and stats

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
campaignIdYesCampaign ID

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
campaignNoThe campaign record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

B3.3/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives 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_statsA
Read-only
Inspect

Get detailed statistics for a campaign, including attributed conversions and revenue (revenueCents)

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
campaignIdYesCampaign ID

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
campaignNoThe campaign record returned by Sequenzy.
statsNoThe campaign statistics record returned by Sequenzy.

TDQS

A3.8/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents 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.

Purpose5/5

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.

Usage Guidelines3/5

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_companyA
Read-only
Inspect

Get company details, processing status, and effective email localization settings

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdYesThe company ID to check

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
companyNoThe company record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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_conversationA
Read-only
Inspect

Get a conversation with its full message history, subscriber details, and context.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
conversationIdYesConversation ID.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
conversationNoThe inbox conversation record returned by Sequenzy.
messagesNoList of conversation message records returned by Sequenzy.

TDQS

A3.8/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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_sendA
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
emailSendIdYesEmail send ID to inspect.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
emailSendNoThe email send record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A3.8/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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_guideA
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
frameworkNoFramework/language (nextjs, express, python, etc.)
use_caseNoUse 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

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
guideNoThe integration guide record returned by Sequenzy.
codeNoGenerated integration code or example.
stepsNoSetup steps for the requested integration.

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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_pageB
Read-only
Inspect

Get landing page details, content, metrics, and URLs

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
landingPageIdYesLanding page ID.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
landingPageNoThe landing page record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

B3.2/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as list_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_countA
Read-only
Inspect

Get the number of subscribers in a segment

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
segmentIdYesSegment ID

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
countNoNumber of subscribers matching the segment.
segmentIdNoSegment ID that was counted.

TDQS

A4.1/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_sequenceA
Read-only
Inspect

Get sequence details plus editable step content. The response includes sequence.emails with each step's nodeId, linked emailId, subject, previewText, and blocks.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
sequenceIdYesSequence ID

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
sequenceNoThe sequence record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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

Schema coverage is 100%, so the baseline is 3. The description 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.

Purpose5/5

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.

Usage Guidelines3/5

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_statsA
Read-only
Inspect

Get statistics for a sequence, including attributed conversions and revenue (revenueCents) plus per-step failed subscribers and failure reasons

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
sequenceIdYesSequence ID

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
sequenceNoThe sequence record returned by Sequenzy.
statsNoThe sequence statistics record returned by Sequenzy.

TDQS

A3.8/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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_statsB
Read-only
Inspect

Get overview statistics for a time period

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
periodNoTime period: 7d, 30d, or 90d (default: 7d)

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
statsNoThe account or company statistics record returned by Sequenzy.

TDQS

B3.3/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not 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_subscriberA
Read-only
Inspect

Get the full subscriber profile, including tags, list memberships, sequence enrollments, email stats, and recent activity

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
emailNoSubscriber email address. Provide email or externalId to identify the subscriber.
externalIdNoCustomer-owned subscriber ID. Provide email or externalId to identify the subscriber.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
subscriberNoThe subscriber record returned by Sequenzy.

TDQS

A3.8/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_activityA
Read-only
Inspect

Get recent activity, email stats, and current sequence enrollments for a subscriber

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
emailNoSubscriber email address. Provide email or externalId to identify the subscriber.
externalIdNoCustomer-owned subscriber ID. Provide email or externalId to identify the subscriber.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
activityNoList of subscriber activity event records returned by Sequenzy.
subscribersNoList of subscriber records returned by Sequenzy.
paginationNoPagination metadata.

TDQS

A4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_templateA
Read-only
Inspect

Get a template's details, content, and all localized variants with sync status

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
templateIdYesTemplate ID

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
templateNoThe email template record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_emailA
Read-only
Inspect

Get a transactional email by ID or slug, including subject, preview text, blocks, variables, and linked dashboard URLs

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
idOrSlugYesTransactional email ID or API slug, for example `welcome-email`.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
transactionalNoThe transactional email record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A3.9/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
emailYesEmail address of the person to invite.
roleYesTeam role. Admins can manage the workspace; viewers have read-only access.
canManageBillingNoWhether the member can manage billing. Only the company owner can grant billing access. Defaults to false.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
invitationNoThe team invitation record returned by Sequenzy.

TDQS

A4.5/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_testsA
Read-only
Inspect

List A/B tests and their variants

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
sequenceIdNoOptional sequence ID to filter automation A/B tests.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
abTestsNoList of A/B test records returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives 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_accountsA
Read-only
Inspect

List the Meta ad accounts available through the connected Meta Ads integration. Use the returned account id as adAccountId when creating an audience sync.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
adAccountsNoList of ad account records returned by Sequenzy.

TDQS

A4.3/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_syncsA
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
audienceSyncsNoList of audience sync records returned by Sequenzy.

TDQS

A4/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_campaignsC
Read-only
Inspect

List all campaigns

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID to list campaigns for. If not provided, uses the currently selected company.
statusNoFilter by status (draft, scheduled, sent)
labelNoOptional label name filter. Only campaigns assigned this label are returned.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
campaignsNoList of campaign records returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness3/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives 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_conversationsA
Read-only
Inspect

List inbox conversations (email replies from subscribers). Filter by status, free-text search, or unread state, with pagination.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
statusNoFilter by conversation status. Defaults to all.
searchNoFree-text search across conversation subjects and participants.
unreadNoSet true to only return conversations with unread messages.
pageNoPage number. Defaults to 1.
limitNoResults per page, from 1 to 100. Defaults to 20.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
conversationsNoList of inbox conversation records returned by Sequenzy.
paginationNoPagination metadata.

TDQS

A4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 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.

Purpose5/5

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.

Usage Guidelines3/5

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_pagesC
Read-only
Inspect

List all landing pages for a company

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID to list landing pages for. If not provided, uses the currently selected company.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
landingPagesNoList of landing page records returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

C2.8/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, 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.

Conciseness3/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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_listsA
Read-only
Inspect

List all subscriber lists

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID to list lists for. If not provided, uses the currently selected company.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
listsNoList of list records returned by Sequenzy.

TDQS

A3.5/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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_productsA
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID to list products for. If not provided, uses the currently selected company.
providerNoFilter by provider: stripe, shopify, woocommerce, or manual.
searchNoFilter products by title.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
productsNoList of product records returned by Sequenzy.

TDQS

A4/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_segmentsC
Read-only
Inspect

List all segments

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID to list segments for. If not provided, uses the currently selected company.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
segmentsNoList of segment records returned by Sequenzy.

TDQS

C2.8/5.0
Behavior3/5

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.

Conciseness3/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose3/5

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.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives 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_sequencesB
Read-only
Inspect

List all email sequences (automations)

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID to list sequences for. If not provided, uses the currently selected company.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
sequencesNoList of sequence records returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true 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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives 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_tagsA
Read-only
Inspect

List all tags in the account

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID to list tags for. If not provided, uses the currently selected company.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
tagsNoList of tag records returned by Sequenzy.

TDQS

A3.9/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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

Schema description coverage is 100%, so the schema 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.

Purpose5/5

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.

Usage Guidelines3/5

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_membersA
Read-only
Inspect

List team members for the company, including the owner, members with their roles, and pending or expired invitations.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
membersNoList of team member records returned by Sequenzy.
invitationsNoList of team invitation records returned by Sequenzy.

TDQS

A4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_templatesA
Read-only
Inspect

List all email templates, including per-locale localization sync status

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
templatesNoList of email template records returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A4.1/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_emailsA
Read-only
Inspect

List transactional email templates, including their API slugs and linked email IDs

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
transactionalNoList of transactional email records returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. 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_deliveriesA
Read-only
Inspect

List recent delivery attempts for an outbound webhook endpoint, including status and response codes.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
webhookIdYesWebhook endpoint ID.
limitNoMaximum number of deliveries to return, from 1 to 100. Defaults to 20.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
deliveriesNoList of webhook delivery records returned by Sequenzy.

TDQS

A3.5/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives 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_webhooksA
Read-only
Inspect

List outbound webhook endpoints and their subscribed event types.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
webhooksNoList of outbound webhook records returned by Sequenzy.

TDQS

A3.8/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_websitesA
Read-only
Inspect

List all configured sender websites/domains

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
labelNoOptional label name filter. Only templates assigned this label are returned.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
websitesNoList of sender website records returned by Sequenzy.

TDQS

A3.5/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
conversationIdYesConversation ID.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
conversationNoThe inbox conversation record returned by Sequenzy.

TDQS

A4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
campaignIdYesCampaign ID to pause.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
campaignNoThe campaign record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A4.4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
landingPageIdYesLanding page ID.
nameNoOptional landing page name update.
slugNoOptional slug update before publishing.
contentNoComplete 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

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
landingPageNoThe landing page record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A3.8/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_fileB
Destructive
Inspect

Remove the attached distributable file from a product.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
productIdYesProduct ID from list_products, or your own productId for products pushed via upsert_products.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
productNoThe product record returned by Sequenzy.

TDQS

B3.4/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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

Schema coverage is 100%, so the baseline is 3. The description 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.

Purpose5/5

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.

Usage Guidelines2/5

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_subscriberB
Destructive
Inspect

Unsubscribe or delete a subscriber

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
emailNoSubscriber email address. Provide email or externalId to identify the subscriber.
externalIdNoCustomer-owned subscriber ID. Provide email or externalId to identify the subscriber.
hardDeleteNoIf true, permanently deletes. If false, just unsubscribes.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
subscriberNoThe subscriber record returned by Sequenzy.
hardDeletedNoWhether the subscriber was permanently deleted.

TDQS

B3.2/5.0
Behavior3/5

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.

Conciseness3/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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_listA
Destructive
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
listIdYesSubscriber list ID to remove subscribers from.
emailsYesEmail addresses to remove from the list. Maximum 500 per call.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
listNoThe list record returned by Sequenzy.
removedNoNumber of subscribers removed from the list.
skippedNoNumber of subscribers skipped.

TDQS

A4.4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
webhookIdYesWebhook endpoint ID.
deliveryIdYesDelivery ID to replay. Use list_webhook_deliveries to find delivery IDs.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
deliveryNoThe webhook delivery record returned by Sequenzy.
jobNoThe webhook replay job record returned by Sequenzy.

TDQS

A3.9/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
conversationIdYesConversation ID to reply in.
typeNoMessage type: outbound emails the subscriber, note is internal-only. Defaults to outbound.
subjectNoOptional subject override. Defaults to the conversation subject.
bodyTextNoPlain-text message body.
bodyHtmlNoHTML message body.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoThe conversation message record returned by Sequenzy.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
conversationNoThe inbox conversation record returned by Sequenzy.

TDQS

A4.3/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_testA
Destructive
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
abTestIdYesA/B test ID to restart
sourceVariantIdNoOptional variant ID to use as the new control email. Defaults to the selected winner.
testTypeNoOptional test type: subject or content.
winnerThresholdNoOptional number of subscribers before selecting a winner. Must be from 10 to 1000.
variantCountNoOptional total variants including the control. Must be from 2 to 4.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
abTestNoThe A/B test record returned by Sequenzy.

TDQS

A3.8/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
campaignIdYesCampaign ID to resume.
spreadOverHoursNoSpread the remaining delivery over an integer number of hours from 1 to 72.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
campaignNoThe campaign record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A4.3/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
campaignIdYesCampaign ID
scheduledAtYesFuture ISO 8601 timestamp for the send, for example 2026-06-01T14:00:00Z.
targetListsNoOptional 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'}.
sendTimeOptimizationNoWhether to use send-time optimization.
spreadOverHoursNoSpread delivery over an integer number of hours from 1 to 72. When set, spread delivery takes precedence over send-time optimization.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
campaignNoThe campaign record returned by Sequenzy.
scheduledAtNoScheduled send timestamp.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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_subscribersA
Read-only
Inspect

Search subscribers by free-text query, tags, list, or segment. If you omit limit, the tool fetches all pages and returns every match.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
queryNoSearch query (email or name)
tagsNoFilter by tags
listNoFilter by subscriber list ID or exact list name. Prefer listId when known.
listIdNoFilter by subscriber list ID.
listNameNoFilter by exact subscriber list name when the list ID is not known.
segmentIdNoFilter by segment ID
statusNoFilter by subscriber status: active, unsubscribed, or bounced.
limitNoMaximum results to return. If omitted, the tool returns all matches across pages.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
subscribersNoList of subscriber records returned by Sequenzy.
paginationNoPagination metadata.
returnedNoNumber of subscribers returned.
truncatedNoWhether the result was truncated by the requested limit.

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdYesThe company ID to select (from get_account's companies list)

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
companyIdNoSelected company ID.
companyNameNoSelected company name.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A4.4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
toYesRecipient email address
subjectNoEmail subject (required if not using templateId)
htmlNoEmail HTML content (required if not using templateId)
templateIdNoTemplate ID to use (alternative to html)
variablesNoVariables for template personalization. Nested objects and arrays are supported for repeat blocks, for example { items: [...] }.
subscriberExternalIdNoCustomer-owned subscriber ID for attaching analytics/localization on single-recipient sends. Maximum length: 255 characters.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
emailSendNoThe transactional email send record returned by Sequenzy.
transactionalNoThe transactional email record returned by Sequenzy.

TDQS

A3.8/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool 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

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
campaignIdYesCampaign ID to test
toYesEmail address to send test to

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
emailSendNoThe test email send record returned by Sequenzy.
recipientNoTest email recipient.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A3.6/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
syncIdYesAudience sync ID to run.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
audienceSyncNoThe audience sync record returned by Sequenzy.
jobNoThe audience sync job record returned by Sequenzy.
jobIdNoQueued audience sync job ID.

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
jobNoThe product sync job record returned by Sequenzy.
jobIdNoQueued product sync job ID.

TDQS

A3.8/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
webhookIdYesWebhook endpoint ID to test.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
webhookNoThe outbound webhook record returned by Sequenzy.
deliveryNoThe test webhook delivery record returned by Sequenzy.

TDQS

A3.8/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_pageA
Destructive
Inspect

Unpublish a landing page and return it to draft status. Optional name, slug, or content updates are saved first.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
landingPageIdYesLanding page ID.
nameNoOptional landing page name update.
slugNoOptional slug update before unpublishing.
contentNoComplete 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

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
landingPageNoThe landing page record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A3.8/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
abTestIdYesA/B test ID
variantIdYesA/B test variant ID
subjectNoVariant subject line
previewTextNoVariant preview text. Pass an empty string to clear it.
htmlNoReplacement HTML body. Mutually exclusive with blocks.
blocksNoReplacement 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

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
abTestNoThe A/B test record returned by Sequenzy.
variantNoThe A/B test variant record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A4/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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).

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
syncIdYesAudience sync ID
frequencyNoNew sync frequency.
isActiveNoSet false to pause the sync, true to resume it.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
audienceSyncNoThe audience sync record returned by Sequenzy.

TDQS

A3.8/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
campaignIdYesCampaign ID
nameNoCampaign name
subjectNoEmail subject line
trackingCodeNoOptional campaign tracking code for UTM templates. Use only when explicitly requested. Send an empty string to clear it.
htmlNoEmail HTML content. Mutually exclusive with `blocks`.
blocksNoSequenzy 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: [...] }.
replyToNoSet reply-to using an existing reply profile email address for this company.
replyProfileIdNoSet reply-to using a reply profile ID for this company.
campaignDataNoSet campaign-scoped JSON data for repeat blocks and personalization.
computedListsNoSet computed list definitions derived from campaignData at send time.
labelsNoReplacement label names. Send an empty array to clear labels. Missing labels are created automatically.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
campaignNoThe campaign record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

C2.9/5.0
Behavior3/5

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.

Conciseness2/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
conversationIdYesConversation ID.
statusYesNew conversation status.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
conversationNoThe inbox conversation record returned by Sequenzy.

TDQS

A3.5/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
landingPageIdYesLanding page ID.
nameNoLanding page name.
slugNoLanding page URL slug. It will be normalized and made unique within the company.
contentNoComplete 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

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
landingPageNoThe landing page record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A4.2/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
domainNoReplacement custom domain.
verifyNoRefresh domain verification after any domain update.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
landingPageNoThe landing page record returned by Sequenzy.
domainNoLanding page domain.

TDQS

A3.8/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
listIdYesSubscriber list ID to update.
nameNoNew list name.
descriptionNoNew list description. Pass null to clear it.
isPrivateNoWhether the list is private.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
listNoThe list record returned by Sequenzy.

TDQS

A4.5/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
segmentIdYesSegment ID to update.
nameNoNew segment name.
filterJoinOperatorNoHow top-level filters combine. Use `"and"` to require every filter or `"or"` to match any filter.
filtersNoReplacement segment filters. Same shape and validation rules as create_segment. Mutually exclusive with `root`.
rootNoReplacement nested filter root. Mutually exclusive with `filters` and `filterJoinOperator`.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
segmentNoThe segment record returned by Sequenzy.

TDQS

A4.3/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
sequenceIdYesSequence ID
nameNoSequence name
enrollmentModeNoUpdated sequence re-entry mode. 'matching_field' is only valid for event-based sequence triggers.
enrollmentFieldPathNoDot-path event property used by enrollmentMode='matching_field', such as 'order.id' or 'product.providerVariantId'. Omit to leave unchanged. Use clearEnrollmentFieldPath to clear it.
clearEnrollmentFieldPathNoSet true to clear enrollmentFieldPath without sending a nullable schema value.
stopConditionNoUpdate 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.
branchNoInsert 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.
emailsNoUpdated sequence emails. If you omit emailId/nodeId, items are matched by existing step order.
stepsNoAlias for emails. Supports the same fields and matching rules.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
sequenceNoThe sequence record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A3.5/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
emailNoSubscriber email address. Provide email or externalId to identify the subscriber.
externalIdNoCustomer-owned subscriber ID. Provide email or externalId to identify the subscriber.
attributesNoAttributes to update
addTagsNoTags to add
removeTagsNoTags to remove

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
subscriberNoThe subscriber record returned by Sequenzy.

TDQS

A3.5/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
tagIdYesTag ID. Use list_tags to find tag IDs.
colorYesNew tag color.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
tagNoThe tag record returned by Sequenzy.

TDQS

A4/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
templateIdYesTemplate ID
nameNoTemplate name
subjectNoEmail subject line
htmlNoEmail HTML content. Mutually exclusive with `blocks`.
blocksNoSequenzy 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: [...] }.
labelsNoReplacement label names. Send an empty array to clear labels. Missing labels are created automatically.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
templateNoThe email template record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A3.8/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
idOrSlugYesTransactional email ID or API slug, for example `welcome-email`.
nameNoTransactional email name.
enabledNoWhether this transactional email can be sent.
subjectNoEmail subject line.
previewTextNoEmail preview text.
htmlNoEmail HTML content. Mutually exclusive with `blocks`.
blocksNoReplacement 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

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
transactionalNoThe transactional email record returned by Sequenzy.
appUrlsNoDashboard URLs for relevant Sequenzy resources.
urlNoPrimary dashboard URL for this result.
settingsUrlNoCompany settings URL when available.

TDQS

A4/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
webhookIdYesWebhook endpoint ID.
nameNoNew webhook endpoint name.
urlNoNew HTTPS URL that will receive webhook events.
eventsNoReplacement event type subscriptions.
statusNoEnable or disable deliveries to this endpoint.

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
webhookNoThe outbound webhook record returned by Sequenzy.

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdNoCompany ID. If not provided, uses the currently selected company.
productsYesProducts to create or update (max 100).

Output Schema

ParametersJSON Schema
NameRequiredDescription
successNoWhether the Sequenzy operation succeeded.
messageNoHuman-readable status, confirmation, or next-step message.
noteNoAdditional context about the result.
itemsNoFallback array wrapper used only when a tool returns a bare array.
valueNoFallback object wrapper used only when a tool returns a non-object value.
productsNoList of product records returned by Sequenzy.
createdNoNumber of products created.
updatedNoNumber of products updated.

TDQS

A4.1/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

  1. 113 tool updatesv0.1.0
    • First observedadd_ab_test_variant
    • First observedadd_subscriber
    • First observedadd_subscribers_to_list
    • First observedadd_website
    • First observedattach_product_file
    • First observedcancel_campaign
    • First observedcancel_sequence_enrollments
    • First observedcancel_team_invitation
    • First observedcheck_website
    • First observedconnect_landing_page_domain
    • First observedcreate_ab_test
    • First observedcreate_api_key
    • First observedcreate_audience_sync
    • First observedcreate_campaign
    • First observedcreate_company
    • First observedcreate_landing_page
    • First observedcreate_list
    • First observedcreate_segment
    • First observedcreate_sequence
    • First observedcreate_tag
    • First observedcreate_template
    • First observedcreate_transactional_email
    • First observedcreate_webhook
    • First observeddelete_ab_test
    • First observeddelete_ab_test_variant
    • First observeddelete_audience_sync
    • First observeddelete_campaign
    • First observeddelete_landing_page
    • First observeddelete_list
    • First observeddelete_product
    • First observeddelete_segment
    • First observeddelete_sequence
    • First observeddelete_tag
    • First observeddelete_template
    • First observeddelete_webhook
    • First observeddisable_sequence
    • First observedduplicate_campaign
    • First observedenable_sequence
    • First observedenroll_subscribers_in_sequence
    • First observedgenerate_email
    • First observedgenerate_sequence
    • First observedgenerate_subject_lines
    • First observedget_ab_test
    • First observedget_ab_test_stats
    • First observedget_account
    • First observedget_app_urls
    • First observedget_campaign
    • First observedget_campaign_stats
    • First observedget_company
    • First observedget_conversation
    • First observedget_email_send
    • First observedget_integration_guide
    • First observedget_landing_page
    • First observedget_segment_count
    • First observedget_sequence
    • First observedget_sequence_stats
    • First observedget_stats
    • First observedget_subscriber
    • First observedget_subscriber_activity
    • First observedget_template
    • First observedget_transactional_email
    • First observedinvite_team_member
    • First observedlist_ab_tests
    • First observedlist_ad_accounts
    • First observedlist_audience_syncs
    • First observedlist_campaigns
    • First observedlist_conversations
    • First observedlist_landing_pages
    • First observedlist_lists
    • First observedlist_products
    • First observedlist_segments
    • First observedlist_sequences
    • First observedlist_tags
    • First observedlist_team_members
    • First observedlist_templates
    • First observedlist_transactional_emails
    • First observedlist_webhook_deliveries
    • First observedlist_webhooks
    • First observedlist_websites
    • First observedmark_conversation_read
    • First observedpause_campaign
    • First observedpublish_landing_page
    • First observedremove_product_file
    • First observedremove_subscriber
    • First observedremove_subscribers_from_list
    • First observedreplay_webhook_delivery
    • First observedreply_to_conversation
    • First observedrestart_ab_test
    • First observedresume_campaign
    • First observedschedule_campaign
    • First observedsearch_subscribers
    • First observedselect_company
    • First observedsend_email
    • First observedsend_test_email
    • First observedsync_audience_now
    • First observedsync_products
    • First observedtest_webhook
    • First observedunpublish_landing_page
    • First observedupdate_ab_test_variant
    • First observedupdate_audience_sync
    • First observedupdate_campaign
    • First observedupdate_conversation_status
    • First observedupdate_landing_page
    • First observedupdate_landing_page_domain_settings
    • First observedupdate_list
    • First observedupdate_segment
    • First observedupdate_sequence
    • First observedupdate_subscriber
    • First observedupdate_tag
    • First observedupdate_template
    • First observedupdate_transactional_email
    • First observedupdate_webhook
    • First observedupsert_products

TDQS

B3.4/5.0

Scored across 113 tools

Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count1/5

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.

Completeness3/5

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

ActivityActive
ResponsivenessUnresponsive

Related MCP Connectors

Related MCP Servers

  • F
    license
    B
    quality
    D
    maintenance
    Enables management of email campaigns, subscribers, lists, segments, journeys, templates, transactional email, and client/account settings through the Campaign Monitor API via natural language.
    100
    1
    -
  • F
    license
    Not graded
    quality
    D
    maintenance
    Enables interaction with the Mailchimp API for managing campaigns, lists, templates, reports, and automations through natural language.
    3
    -
  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to interact with Mailjet's contact, campaign, segmentation, statistics, and workflow APIs for managing email marketing operations through natural language.
    123 npm
    11
    Apache 2.0